記錄一次平平無奇的雲上攻防過程

語言: CN / TW / HK

點擊藍字

關注我們

聲明

本文作者:TeamsSix

本文字數:1440

閲讀時長:4 分鐘

附件/鏈接 :點擊查看原文下載

本文屬於【狼組安全社區】所有,未經許可禁止轉載

由於傳播、利用此文所提供的信息而造成的任何直接或者間接的後果及損失,均由使用者本人負責,狼組安全團隊以及文章作者不為此承擔任何責任。

狼組安全團隊有對此文章的修改和解釋權。如欲轉載或傳播此文章,必須保證此文章的完整性,包括版權聲明等全部內容。未經狼組安全團隊允許,不得任意修改或者增減此文章內容,不得以任何方式將其用於商業目的。

之前有次在做攻防演練的時候,通過反編譯小程序找到了目標雲服務的 Access Key,最終通過這個 AK 拿下了目標上千萬條敏感信息以及幾十台雲服務主機的 root 權限,整個過程平平無奇,這裏簡單記錄下。

閲前須知:

  • 文中數據的值都是虛構的內容,非真實場景裏的數據。

  • 文中使用的 CF 工具版本為 v0.4.0,如果讀者有在使用 CF,為避免版本不同導致命令不一致的情況,請以 CF 使用手冊裏的命令為準,CF 使用手冊地址:wiki.teamssix.com/cf

一、

發現訪問憑證並利用

首先找到目標的微信小程序,反編譯小程序找到了硬編碼在源碼裏的 Access Key

將 Access Key 配置到 CF 雲環境利用框架裏,CF 項目地址:github.com/teamssix/cf

cf config

嘗試列出一下當前訪問憑證的資源,因為輸出內容較多,這裏僅展示了一部分,再次提醒一下,本文圖片中數據的值都是虛構內容,非真實場景裏的數據。

cf alibaba ls

最終通過 CF 列出這個 AK 裏有 2 個存儲桶以及 30 多台雲服務主機,不過裏面有一台是關機的。

二、

存儲桶的利用

先來看這兩個存儲桶,在第一個存儲桶 teamssix-api-example 裏有 500 多 M 的數據,在存儲桶體積比較少的情況下,可以直接使用 cf alibaba oss obj get 命令下載存儲桶裏的所有對象,但這裏存儲桶體積比較大,還是用 OSS Browser 大概預覽下吧。

用 OSS Browser 打開第一個存儲桶,翻了一遍,沒有發現太多敏感的信息,然後繼續打開第二個存儲桶,發現在第二個存儲桶裏存儲了大量的身份證信息。

在 OSS Browser 裏沒辦法看到這些文件的總數,好在 CF 的輸出結果裏可以看到存儲桶的文件總數。

從 CF 的輸出結果來看這個存儲桶總共有 345 w 條數據,從 OSS Browser 列出的結果來看,估計這三百多萬條的數據應該都是身份證照片之類的信息了。

三、

ECS 的利用

剛才通過 CF 發現了 30 多台雲服務主機,這裏先看看 CF 能對雲主機執行哪些操作。

cf alibaba ecs exec -h

在寫報告的時候需要有服務器權限證明的截圖,這裏可以直接使用 CF 一鍵執行三要素,方便寫報告。

cf alibaba ecs exec -b

接下來打算翻翻實例,看看能不能發現什麼有用的信息,後來在一個實例的命令歷史記錄裏發現了 MySQL 數據庫的明文密碼。

cf alibaba ecs exec -i i-abcdefghijklmn33 -c "cat ~/.bash_history | grep mysql"

連接到數據庫後,開始翻數據庫,翻着翻着,在一張表裏發現好東西,這張表存儲了目標一千多萬條敏感數據。

再後來,在其他的實例中還發現了一些容器,包括 ES 、Redis 數據庫的容器,不過裏面數據量沒有太多。

到這裏,通過這個 AK 已經拿到了目標一千多萬條數據庫敏感信息、三百多萬條身份證照片信息以及三十多台服務器 root 權限。

報告交上去後,給的分數也很可觀,不過這裏因為不通靶標,所以只能搞點數據分和權限分了。

總的來説,整個過程沒有太大的波瀾,這裏主要是利用了兩處目標的風險點:

  1. 雲服務的 Access Key 直接硬編碼到了小程序裏

  2. Access Key 權限沒有做好控制

解決起來也很簡單:

  1. 小程序裏不要硬編碼 Access Key,建議可以用臨時密鑰啥的

  2. 這裏的 Access Key 應該是隻需要 OSS 的權限,ECS 的權限就不應該再賦予給這個 AK 了

最後,如果師傅感覺 CF 這個工具還不錯,記得給個 Star 呀 ~,CF 項目地址:github.com/teamssix/cf

TeamsSix

掃描關注公眾號回覆加羣

和師傅們一起討論研究~

WgpSec狼組安全團隊

微信號:wgpsec

Twitter:@wgpsec