AWS 控制台中的 XSS

可以想象，对 AWS API 进行模糊测试并非易事。有数百种 AWS 服务和数千种可能的操作。再加上无数的参数相结合，每个协议都有不同的格式、不同的区域、不同的版本以及我们想要使用的所有类型的输入，这使得它非常耗时。

为了增加这个难度，我将合法流量发送到 API，这反过来可以创建需要花钱的资源。结果，我一直盯着计费仪表板，并删除创建的任何内容。我还一直在浏览 AWS 控制台以查找任何错误。

在这些检查过程中，我偶然发现了 Elastic Beanstalk 更改历史记录中的一条错误消息。

AWS Elastic Beanstalk 是一项易于使用的服务，用于在熟悉的服务器（例如 Apache 、Nginx、Passenger 和 IIS ）上部署和扩展使用 Java、.NET、PHP、Node.js、Python、Ruby、GO 和 Docker 开发的 Web 应用程序和服务。

你只需上传代码，Elastic Beanstalk 即可自动处理包括容量预配置、负载均衡、自动扩展和应用程序运行状况监控在内的部署工作。同时，你能够完全控制为应用程序提供支持的 AWS 资源，并可以随时访问底层资源。

Elastic Beanstalk 不额外收费 – 你只需为存储和运行应用程序所需的 AWS 资源付费。

经过一番分析，我突然明白了，这是一个安全隐患。

那么，什么是“b.requestParameters”，为什么 AWS 控制台不认为它是 null？通过分析，在 beanstalk-xp_en.min.js 的第 17240 行（该行号来自美化的 JS 输出）有对 b.requestParameters 的引用。

通过调试器，可以清楚地看到“更改历史记录”页面正在从 CloudTrail 加载事件并显示它们，详情请点击这里。

Elastic Beanstalk 的更改历史记录功能是一项非常新的功能（于 2021 年 1 月发布），允许你查看 EB 环境配置的更改。

这并没有回答为什么b.requestParameters是null，发生了什么?从调试来看，很明显它是在CloudTrail事件上寻找一个特定的属性，而模糊器没有提供它。在CloudTrail中查找那个特定事件，可以肯定的是，在尝试更新环境操作时我没有提供任何参数，因此 requestParameters 为null。

最后我们找到了罪魁祸首，但是我们该如何处理我们新发现的漏洞呢？

HTML 注入

从 JavaScript 来看，很明显我们对两个值有高度的控制。那些是用户代理和环境名称。此外，这些值似乎被直接插入到 DOM 中。

我会想到跨站点脚本 (XSS) 攻击，但 AWS 通常非常擅长在浏览器中呈现内容之前对其进行清理。这是我在使用 SSM 代理时遇到的第一手经验。因此，我认为任何恶意内容都会在显示之前被清理干净。

为了测试这一点，我将一个破损图像标记的简单有效载荷放在一起(我有意将源设置为“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发了一封邮件，里面有一些截屏。对于不能再次填充更改历史(即使是真正的应用程序)感到失望，就在这个时候，我发现使用的是AngularJS而不是Angular。

模板注入

当意识到页面使用了AngularJS时，引入了另一种我们可以尝试的注入攻击，客户端模板注入。当攻击者可以提供自己的模板语言输入时，就会发生模板注入攻击。这将导致在用户的浏览器中对这些输入进行评估。例如(取决于模板格式)，你可以插入{{2+2}}，它的值是4。

在对自己之前没有意识到AngularJS的情况感到非常失望之后，我创建了一个带有模板名称的应用程序，并刷新了浏览器。

我们已经确认它容易受到模板注入的影响，但我们可以从哪里开始呢？好消息是 PortSwigger 的 Gareth Heyes 在这方面做了大量的研究。

简而言之，我们可以利用模板注入作为一种方法来执行任意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。经过一些修改，我想出了以下有效载荷。

这将利用 ng-focus 指令来启动 JavaScript。$event.view 变量可以让我们访问我们需要的所有普通 JavaScript 功能。所以我用这个名字创建了一个应用程序，刷新了页面，然后……

任务完成。

在确认没有问题后，我截取了一些屏幕截图并将它们发送到 AWS。

总结

首先，我认为这是一个非常有趣的攻击场景，可能从 API 访问到尝试通过 AWS 控制台攻击用户。需要明确的是，这是一种非常罕见的情况。据我所知，在 AWS 控制台中只发现了一个其他的 XSS 漏洞并进行了公开披露。需要指出的是，我认为我们可以在没有任何权限的情况下在更改历史记录中设置 XSS，这非常有趣。假设的攻击场景可能是：登陆 EC2 实例 -> 通过基于资源的策略识别正在使用 Elastic Beanstalk 并检测它的服务相关角色 -> 作为没有 EB 或 CloudTrail 权限的角色发送有效负载 -> 等待攻击结果。

我不确定为什么更改历史记录似乎在一段时间内不起作用，不过还好它最好还能发挥作用，我也能够证明我可以在其中获得 XSS。

原文来自: 4hou.com