AWS控制臺中的XSS

正如我在Twitter上發布的那樣，我最近開始了一個對 AWS API 進行模糊測試的輔助項目。這是我之前關于該主題的工作的合乎邏輯的下一步。為了支持它，我必須構建自己的庫來手動制作 AWS API 請求并對其進行變異。我認為這將是一條非常富有成效的研究道路，但是我設法模糊了自己的方式，訂閱了一項我無法禁用的每年 36,000 美元的服務。它最終得到了解決（非常感謝所有幫助/提供幫助的人。這是一次令人傷腦筋的經歷），但出于顯而易見的原因，我暫時不會對 AWS API 進行模糊測試。

好消息是，在整個慘敗之前，即使圖書館還沒有完成，它已經為自己贏得了一個錯誤，這篇文章就是對它的解釋。它是通過 AWS 漏洞披露計劃報告的，現已修復。感謝 AWS 安全部門的 Peter 和 Patrick 忍受我所有的電子郵件！

發現

可以想象，對 AWS API 進行模糊測試并非易事。有數百種 AWS 服務和數千種可能的操作。這與無數參數相結合，每個協議都有不同的格式、不同的區域、不同的版本以及我們想要使用的所有輸入類型，這使得它非常耗時。

為了增加這個困難，我向 API 發送合法流量，這反過來會創建需要花錢的資源（作者注：本節是在上述事件之前編寫的。這是輕描淡寫的）。結果，我一直像鷹一樣觀察計費儀表板，并刪除創建的任何內容。我也一直在瀏覽 AWS 控制臺以尋找任何不妥之處。

在這些檢查過程中，我偶然發現了Elastic Beanstalk更改歷史記錄中的一條錯誤消息。

有趣的。然而，當時，我有點把它放在一邊，因為“很奇怪，你可以破壞 AWS 控制臺的一部分”，并繼續致力于模糊測試庫。我什至把這張照片貼到了推特上（如果你是我把它拿下來之前喜歡它的兩個人之一；謝謝）。然而，經過一點工作后，我有點恍然大悟，“這有安全隱患嗎？” （是的，我知道對嗎？黑客大師在工作）。

那么，什么是“b.requestParameters”，為什么 AWS 控制臺會不高興它為空？好吧，為了找出答案，我積累了從我多年的軟件開發和信息安全經驗中積累的所有技能和知識...... .. Ctrl+F 用于 JavaScript 中的“b.requestParameters”（再次，黑客大師在工作）。

這立即返回了答案。在 beanstalk-xp_en.min.js 的第 17,240 行（該行號來自美化的 JS 輸出）有對 b.requestParameters 的引用。

使用調試器進行單步調試后，可以清楚地看到更改歷史記錄頁面正在從 CloudTrail 加載事件并顯示它們。作為參考，這就是它的外觀（取自此處）。

Elastic Beanstalk 的更改歷史記錄功能是一項相當新的功能（于 2021 年 1 月發布），可讓您查看 EB 環境配置的更改。

這并沒有回答為什么 b.requestParameters 為空感到不安的問題，發生了什么？通過調試，很明顯它正在尋找 CloudTrail 事件的特定屬性，而 fuzzer 沒有提供它。在 CloudTrail 中查找該特定事件，果然，在嘗試update-environment操作時我沒有提供任何參數，因此 requestParameters 為空。

終于我們找到了罪魁禍首，但是我們能用我們發現的新錯誤做什么呢？下一個合乎邏輯的步驟是稍微探索一下。

HTML注入

從 JavaScript 可以看出，我們對兩個值有高度的控制。那些是用戶代理和環境名稱。此外，這些值似乎被直接插入到DOM中。

想到了跨站點腳本 (XSS)攻擊，但 AWS 通常非常擅長在將內容呈現到瀏覽器中之前對其進行清理。這是我在使用SSM Agent時遇到的第一手經驗。因此，我認為任何惡意內容都會在顯示之前進行清理。

為了測試這一點，我將一個損壞的圖像標簽的簡單有效負載放在一起（我故意將源設置為“x”）。我喜歡用它作為測試，因為如果它被渲染，它會給我一個很好的視覺指示器，否則我只會看到編碼值。

