Rumors are swirling on hacker forums about a potential breach at Huge Logistics. Your team has been monitoring these conversations closely, and Huge Logistics has asked you to assess the security of their website. Beyond the surface-level assessment, you're also to investigate links to their cloud infrastructure, mapping out any potential risk exposure. The question isn't just if they've been compromised, but how deep the rabbit hole goes.
题目提供的信息：52.6.119.121
真实场景
Capital One 数据泄露就是由于 SSRF 漏洞获取 EC2 的元数据（metadata），从而访问到 AWS S3 桶的敏感数据
访问 IP 重定向到域名 hugelogistics.pwn
绑定 host 访问
whois 查看 52.6.119.121 ip 信息，ip 是 EC2 实例的
f12 查看网站代码，发现
huge-logistics-storage 桶但文件拿不下来
继续回去看网站，在右上角 status 会访问到以下页面，点 Check 估计会去请求探测可用性
把 name 参数 改为 AWS 的元数据 IP
169.254.169.254，能访问
访问
169.254.169.254/latest/meta-data/ 元数据一般有这些
访问
169.254.169.254/latest/meta-data/iam/info 查看 iam arn，角色为 MetapwnedS3Access
根据角色名获取 sts，访问
169.254.169.254/latest/meta-data/iam/security-credentials/MetapwnedS3Access
查看下身份
这时候再来访问桶的东西
防御
- 使用 IMDSv2 在这种场景下可以防御（2023.11 后默认都是 v2）
- 通过这个 guide 禁用掉元数据
- 编辑好桶 ACL，不应该公共可列桶
进一步阅读
- https://hackerone.com/reports/53088 - 允许发起外部 HTTP 请求导致请求元数据
- https://blog.appsecco.com/finding-ssrf-via-html-injection-inside-a-pdf-file-on-aws-ec2-214cc5ec5d90 - HTML 页面作为 PDF 下载时，服务端把 HTML 转换为 PDF，并提供预览（这就顶多是XSS），直接在 HTML 嵌入 iframe 标签，服务端请求渲染在 PDF 上，就导致可以请求元数据，把结果反回来
- https://cloud.google.com/blog/topics/threat-intelligence/cloud-metadata-abuse-unc2903/ - Adminer 数据库登录连接存在 SSRF，52.170.213.50:1337 是攻击者多服务器，上面搞个 301 重定向，重定向到 元数据地址。然后Adminer数据库连接驱动默认都是跟随重定向的，如果 Adminer 部署在 AWS EC2 等上
就可以通过报错查看到返回到数据了，妙！
