如何分析CVE-2018-6376以及二階SQL注入

如何分析CVE-2018-6376以及二階SQL注入，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

Savan Gadhiya和Amish Patadiya將嘗試幫助我們理解并發現二階SQL注入方法和利用技術。還將演示如何使用SQLmap來利用二階SQL注入（即不要重復造輪子）。

什么是二階SQL注入？

為了預防SQL注入攻擊，而將輸入到應用程序中的某些數據進行了“轉義（escape）”，但是這些數據卻又在“未被轉義（Unescaped）”的查詢窗體中重復使用。此時，攻擊者可能注入的是一個PAYLOAD，這樣就會構成一個SQL查詢語句并被執行，這就是所謂的二階SQL注入。

了解更多：https://portswigger.net/kb/issues/00100210_sql-injection-second-order

下面，讓我們來通過Joomla中二階SQL注入的例子來更進一步的理解[CVE-2018-6376]。

詳情

受影響Joomla！版本：<= 3.8.3 and >= 3.7.0

危害：可將低權限用戶（Manager）提升為更高的的用戶權限（Administrator’或‘    Super Administrator’）。

注入檢測

現在，我們已經搭建好了一個版本為3.8.3的Joomla！平臺用于測試如下圖所示：

我們創建了具有“Super Users”權限的用戶“amish”，以及具有“Manager”權限的另一個用戶"savan"，如下所示：

我們的目標是將“Manager”權限的用戶提升為“Super Administrator”權限。因此現在我們以用戶'savan'的身份登錄。下圖顯示了用戶'savan'的儀表盤，并  且我們也可以看到Super User’當前也處于登錄狀態：

從漏洞報告中我們知道，受影響的實例是位于配置文件資料更新頁中。下圖顯示了用戶'savan'的配置文件更新頁面：

讓我們使用 BURP Suite來攔截配置文件更新請求。如下所示，表單數據的POST請求發向了以下地址：

http://<IP/domain>/joomla/administrator/index.php?option=com_admin&view=profile&layout=edit&id=645

受影響的參數是‘forms[params][admin_style]‘，我們將下面的有效載荷插入到受影響的參數中，如下所示：

PAYLOAD: ‘ (單引號)

成功提交此請求后，配置文件更新頁將顯示參考消息“已保存的項目”，如下圖所示：

以上并沒有顯示任何異樣，因為該頁面并沒有使用被注入的PAYLOAD構造SQL查詢并執行。讓我們訪問下面的URL，使用注入的有效載荷構造SQL查詢，并執行，如下圖所示：

http://<IP/domain>/joomla/administrator/index.php

查看源代碼我們可以得知，PAYLOAD的插入并不容易實施SQL注入攻擊。下圖顯示了文件'/administrator/components/com_admin/controllers/profile.php'的代碼片段，其中突出顯示了“編輯配置文件”功能的路徑：

當用戶更新配置文件詳細信息時，應用程序將檢索所有參數并返回JForm對象，如下圖所示：

下圖顯示應用程序將檢索到的用戶信息存儲到數據庫中：

上面我們已經確認用戶輸入并未被構造用于SQL查詢，因此PAYLOAD插入實例并不容易實施攻擊，讓我們在受影響的頁面來利用它。如下圖所示，我們插入以下字符串作為PAYLOAD，以查看SQL語句是如何被構造的：

PAYLOAD: test

通過儀表盤上顯示的錯誤信息我們可以看到，錯誤信息中僅顯示了PAYLOAD的第一個字符。

接著,我們做了進一步的嘗試。我們注入了另一個payload‘AND sleep(5);–‘ 并刷新了儀表盤。如下圖所示，我們得到了同樣的結果：

如果此時我們查看數據庫，就會發現我們輸入的PAYLOAD已被存儲在了數據庫中：

在確認payload被正確存儲后，下面讓我們來驗證受影響的代碼是如何構造SQL查詢的。受影響的實例來自‘administrator/templates/hathor/postinstall/hathormessage.php’文件。如下圖所示，代碼的第40行主要是從‘admin_style’參數獲取用戶的輸入值并傳遞給‘adminstyle’變量。在第47行，代碼直接使用用戶提供的輸入來構建SQL查詢。這里我們把它看成是一個數組，因此索引值為0的存儲值將被用于構造查詢。這也就是為什么在錯誤信息中，只能看到第一字符的原因。

