*本文中涉及到的相關漏洞已報送廠商並得到修復，本文僅限技術研究與討論，嚴禁用於非法用途，否則產生的一切後果自行承擔。 本文中出現的所有敏感信息已做打碼處理  

一、找網站SQL注入點

在測試時後發現有一個信息查詢框，就是下面這個圖片顯示的。一般信息查詢框會和數據庫存在交互。 

我輸入數字1，會正常提示木查詢到相關信息。

那我們使用1′測試一下，發現不彈未查詢到相關信息的提示框，也沒有任何數據輸出，大致判斷這個點存在sql注入，並且不對輸出報錯信息。

大概猜測出SQL語句爲 ：

select * from A where id ='$_POST['id']';

沒有對用戶輸入的數據做任何過濾。

構造一個閉合語句再次確認一些是否確認存在sql注入。

payload：1′ #

通過上面簡單測試，已經確定了，肯定存在sql注入。

二、sqlmap跑一下 

將數據包保存到一個文件，直接用sqlmap跑。非常震驚，居然有51個庫。

經過查詢，查到後臺的賬號密碼，那我就開始找後臺的艱辛路程了。

三、找後臺

沒有找到後臺，但是發現robots文件。

從robots上看到是PHPCMS系統

使用PHPCMS系統通用後臺地址admin.php，m=admin&c=index&a=login，都不行，測了好就發admin模型下的index控制器是存在，當我們訪問的時候就會自動跳到首頁，這也該是開發者後來做了修改，專門做防黑的。

四、找通用漏洞

這個步驟就不多說了，我測了已暴光的漏洞，都是不行，說明開發者還是有安全意識的，把漏洞都給修復了。

五、返回sqlmap

還有一種思路就是使用sqlmap –os-shell直接獲取shell，但是這個基本上不行的，因爲網站的文件基本上都是755權限，沒有寫的權限就會失敗。那我還是抱着一絲絲希望去測試了。

使用sqlmap –os-shell需要知道網站的絕對路徑，網站絕對路徑可以通過中間件配置文件查看。

首先需要知道網站用了什麼中間件，我沒有用nmap跑，只用404看到是nginx ,nginx的配置文件  /usr/local/nginx/conf/ngixn.conf

用sqlmap –file-read 去讀nginx配置文件。通過配置文件只看到一條默認的配置信息

需要注意的是如果在nginx.conf文件沒有看到有價值的信息，有一種可能是存在，/usr/local/nginx/conf/vhost/網站域名.conf 這個位置，果不其然就是它。

找到了真實的路徑，就可以使用 sqlmap –os-shell了，但是正式我當時預料的沒有寫入權限導致拿shell失敗。

六、使用sqlmap讀取網站源碼

通過上面的思路我們已經知道網站的真實路徑，知道了是PHPCMS系統，那我們可以讀取網站的文件了。

1、讀取路由文件  caches\configs\route.php 查看路由文件沒有問題。

2、查看系統文件 caches\configs\system.php  （這個文件能看是否開啓了域名訪問後臺）

3、在上面我們說到admin模型下index控制器是能訪問，知識在訪問的時候會跳轉到主頁，那我們下載index控制器文件看下。  phpcms\modules\admin\index.php ,查看index控制器下的login方法是沒有做任何修改的。

七、側面滲透測試

上面說了一共有51個網站，我隨機看了幾個，數據庫的結構是一樣的，說明是同一個建站系統。

那我們用nmap掃一下服務發現有8080服務，這個網站8080端口的網站時dedecms系統搭建的，我正好有後臺密碼，這樣能通過dedecms上傳文件。

八、代碼審計

通過上面們大概判斷是admin模塊index控制器有問題。

查看admin模塊多了一個MY_index.php控制器，

查看MY_index.php 發現裏面有一個構造函數，這個函數大概意思就是會打開這個方法會判斷你的right_enter的session值是否爲空，若果爲空，那麼就回到首頁，這這是我們剛開始一直打不開後臺的原因。

經過看phpcms開發手冊（我對這看系統二次開發不太熟悉，我只知道是一個MVC結構的php程序），如果需要對控制器進行二次開發需要在同級目錄創建一個MY_*.php文件，大概意思就是創建這個文件後程序在運行index模塊時會運行MY_index.php裏面的代碼。

到這了明白了，因爲沒有$_SESSION['right_enter']值，所以導致登陸不了，所以打開後臺首先需要給$_SESSION['right_enter']賦值。經過不懈努力找到了一個正確文件。

相關文章