可以想象，對 AWS API 進(jìn)行模糊測試并非易事。有數(shù)百種 AWS 服務(wù)和數(shù)千種可能的操作。再加上無數(shù)的參數(shù)相結(jié)合，每個協(xié)議都有不同的格式、不同的區(qū)域、不同的版本以及我們想要使用的所有類型的輸入，這使得它非常耗時。

為了增加這個難度，我將合法流量發(fā)送到 API，這反過來可以創(chuàng)建需要花錢的資源。結(jié)果，我一直盯著計費(fèi)儀表板，并刪除創(chuàng)建的任何內(nèi)容。我還一直在瀏覽 AWS 控制臺以查找任何錯誤。

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

AWS Elastic Beanstalk 是一項易于使用的服務(wù)，用于在熟悉的服務(wù)器（例如 Apache 、Nginx、Passenger 和 IIS ）上部署和擴(kuò)展使用 Java、.NET、PHP、Node.js、Python、Ruby、GO 和 Docker 開發(fā)的 Web 應(yīng)用程序和服務(wù)。

你只需上傳代碼，Elastic Beanstalk 即可自動處理包括容量預(yù)配置、負(fù)載均衡、自動擴(kuò)展和應(yīng)用程序運(yùn)行狀況監(jiān)控在內(nèi)的部署工作。同時，你能夠完全控制為應(yīng)用程序提供支持的 AWS 資源，并可以隨時訪問底層資源。

Elastic Beanstalk 不額外收費(fèi) – 你只需為存儲和運(yùn)行應(yīng)用程序所需的 AWS 資源付費(fèi)。

經(jīng)過一番分析，我突然明白了，這是一個安全隱患。

那么，什么是“b.requestParameters”，為什么 AWS 控制臺不認(rèn)為它是 null？通過分析，在 beanstalk-xp_en.min.js 的第 17240 行（該行號來自美化的 JS 輸出）有對 b.requestParameters 的引用。

通過調(diào)試器，可以清楚地看到“更改歷史記錄”頁面正在從 CloudTrail 加載事件并顯示它們，詳情請點(diǎn)擊這里。

Elastic Beanstalk 的更改歷史記錄功能是一項非常新的功能（于 2021 年 1 月發(fā)布），允許你查看 EB 環(huán)境配置的更改。

這并沒有回答為什么b.requestParameters是null，發(fā)生了什么?從調(diào)試來看，很明顯它是在CloudTrail事件上尋找一個特定的屬性，而模糊器沒有提供它。在CloudTrail中查找那個特定事件，可以肯定的是，在嘗試更新環(huán)境操作時我沒有提供任何參數(shù)，因此 requestParameters 為null。

最后我們找到了罪魁禍?zhǔn)?，但是我們該如何處理我們新發(fā)現(xiàn)的漏洞呢？

HTML 注入

從 JavaScript 來看，很明顯我們對兩個值有高度的控制。那些是用戶代理和環(huán)境名稱。此外，這些值似乎被直接插入到 DOM 中。

我會想到跨站點(diǎn)腳本 (XSS) 攻擊，但 AWS 通常非常擅長在瀏覽器中呈現(xiàn)內(nèi)容之前對其進(jìn)行清理。這是我在使用 SSM 代理時遇到的第一手經(jīng)驗。因此，我認(rèn)為任何惡意內(nèi)容都會在顯示之前被清理干凈。

為了測試這一點(diǎn)，我將一個破損圖像標(biāo)記的簡單有效載荷放在一起(我有意將源設(shè)置為“x”)。我喜歡使用這個作為測試，因為如果它被渲染，它會給我一個很好的視覺指示，否則我只會看到編碼的值。

我修改了我的框架，將用戶代理設(shè)置為有效負(fù)載，點(diǎn)擊發(fā)送并等待。在等待了10分鐘后，我刷新了控制臺并被驚呆了。

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

雖然 CSP 不能緩解跨站點(diǎn)腳本攻擊，但它可以緩解影響。在本例中，CSP 阻止了內(nèi)嵌腳本，這導(dǎo)致我的 XSS 負(fù)載失敗。

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

有趣的是，你只需要與帳戶關(guān)聯(lián)的有效憑據(jù)即可運(yùn)行。這些憑證不需要 Elastic Beanstalk 或 CloudTrail 權(quán)限。此更改歷史記錄儀表板也會加載失敗的嘗試。因此，即使你對某個角色或用戶擁有零權(quán)限，你更新 Elastic Beanstalk 環(huán)境的嘗試也會顯示出來。

iframe 注入

由于沒有找到繞過 CSP 的方法，我向一些朋友尋求想法。在和我的朋友Chris聊天時(查看他在schneidersec.com的博客)，他注意到iframe部分有一些有趣的東西。

內(nèi)容安全策略允許你從與控制臺設(shè)置在同一區(qū)域的 S3 存儲桶加載 iframe。我們都對此感到驚訝，難道你不能創(chuàng)建自己的存儲桶并托管 HTML 嗎？我們不明白為什么不這樣做，所以我創(chuàng)建了一個 S3 存儲桶，放入了一些 HTML 并更改了我的負(fù)載以創(chuàng)建一個 iframe。這導(dǎo)致了這個：

實(shí)際上，你可以從 S3 存儲桶加載 iframe！