現在我們已經知道了PAYLOAD會被視為一個數組，索引值為0的存儲值將被用于構造查詢。因此，讓我們嘗試提供一個數組‘[“test1″,”test2″,”test3”]’作為PAYLOAD。這么做的目的是測試第0個索引（即“test1”）是否會被用于構造SQL查詢。但結果還是令我有點失望，錯誤信息依舊只顯示了第一個字符“[”，這意味著程序將整個PAYLOAD視為了一個字符串，如下所示：

到這我已經有點懷疑人生了，難道這并不是SQL注入的可利用實例嗎？

靈光一現，我們想到了一個方法，即改變參數名提供數組‘admin_style’的第0個索引。如下圖所示，我們使用'jform [params] [admin_style] [0]'更改了參數名稱，并將相同的PAYLOAD注入到了'admin_style'的第0個索引中：

PAYLOAD: AND sleep(5);–

現在我們可以看到，雖然PAYLOAD并沒有被執行，但錯誤消息中已經可以完整顯示我們的PAYLOAD內容。

我們接著注入以下PAYLOAD來獲取目標數據庫名稱，我們獲取到了數據庫名稱為'joomla'如下圖所示：

Payload: extractvalue(0x0a,concat(0x0a,(select database())))

現在我們來實現我們的終極目標，即以超級管理員的權限訪問應用程序。以下PAYLOAD將為我們獲取到超級管理員用戶“amish”的session id，如下圖所示：

Payload: extractvalue(0x0a,concat(0x0a,(select * from joomla_session where username=’amish’)))

成功獲取session id后，我們就可以模擬超級管理員用戶訪問應用了。

自動化利用

當在實際的滲透環境中，我們不可能每次都手動進行測試，這樣會消耗我們大量的時間。那么，如何讓我們的測試實現自動化呢？

這里就不得不提sql注入的掃描神器SQLMap了。SQLMap為我們提供了專門針對二階注入的查詢開關，我們只需提供可能存在二階注入的目標URL地址即可。

注意/限制：由于這是二階SQL注入，所以我們不能使用多個線程來自動檢查每個查詢的輸出。

如果我們直接將該實例提供給SQLMap，可能無法正常運作。為了解決這個問題，我們需要創建一個sqlmap可以將其PAYLOAD注入并順利獲取數據的查詢。我們構造了以下PAYLOAD，作為請求中‘jform[params][admin_style][0]’參數的值，并使用SQLMap '-r'開關來解析請求，如下圖所示：

PAYLOAD: extractvalue(0x0a,concat(0x0a,(select @@version where 1=1 *)))

這里的‘*’代表SQLMap注入PAYLOAD的位置，例如：

• extractvalue(0x0a,concat(0x0a,(select @@version where 1=1 AND 5231=5231)))

• extractvalue(0x0a,concat(0x0a,(select @@version where 1=1 AND 5231=1623)))

• extractvalue(0x0a,concat(0x0a,(select @@version where 1=1 OR 7231=7231)))

• extractvalue(0x0a,concat(0x0a,(select @@version where 1=1 order by 1 —)))

• extractvalue(0x0a,concat(0x0a,(select @@version where 1=1 union all select NULL,NULL,NULL,’21231231232′)))

如下圖所示，SQLMap現在使用以下命令檢測注入并提取所有數據庫名稱：

sqlmap -r 1.txt –dbms MySQL –second-order “http://<IP/domain>/joomla/administrator/index.php” -D “joomla” –dbs

通過Sqlmap我們可以輕松提取到更多的數據。

防護措施

為了避免該類漏洞對你的影響，請務必升級你的Joomla！至3.8.5版本（截至本文發布時的最新版本）。Joomla！也提供了代碼層的修復方案，如下：

關于如何分析CVE-2018-6376以及二階SQL注入問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。