對印度某電子商務公司從LFI到資料庫獲取的滲透測試過程
本文分享的是作者在滲透測試過程中，通過不同漏洞的組合利用，最終拿下印度某大型電子商務公司資料庫許可權。（文章已經相關公司許可釋出）
從LFI漏洞入手
本次滲透測試的目標比較確定，最初我偏向去發現其中的本地檔案包含漏洞（LFI），所以我著重對其中的檔案互動功能和特性進行了深入的測試分析，很巧的是，我發現了該公司一個針對不同移動裝置顯示 “Android Google play” 和 “iPhone App store” 的自身APP下載頁面，如下：
當我點選頁面中 “Android Google play” 和 “iPhone App store”任意一個按鈕，之後就會跳到如下的頁面： http://www.xxxx.com/downloadcallback/null ：
接著，就會馬上重定向到相應的APP下載引用頁面（Referrer Page）。當我在瀏覽器隱身模式下把引用頁面去掉，想看看有什麼反應時，請求服務端後返回了一個“404 Page not found” 的響應，很明顯，它查詢了某些條件或請求引數，可能遵循了某種簡單的if/else邏輯。為了詳細檢視是否有其它引數遺漏，我看到了頁面中的以下HTML原始碼：
以上程式碼中的邏輯已經很明顯了，有意思的是，在紅框標註內可以發現有一個名為“download_handler.php”的PHP檔案，在點選首次跳轉時出現的URL中 – http://www.xxxx.com/downloadcallback/null ，這個PHP檔案是不存在的，然而這個PHP檔案請求的是一個“path”的路徑引數，其路徑URL如程式碼中描述的finaldownloadlink，其“name” 名稱為nameURL。所以，去掉引用頁面後，最終也就返回了“404 Page not found”沒東西下載的響應了。如果按照上述HTML程式碼的規定，那麼其final URL應該是這種樣子的：
downloadcallback/download_handler.php?path=
於是，在該處我偶然地嘗試了一下目錄遍歷攻擊，path=../../../../etc/passwd，哇，竟然有讀寫許可權，除了/etc/passwd，還能讀取到其它服務端敏感檔案：
而且，我還可以讀取到各種Linux系統檔案、配置檔案和訪問日誌資訊，這樣一來，還能深入獲取到使用者的access token、引數和其它更敏感的資訊，這一切的罪魁禍首就是“download_handler.php”這個檔案：
轉化為SSRF攻擊
可知，這個PHP檔案只是簡單地執行使用者請求輸入，然後把輸入請求的響應返回，這種模式也很容易存在SSRF漏洞，比如：
這裡，讀取/etc/password的方式，還能用file:/// 方式（開啟對應的本地系統檔案）：
發現AWS ElasticBeanstalk例項
另外，當我用這種LFI和SSRF方式測試時，在讀取伺服器端/etc/motd檔案（系統佈告資訊欄）時，我發現這個Linux系統部署了AWS ElasticBeanstalk：
這個線索讓我有了深入滲透的決心，我們可以用上述SSRF方式來具體找找一些AWS例項，如MetaData或User Data：
利用上述SSRF方式，從“ http://169.254.169.254/latest/dynamic/instance-identity/document ”的系統服務API中，還可獲取到一些AWS賬號ID和雲服務區域資訊，如下：
在我檢查系統的AWS Elastic Beanstalk部署環境時，還發現了一個API呼叫，用它可以獲取到AWS Access Key、Secret Access Key和Token等重要的驗證資訊，這個API是：
http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role
直接用上述的SSRF方式，加上這個API呼叫，在響應資訊中就能返回AWS Access Key、Secret Access Key和Token，結合之前發現的賬戶ID，現在的情況是越來越嚴重了：
接下來，我們可以來驗證一下這些AWS賬戶了，只要密碼不過期，就可以在aws-cli命令列介面中來進行操作了，如下：
也可以列出相關資訊或下載S3 bucket資料到本地系統中，如下：
獲取資料庫
當細細檢視S3 bucket資料時，我發現了一些很敏感的檔案，如database.js、config.js、app.js、payment.config，果不其然，這些檔案中包含了支付相關的雜湊鍵值、加鹽值、資料庫存密碼憑據、內部使用工具名稱和密碼資訊等等。而且，我還發現了一個正在執行的MongoDB例項，其密碼就存在於明文的配置檔案中，我連線上之後，在其中發現了一些客戶資料，如下圖所示：
儘管它沒有包含所有的使用者詳細資訊，但這些資訊涉及10000多名客戶。之後，我向該公司上報了該漏洞，他們非常重視，給予了及時的漏洞修復，並輪換了所有受影響的金鑰和憑據。最終，這次從LFI到SSRF，再到Elastic Beanstalk例項，最後再到S3 bucket資料庫許可權獲取的操作，導致了上萬名目標公司客戶的敏感金鑰憑據資訊洩露。