?

Sep 03 2016

phpMyAdmin SQL注入漏洞(CVE-2016-5703)分析

首頁 » 代碼審計 » phpMyAdmin SQL注入漏洞(CVE-2016-5703)分析   

0x00.影響版本 

Version 4.6.x (<4.6.3) 
Version 4.4.x (<4.4.15.7) 

  

0x01.漏洞描述 

phpMyAdmin是一個web端通用MySQL管理工具,上述版本在central_columns.lib.php文件里的db參數存在sql注入漏洞,攻擊者利用此漏洞可以獲取數據庫中敏感信息,甚至可以執行任意命令

0x02.測試環境 

Windows7(X64)+PHP5.5.12+Apache/2.4.9+phpMyAdmin4.6.2 


0x03.漏洞詳情 

從官方的補丁ef6c66dca1b0cb0a1a482477938cfc859d2baee3來看,其對libraries\central_columns.lib.php中某幾個function中的$db參數進行了轉義,由此我們可以初步判定注入點就出現在這幾個函數的$db參數處 ; 

1.png

我們全局搜索一下引入了central_columns.lib.php的文件

2.png
總共四個文件包含了central_columns.lib.php,其中三個文件為庫函數文件,因此最直接與用戶交互的文件還是db_central_columns.php 
我們來到db_central_columns.php,搜索一下打補丁的幾個函數: 

PMA_deleteColumnsFromList出現在大約89行 
PMA_getColumnsList出現在大約135行 
PMA_getCentralColumnsCount出現在大約94行 
PMA_getCentralColumnsListRaw出現在大約49行 

我們應該盡量選擇不需要滿足過多if條件語句以及位置盡量靠前的不危險函數分析,跟進PMA_getCentralColumnsCount函數: 

3.png


我們能在函數91行之前打印出任意字符串,而在if語句之后無法打印出字符串,我們看到函數93~95行出現了if語句判斷,因此我們跟進if語句if(empty($cfgCentralColumns)),其中$cfgCentralColumns是從PMA_centralColumnsGetParams獲取到的,繼續跟進PMA_centralColumnsGetParams函數: 
該函數同樣在central_columns.lib.php文件里大約17行 
4.png

我們在25行之后打印一下$cfgRelation變量 

5.png


根據接下來的if語句,我們需要使得$cfgRelation['centralcolumnswork']不為false,才能使程序完整執行下去,那么$cfgRelation['centralcolumnswork']是個什么變量呢? 
跟進函數PMA_getRelationsParam(在libraries\relation.lib.php大約61行) 

6.png


繼續跟進函數PMA_checkRelationsParam(在libraries\relation.lib.php大約451行) 

7.png


我們可以看到,我們需要的變量在這個foreach語句中被定義成了false,我們繼續向下跟進,從大約563行起,出現了如下語句: 
8.png


官方文檔http://docs.phpmyadmin.net/zh_CN/latest/config.html,我們可以知道PMA_checkRelationsParam函數的作用就是檢查用戶是否自定義了配置文件,只有用戶自定義了配置文件,我們需要的$cfgRelation['centralcolumnswork']才能為True 

那么,如何自定義配置文件呢? 

我們知道,phpMyAdmin在沒有自定義配置文件時會默認加載libraries\config.default.php中的配置;要自定義配置文件,我們只需要在phpMyAdmin根目錄將config.sample.inc.php文件copy為config.inc.php,并將41~44/47~68行取消注釋,43以及44行改為MySQL用戶(需要與攻擊時phpMyAdmin的登錄用戶一致): 

9.png


然后創建一個名為phpmyadmin的數據庫,選中該數據庫然后點擊導航欄“操作”,根據頁面錯誤提示即可自動創建phpMyAdmin自身的數據庫 

接下來回到central_columns.lib.php文件PMA_centralColumnsGetParams函數中, 
我們在與之前同樣的位置打印一下$cfgCentralColumns變量,我們發現頁面已經能讓你能夠dump出數據了,說明程序已經能夠向下執行,$cfgRelation['centralcolumnswork']變量為True 

10.png


接下來我們到存在漏洞的函數PMA_getCentralColumnsCount中打印查詢語句以及結果集: 

11.png


我們發現打印在頁面上的sql語句存在很典型的注入類型,如下圖所示: 

12.png

最后需要明確的一個問題,central_columns是什么? 
我們知道之前我們創建的數據庫phpmyadmin存在一個數據表pma_central_columns,而任意一個數據表的任何字段都可以添加進入pma_central_columns,在創建新的表或者添加字段時就能從此表中直接選取插入,所以我們能看出central_columns是作為儲存一些關鍵字段,以方便添加外鍵時使用。 

0x04.漏洞修復 

1.使用Utils::sqlAddSlashes函數對libraries\central_columns.lib.php的$db參數轉義, 
或者升級phpMyAdmin Version4.6至4.6.3,Version4.4 升級至4.4.15.7以修復此漏洞 

0x05.漏洞總結 

phpMyAdmin本身作為數據庫管理工具,登錄后的注入顯得相當雞肋,最近的無需登錄漏洞也是出在2.8.3左右版本。而從出現漏洞的文件來看,同一個文件僅僅部分函數進行了轉義防護,這也可以看出開發人員在修復漏洞時“指哪修哪”,而最近以色列安全研究人員@e3amn2l提交的近20個漏洞中也出現了相似的未轉義引起的漏洞,更加印證了這一點。 
因此我認為安全從業人員在接收到安全漏洞時,應該首先構思最優的安全修復指南,而不是直接交給開發人員進行修復,多一個流程也可盡量避免在同一個地方重復跌倒。 

0x06.參考資料 

http://smita786.blogspot.com/2014/06/gsoc14-coding-week-3-using-central-list.html 
2016年phpMyAdmin漏洞統計 

13.png

如果您喜歡本博客,歡迎點擊圖片定訂閱到郵箱填寫您的郵件地址,訂閱我們的精彩內容:

正文部分到此結束

文章標簽: phpmyadmin漏洞 CVE-2016-5703

版權聲明:若無特殊注明,本文皆為( mOon )原創,轉載請保留文章出處。

也許喜歡: «Hack Redis via Python urllib HTTP Header Injection | 360webscan防御腳本繞過»

你腫么看?

你還可以輸入 250/250 個字

? 微笑 大笑 拽 大哭 親親 流汗 噴血 奸笑 囧 不爽 暈 示愛 害羞 吃驚 驚嘆 愛你 嚇死了 呵呵

評論信息框

這篇文章還沒有收到評論,趕緊來搶沙發吧~

?
?
河北11选5开奖