提交給 AWS

沒有看到通過 HTML/iframe 注入解決的 CSP 的明顯方法。當(dāng)然，我的意思是 AWS 控制臺中的任何漏洞都是整潔的，但 HTML 注入對于滲透測試報告來說是多余的。無論哪種方式，我都向 AWS 漏洞披露計劃發(fā)送了一封電子郵件以及一些屏幕截圖和概念證明（將HTML有效負(fù)載粘貼到用戶代理中用于更新環(huán)境API調(diào)用的Python腳本）。

AWS 安全團(tuán)隊迅速做出回應(yīng)，并表示他們已將信息轉(zhuǎn)發(fā)給服務(wù)團(tuán)隊。這樣我等了大約兩周，并注意到我的“更改歷史記錄”頁面中不再有任何事件。為此，我專門創(chuàng)建了一些新的 CloudTrail 事件，但它們?nèi)匀粵]有出現(xiàn)。

“也許他們現(xiàn)在對事件有了驗證?”要么檢查惡意輸入，要么檢查它是否影響現(xiàn)有環(huán)境?”我可以看出，負(fù)責(zé)構(gòu)建表的JavaScript已經(jīng)被修改了，但是它被縮小了，并且區(qū)分新舊外觀太耗時了。因此，我創(chuàng)建了一個合法的Elastic Beanstalk應(yīng)用程序和環(huán)境。當(dāng)我這樣做的時候，我想看看是否有其他的字段也容易受到HTML注入的影響，確實(shí)有一些字段。示例如下：

為了提供幫助，我又給AWS發(fā)了一封郵件，里面有一些截屏。對于不能再次填充更改歷史(即使是真正的應(yīng)用程序)感到失望，就在這個時候，我發(fā)現(xiàn)使用的是AngularJS而不是Angular。

模板注入

當(dāng)意識到頁面使用了AngularJS時，引入了另一種我們可以嘗試的注入攻擊，客戶端模板注入。當(dāng)攻擊者可以提供自己的模板語言輸入時，就會發(fā)生模板注入攻擊。這將導(dǎo)致在用戶的瀏覽器中對這些輸入進(jìn)行評估。例如(取決于模板格式)，你可以插入{{2+2}}，它的值是4。

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

我們已經(jīng)確認(rèn)它容易受到模板注入的影響，但我們可以從哪里開始呢？好消息是 PortSwigger 的 Gareth Heyes 在這方面做了大量的研究。

簡而言之，我們可以利用模板注入作為一種方法來執(zhí)行任意JavaScript并獲得跨站點(diǎn)腳本！以前，這需要一些工作來轉(zhuǎn)義Angular表達(dá)式沙箱，然而，在AngularJS 1.6中，沙箱被刪除了。因為我們使用的是1.8.1，所以我們不必?fù)?dān)心它，相反，我們可以使用以下有效載荷，詳情請點(diǎn)擊這里。

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

這將允許我們運(yùn)行傳統(tǒng)的警報XSS有效負(fù)載，但它會通過內(nèi)容安全策略嗎？我實(shí)際上并不確定。

我的想法是我沒有注入一個新的腳本標(biāo)簽，我只是要求 AngularJS 評估一個模板表達(dá)式，因為 AngularJS 已經(jīng)被允許，它不會工作嗎？這不是真正的內(nèi)聯(lián)評估嗎？所以我發(fā)送了有效載荷并重新加載了屏幕，以期待成功。

又失敗了，即使我們要求AngularJS計算一個模板，它也不會讓我們得到XSS。有什么辦法可以繞過這個內(nèi)容安全政策嗎？

繞過 CSP

令人驚奇的是，AngularJS 可以用來繞過 CSP！這樣做的方法與我的想法大致相同，只是我們不是注入一個模板，而是注入HTML。

感謝 Gareth Heyes 的一些令人難以置信的研究，我們讓AngularJS通過指令來計算JavaScript。經(jīng)過一些修改，我想出了以下有效載荷。

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

任務(wù)完成。

在確認(rèn)沒有問題后，我截取了一些屏幕截圖并將它們發(fā)送到 AWS。

總結(jié)

首先，我認(rèn)為這是一個非常有趣的攻擊場景，可能從 API 訪問到嘗試通過 AWS 控制臺攻擊用戶。需要明確的是，這是一種非常罕見的情況。據(jù)我所知，在 AWS 控制臺中只發(fā)現(xiàn)了一個其他的 XSS 漏洞并進(jìn)行了公開披露。需要指出的是，我認(rèn)為我們可以在沒有任何權(quán)限的情況下在更改歷史記錄中設(shè)置 XSS，這非常有趣。假設(shè)的攻擊場景可能是：登陸 EC2 實(shí)例 -> 通過基于資源的策略識別正在使用 Elastic Beanstalk 并檢測它的服務(wù)相關(guān)角色 -> 作為沒有 EB 或 CloudTrail 權(quán)限的角色發(fā)送有效負(fù)載 -> 等待攻擊結(jié)果。

我不確定為什么更改歷史記錄似乎在一段時間內(nèi)不起作用，不過還好它最好還能發(fā)揮作用，我也能夠證明我可以在其中獲得 XSS。

參考及來源：https://frichetten.com/blog/xss_in_aws_console/