我修改了我的框架，將用戶代理設置為有效負載，點擊發送并等待。等了 10 分鐘后，我刷新了控制臺，然后傻眼了。

這是 AWS 控制臺中的有效 HTML 注入！下一步，XSS 會起作用嗎？更改了有效載荷，發送了它，然后等待了幾分鐘。壞消息：沒有 JavaScript 執行。原因？內容安全策略 (CSP)阻止了我。如果您不熟悉，可以將 CSP 視為瀏覽器可以加載某些資源的指南。JavaScript 可以從某些域加載，字體可以從不同的域加載，等等。

雖然 CSP 不能減輕跨站點腳本攻擊的原因，但它可以減輕影響。在這種情況下，CSP 阻止了內聯腳本，這使我的 XSS 有效負載失敗。

瀏覽控制臺的 CSP，我找不到解決方法。這給我們留下了令人失望的 HTML 注入。你能做一些遲鈍的網絡釣魚或社會工程計劃嗎？是的，也許。它很簡潔，但僅限于在 AWS 控制臺中找到的上下文中。我認為最現實的是，您可以嘗試插入帶有鏈接的“錯誤”消息并嘗試以這種方式欺騙某人。

有趣的是，您只需要與該帳戶關聯的有效憑據即可。這些憑證不需要 Elastic Beanstalk 或 CloudTrail 權限。此更改歷史儀表板也會加載失敗的嘗試。因此，即使您對某個角色或用戶擁有零權限，您更新 Elastic Beanstalk 環境的嘗試也會顯示出來。

iframe注入

沒有看到繞過 CSP 的方法，我向一些朋友尋求想法。在與我的朋友 Chris 聊天時（查看他在schneidersec.com上的博客），他注意到 iframe 部分下有一些有趣的東西。

內容安全策略允許您從與控制臺設置在同一區域的 S3 存儲桶加載 iframe。我們都對此感到驚訝，難道您不能創建自己的存儲桶并托管 HTML 嗎？我們不明白為什么不這樣做，所以我創建了一個 S3 存儲桶，放置了一些 HTML 并更改了我的有效負載以創建一個 iframe。結果是這樣的：

事實上，您可以從 S3 存儲桶加載 iframe！

提交給AWS

沒有看到通過 HTML/iframe 注入解決的 CSP 的明顯方法。很酷嗎？當然，我的意思是 AWS 控制臺中的任何漏洞都是整潔的，但 HTML 注入對于滲透測試報告來說是無用的。無論哪種方式，我都向 AWS 漏洞披露程序發送了一封電子郵件以及一些屏幕截圖和一個概念證明（用于在用戶代理中粘貼 HTML 有效負載以進行更新環境 API 調用的 Python 腳本）。

AWS 安全團隊迅速做出回應，并表示他們已將信息轉發給服務團隊。從這里開始，我等了大約兩周，發現“更改歷史記錄”頁面中不再有任何事件。“奇怪”，我想，“也許他們只是老掉了”？所以我創建了一些新的 CloudTrail 事件，但它們仍然沒有出現。

“也許他們現在對事件進行了驗證？是檢查惡意輸入還是影響現有環境？”。我可以看出負責構建表格的 JavaScript 已被修改，但它已被縮小并且區分新舊看起來太費時了。所以我創建了一個合法的 Elastic Beanstalk 應用程序和環境。當我這樣做的時候，我想四處看看是否有其他領域容易受到 HTML 注入的影響，而且確實有一些。幾個例子：

為了提供幫助（希望不會令人討厭），我向 AWS 發送了另一封電子郵件，其中附有一些屏幕截圖。失望的是我無法再次填充更改歷史記錄，即使使用真正的應用程序，我也開始清理。正是在這個時候，我有了一個想法，“這使用的是什么版本的Angular ”？我很快發現它沒有。它使用了 AngularJS。

模版注入

