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

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

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

什么是二階SQL注入？

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

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

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

詳情

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

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

注入檢測

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

我們創(chuàng)建了具有“Super Users”權(quán)限的用戶“amish”，以及具有“Manager”權(quán)限的另一個用戶"savan"，如下所示：

我們的目標(biāo)是將“Manager”權(quán)限的用戶提升為“Super Administrator”權(quán)限。因此現(xiàn)在我們以用戶'savan'的身份登錄。下圖顯示了用戶'savan'的儀表盤，并  且我們也可以看到Super User’當(dāng)前也處于登錄狀態(tài)：

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

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

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

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

PAYLOAD: ‘ (單引號)

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

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

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

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

當(dāng)用戶更新配置文件詳細信息時，應(yīng)用程序?qū)z索所有參數(shù)并返回JForm對象，如下圖所示：

下圖顯示應(yīng)用程序?qū)z索到的用戶信息存儲到數(shù)據(jù)庫中：

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

PAYLOAD: test

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

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

如果此時我們查看數(shù)據(jù)庫，就會發(fā)現(xiàn)我們輸入的PAYLOAD已被存儲在了數(shù)據(jù)庫中：

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

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

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

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

PAYLOAD: AND sleep(5);–

現(xiàn)在我們可以看到，雖然PAYLOAD并沒有被執(zhí)行，但錯誤消息中已經(jīng)可以完整顯示我們的PAYLOAD內(nèi)容。

我們接著注入以下PAYLOAD來獲取目標(biāo)數(shù)據(jù)庫名稱，我們獲取到了數(shù)據(jù)庫名稱為'joomla'如下圖所示：

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

現(xiàn)在我們來實現(xiàn)我們的終極目標(biāo)，即以超級管理員的權(quán)限訪問應(yīng)用程序。以下PAYLOAD將為我們獲取到超級管理員用戶“amish”的session id，如下圖所示：

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

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

自動化利用

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

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

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

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

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現(xiàn)在使用以下命令檢測注入并提取所有數(shù)據(jù)庫名稱：

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

通過Sqlmap我們可以輕松提取到更多的數(shù)據(jù)。

防護措施

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

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