标题：AWS SSRF to Root on production instance — A bug worth 1.75Lacs 作者：Avinash Jain (@logicbomb) 原文地址：https://logicbomb.medium.com/a-bug-worth-1-75lacs-aws-ssrf-to-rce-8d43d5fda899

我已经有一段时间没有写博客了，主要是因为在过去 6-7 个月的 bug 赏金中我找不到新的东西。幸运的是，这个月我在交易平台中发现的一个不错的漏洞。让我们直接开始讨论漏洞，尽量保持简短明了，所以就到这里吧。这是关于——

我如何升级著名的 AWS SSRF 以在印度一家成长中的交易初创公司中执行远程代码执行 (RCE)

我手动遍历应用程序的不同部分以查找一些敏感的 API 端点，同时我将目标范围添加到 Burpsuite 中的“Crawl and Audit”中。在该应用程序中，有一个常见的“密码重置”功能。仔细观察端点，有一个参数“return_url”。这些参数总是有可能带来一些容易发现的错误。当 Burpsuite 在同一端点发现“外部服务交互 (DNS)”漏洞时，我的期望被证明是正确的。在检查不同的 HTTP 请求标头时，很明显该应用程序是通过 AWS 进行的，因为我可以看到响应标头为 X-Amz-Cf-Id，并且还有一个用于获取个人资料照片的 S3 存储桶交互。

下一步的行动很明确，就是检查是否存在可能的 SSRF。我尝试访问 AWS 元数据 URL (http://169.254.169.254/latest/meta-data/)，下面是对 CURL 请求的响应 -

从实例元数据中获取安全凭证 -

这对我来说证实了 SSRF。

现在是时候进一步扩展它了，这是人们应该始终尝试做的事情 -

通过尝试与其相关的所有可能性来升级漏洞。这将增加错误的影响并获得更好的奖励。

AWS 提供了一项名为 AWS System manager 的服务来管理在 AWS 云中运行的应用程序和基础设施，该服务也可以由命令行工具使用。参考 — https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html

这里对我有利的一件事是为了通过 SSM 在实例中运行远程命令，它应该具有附加到实例的相关角色。

1. 使用上述安全凭证安装和配置 AWS CLI。

   $ export AWS_ACCESS_KEY_ID=
   $ export AWS_SECRET_ACCESS_KEY=
   $ export AWS_DEFAULT_REGION=
   $ export AWS_SESSION_TOKEN=
   

2. 以下命令可用于查找第一步中使用的区域 - http://169.254.169.254/latest/meta-data/placement/availability-zone

3. 使用send-command执行命令，查询如下-

   $ aws ssm send-command --document-name "AWS-RunShellScript" --comment "AnyComment" --instance-ids="[Instance-id]" --parameters "commands=whoami"
   

   该命令的输出提供了一个 CommandId

4. 获取第三步中使用的实例 ID - http://169.254.169.254/latest/meta-data/instance-id

5. 最后一步查看所执行命令的输出（如步骤 3“whoami”中使用的）-

   $ aws ssm list-command-invocations --command-id="[Command_Id]" --details
   

唷，终于我能够执行命令了。可以看到输出为“root”！这就是我将 AWS SSRF 升级为 RCE 的方法。这就是这篇简短的文章的内容。