分析CVE-2018-6376–Joomla！二階SQL注入

前言

每周我們都能聽到或看到許多關於安全漏洞的預警或報告，雖然看上去大多數的漏洞都千篇一律，但對於我們滲透測試人員而言，其中的一些思路方法和利用點卻尤為吸引我們的眼球。最近，知名的內容管理系統Joomla！就被曝出了存在二階SQL注入漏洞。這裡有一篇博文的分析大家可以看看：https://blog.ripstech.com/2018/joomla-privilege-escalation-via-sql-injection/

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

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

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

受影響Joomla！版本：= 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:///joomla/administrator/index.php?option=com_admin&view=profile&layout=edit&id=645

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

PAYLOAD:『 (單引號)

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

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

http:///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注入的可利用實例嗎？

GIF

靈光一現，我們想到了一個方法，即改變參數名提供數組『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 *)))