嗨，大家好！

這是我最近發現的一個漏洞利用鏈條，最終可導致印度最賺錢的電子商務公司的一個資料庫中的數據被我完全掌握。現在，就讓我們開始吧！

在滲透測試中，我比較關注LFI漏洞（本地文件包含）。因此我會特別注意目標網站上那些和文件交互有關的功能和頁面。而在這次目標的產品頁面上，我找到了一個常見的軟體下載功能，提供「Android Google paly」和「iPhone App store」兩種下載方式。

當我點擊它的時候，它把我重定向到下面的網頁。

接著，又立即重定向到先前的引用頁面，但當我直接在無痕瀏覽器中打開上述的下載鏈接時，會被重定向到「404 page not found」。很明顯，在打開下載頁面時，它會尋找一些條件和參數，然後遵循代碼中的if/else邏輯。為了查看這其中涉及哪些參數，我檢查了頁面源碼。

很明顯，源碼中的「download-handler.php」文件需要代入兩個參數，一個是參數「path」，表示最終的下載路徑；一個是參數「name」，表示路徑名稱。當缺少這兩個參數時，就會重定向到404。按照上面的代碼，最終的下載URL是

downloadcallback/download_handler.php?path=

於是我開始嘗試目錄遍歷攻擊../../../../etc/passwd，幸運的是，我擁有很大的許可權，能夠讀取/etc/passwd文件的內容和其他敏感文件。

最終，我能夠讀取各種Linux系統文件、配置文件、訪問日誌等，這些文件使我獲得了用戶的訪問令牌，以及更為敏感的信息。而個漏洞的罪魁禍首就是「download-handler.php」，如下所示它的源碼：

以上代碼的邏輯很簡單，就是將指定的文件名作為輸入，將內容讀取回客戶端。注意，這裡也很容易遭受SSRF攻擊

我嘗試過SSRF攻擊中可以使用的協議（file://、dict://、ftp://和gopher://），並發現可以通過file:///scheme讀取文件。

在我一開始發現這個文件讀取漏洞時，我碰巧遍歷讀取了/etc/motd文件，這表明該應用是部署在AWS ElasticBeanstack上。

於是我決定通過SSRF漏洞搜索AWS實例的元數據和用戶數據。並最終：

我甚至可以從介面「169.254.169.254/latest/」中檢索到處AWS帳戶的ID和區域。

說明一下，我從AWS Elastic Beanstalk中瞭解到了一個介面，可以用來獲取AWS訪問密鑰、Secret和令牌。

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

我很快通過SSRF進行了各種嘗試，獲取他們AWS的訪問密鑰、ID、令牌。這個時候，這個漏洞好像已經有點嚴重了。

是時候驗證找到的AWS帳戶了。為了確保登錄憑證不會過期，我配置了aws-cli命令行，並嘗試將S3 bucket數據列出並下載到本地。

在查看這些S3 bucket時，我發現了一些關鍵文件，比如databa se.js、config.js、app.js、payment.config文件，如如我所料，它們包含了諸如Payment hash key和salt（可以用來偽造訂單的），多個資料庫登錄憑證、一些內部工具的用戶名和密碼等等。另外我還發現了一個MongoDB實例，它的登錄憑證也放在配置文件中，當我連接上它時，我發現了大量客戶數據。

雖然這個MongoDB沒有包含所有的用戶詳細信息，已經超過了10萬個。我在很快報告了這個漏洞，公司也很快修復了它，並修改了所有受影響的登錄憑證和密鑰。因此，從文件讀取開始，我找到了SSRF漏洞，再瞭解到Elastic Beanstalk，從那裡獲取一個AWS帳戶登錄憑證，又從AWS S3中發現了一個MongoDB資料庫憑證。最後從MongoDB中，我發現大量客戶的詳細信息，以及各種敏感的憑證/密鑰。

感謝你的閱讀！

本文由白帽彙整理並翻譯，不代表白帽匯任何觀點和立場

來源：從文件讀取到徹底挖掘後端海量敏感數據|NOSEC安全訊息平臺 - NOSEC.ORG

白帽匯從事信息安全，專註於安全大數據、企業威脅情報。

公司產品：FOFA-網路空間安全搜索引擎、FOEYE-網路空間檢索系統、NOSEC-安全訊息平臺。

為您提供：網路空間測繪、企業資產收集、企業威脅情報、應急響應服務。

推薦閱讀：

相關文章