頁面使用 AngularJS 的實現引入了另一種類型的注入攻擊，我們可以嘗試，客戶端模板注入。當攻擊者可以提供自己的模板語言輸入時，就會發生模板注入攻擊。這會導致在用戶的瀏覽器中評估這些輸入。例如（取決于模板格式）您可以插入{{ 2+2 }}，這將評估為4.

在對自己之前沒有意識到 AngularJS 的情況感到非常失望之后，我創建了一個具有模板名稱的應用程序并刷新了瀏覽器。

我們已經確認它很容易受到模板注入的影響，但是我們可以從哪里開始呢？好消息是 PortSwigger 的Gareth Heyes在這方面做了一些巨大的研究（1、2）。

簡而言之，我們可以利用模板注入作為執行任意 JavaScript 并獲得跨站點腳本的方法！以前，這需要一些工作來逃避 Angular 表達式沙箱，然而，在 AngularJS 1.6 中，沙箱被刪除了。由于我們使用的是 1.8.1，因此我們不必擔心它，而是可以使用以下有效負載（取自此處）。

     {{constructor.constructor('alert(1)')()}}    

這將允許我們運行傳統的警報 XSS 有效負載，但它會通過內容安全策略嗎？我實際上并不確定。

我在這里的思考過程是我沒有注入新的腳本標簽，我只是要求 AngularJS 評估模板表達式，并且因為 AngularJS 已經被允許，它不會工作嗎？這不是真正的內聯評估，對嗎？所以我發送了有效載荷并重新加載了屏幕以迎接這個討厭的圖。

又被坑了！即使我們要求 AngularJS 評估一個模板，它也不會給我們 XSS。我們有什么辦法可以繞過這個內容安全政策？

繞過CSP

令人驚奇的是，AngularJS 可以用來繞過 CSP！這樣做的方法大致相當于我的想法，除了我們將注入 HTML 而不是注入模板。等等，這不是倒退嗎？你會看到的 ：）

感謝 Gareth Heyes 所做的一些令人難以置信的研究，我們讓 AngularJS 通過指令來評估 JavaScript 。經過一番擺弄，我想出了以下有效載荷。

     <input ng-focus=$event.view.alert('XSS')>    

這將利用該ng-focus指令來啟動 JavaScript。該$event.view變量將使我們能夠訪問我們需要的所有普通 JavaScript 功能。所以我用這個名字創建了一個應用程序，刷新了頁面，然后……

任務完成！拿那個 CSP！勝利的吶喊！

在確認我沒有產生幻覺后，我截取了一些屏幕截圖并將它們發送到 AWS。

結語

關于這一點，我想指出幾件事。首先是我認為這是一個非常有趣的攻擊場景，可能從 API 訪問到試圖通過 AWS 控制臺攻擊用戶。需要明確的是，這是一種非常罕見的情況。據我所知（和 Google 搜索），在 AWS 控制臺中只發現了一個其他 XSS 錯誤并公開披露。這絕對不是你的普通滲透顧問可以在訂婚時引發的那種事情。但是，對于一個足夠老練的對手來說，在正確的情況下它可能非常方便。

特別是，我認為我們可以在沒有任何權限的情況下在更改歷史中設置 XSS 是非常有趣的。假設的攻擊場景可能是：登陸 EC2 實例 -> 通過基于資源的策略識別 Elastic Beanstalk 正在使用并檢測它的服務相關角色 -> 將有效負載作為沒有 EB 或 CloudTrail 權限的角色發送 -> 等待-> 利潤。

我不確定為什么更改歷史記錄似乎在一段時間內無法運行。它最終回來了，我能夠證明我可以在其中獲得 XSS（見上面的截圖）。

最后，給安全研究人員一點建議；我絕對理解盡快提交您發現的錯誤的興奮。如果其他人找到并先提交怎么辦？如果它在接下來的 30 分鐘內得到修補怎么辦！？雖然，是的，有可能兩個人同時發現相同的錯誤，并且您發現的東西可能會在您通知開發人員之前被修補，但這不太可能發生。相反，最好坐在上面，從頭到尾考慮它（檢查 ANGULAR 的版本），并且只有在你確定你已經盡可能地使用它時才報告它。