從SSRF到最終獲取AWS S3 Bucket訪問權限的實例分析

這篇文章將為大家詳細講解有關從SSRF到最終獲取AWS S3 Bucket訪問權限的實例分析，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

這應該是一次有針對性的滲透，本人專注于LFI（本地文件包含）漏洞搜尋，所以我很熱衷與文件交互相關的功能和端點。一個常見的用于下載App的“Android Google Play”和“iPhone App store”選項功能引起了我的注意。

當我點擊它時，它將我重定向到了另一個頁面，其鏈接地址如下 - 

接著又立即重定向到之前引用的頁面，當我在隱身窗口中打開它查看沒有引用頁面時的響應是什么時，它被重定向到了一個404頁面，因此很明顯它正在尋找某些條件和參數，然后進行簡單的if/else邏輯判斷。為了查看是否有任何缺失的參數，我偶然發現了頁面的以下HTML代碼 - 

邏輯非常清晰，正如你在紅色框中看到的，有一個php文件“download_handler.php”在URL中缺少，需要參數“path”作為finaldownloadlink以及“name”的URL名稱，這就是沒有下載任何內容的原因。所以最終的URL應該是 -

downloadcallback/download_handler.php?path=

我嘗試了目錄遍歷攻擊（../../../../etc/passwd），非常幸運文件幾乎都給了最大權限（一個常見錯誤：/），我能夠讀取/etc/passwd文件以及各種其它文件中的內容 -

我能夠讀取各種Linux系統文件，配置，訪問日志，并獲取get參數中的用戶訪問令牌以及其它更為敏感的信息。導致這個漏洞的罪魁禍首是“download_handler.php” -

PHP文件只是將該文件作為輸入并將其讀取回客戶端。很容易可以看出它應該也非常容易受到SSRF的攻擊 -

嘗試使用不同的URL schemas（file:/// , dict:// , ftp:// and gopher://）讀取 /etc/password，你也可以使用file:/// scheme執行相同操作 -

早些時候，當我通過LFI攻擊抓取敏感文件時，我碰巧讀取了/etc/motd文件，該文件表明該應用程序是通過AWS ElasticBeanstalk部署的。

這也讓我決定繼續通過SSRF搜索AWS實例元數據和用戶數據 -

我還能夠從以下API中檢索AWS賬戶ID和Region -

http://169.254.169.254/latest/dynamic/instance-identity/document

當我讀取AWS Elastic Beanstalk時，我遇到了一個API調用，它可以獲取AWS Access Key，Secret Access Key和Token。

http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role

我很快通過SSRF 進行了調用，我能夠獲取他們的AWS Access key，ID，token，在此之前我也獲得了他們的帳戶ID，這表明相比之前漏洞變得更加嚴重了 -

現在是時候對AWS賬戶進行身份驗證了。為了確保憑證沒有過期，我配置了aws-cli試圖列出并將S3 bucket數據下載到我的本地機器上 -

將s3 bucket內容復制到本地機器 -

在查看每個單獨的S3 bucket時，在一些bucket中我發現了一些關鍵文件，例如database.js，config.js，app.js，payment.config。這些文件很快引起了我的注意。正如我所料，其中包含了支付hash key和salt（可用于篡改訂單的支付），多個數據庫憑據，一些內部工具用戶名和密碼等信息。還有一個正在運行的MongoDB實例，其憑據可在配置文件的純文本中找到，當我嘗試連接到它時，我發現他們的客戶數據也存儲在其中 - 

雖然它沒有包含所有用戶的詳細信息，但其中已包含的數據量超過了10000條。隨后我立即向他們報告了這個漏洞，他們積極并迅速的進行了修復。感謝閱讀！

關于從SSRF到最終獲取AWS S3 Bucket訪問權限的實例分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。