![whoAMI 攻击使黑客能够在 Amazon EC2 实例上执行代码]( "whoAMI 攻击使黑客能够在 Amazon EC2 实例上执行代码")
安全研究人员发现了一种名称混淆攻击，任何发布具有特定名称的 Amazon 系统映像 (AMI) 的人都可以访问 Amazon Web 服务帐户。
这次攻击被称为“whoAMI”，由 DataDog 研究人员于 2024 年 8 月策划，他们证明攻击者可以通过利用软件项目检索 AMI ID 的方式来在 AWS 账户内执行代码。
亚马逊确认了该漏洞并于 9 月份发布了修复程序，但在组织未能更新代码的环境中，客户端的问题仍然存在。
AMI 是预先配置了用于创建虚拟服务器所需软件（操作系统、应用程序）的虚拟机，在 AWS 生态系统中称为 EC2（弹性计算云）实例。
AMI 分为公有 AMI 和私有 AMI，每个 AMI 都有特定的标识符。对于公有 AMI，用户可以在 AWS 目录中搜索所需 AMI 的正确 ID。
为了确保 AMI 来自 AWS 市场中的可信来源，搜索需要包含“所有者”属性，否则 whoAMI 名称混淆攻击的风险会增加。
由于 AWS 环境中 AMI 选择配置错误，可能导致 whoAMI 攻击：
-
软件使用 ec2:DescribeImages API 检索 AMI，无需指定所有者
-
-
一些基础设施即代码工具（如 Terraform）的实践是使用“most_recent=true”，自动选择与过滤器匹配的最新 AMI。
这些条件允许攻击者通过将资源命名为与受信任资源类似的名称，在选择过程中插入恶意 AMI。如果不指定所有者，AWS 会返回所有匹配的 AMI，包括攻击者的 AMI。
如果参数“most_recent”设置为“true”，受害者的系统将提供添加到市场的最新 AMI，其中可能包括名称与合法条目相似的恶意 AMI。
![whoAMI 攻击使黑客能够在 Amazon EC2 实例上执行代码]( "whoAMI 攻击使黑客能够在 Amazon EC2 实例上执行代码")
基本上，攻击者需要做的就是发布一个符合可信所有者使用的模式的名称的 AMI，以便用户轻松选择它并启动 EC2 实例。
whoAMI 攻击不需要破坏目标的 AWS 账户。攻击者只需要一个 AWS 账户，将其后门 AMI 发布到公共社区 AMI 目录，并策略性地选择一个模仿其目标 AMI 的名称。
Datadog 表示，根据他们的遥测数据，该公司监控的组织中约有 1% 容易受到 whoAMI 攻击，但“此漏洞可能会影响数千个不同的 AWS 账户”。
DataDog 研究人员向亚马逊通报了该漏洞，该公司确认内部非生产系统容易受到 whoAMI 攻击。
该问题已于去年 9 月 19 日修复，12 月 1 日 AWS 推出了一项名为“允许的 AMI”的新安全控制，允许客户创建受信任的 AMI 提供商的允许列表。
AWS 表示，该漏洞并未在安全研究人员的测试之外被利用，因此没有客户数据通过 whoAMI 攻击受到泄露。
亚马逊建议客户在使用“ec2：DescribeImages”API 时始终指定 AMI 所有者，并启用“允许的 AMI”功能以获得额外保护。
新功能可通过AWS 控制台 → EC2 → 账户属性 → 允许的 AMI获得。
从去年 11 月开始，Terraform 5.77 在未使用所有者过滤器的情况下使用“most_recent = true”时开始向用户发出警告，并计划在未来版本（6.0）中实施更严格的执行。
系统管理员必须审核他们的配置并在 AMI 源（Terraform、AWS CLI、Python Boto3 和 Go AWS SDK）上更新他们的代码以实现安全的 AMI 检索。
要检查当前是否正在使用不受信任的 AMI，请通过“允许的 AMI”启用 AWS 审计模式，然后切换到“强制模式”来阻止它们。
DataDog 还发布了一个扫描程序来检查 AWS 账户中是否存在从不受信任的 AMI 创建的实例，可从此 GitHub 存储库获取。
信息来源：BleepingComputer
原文始发于微信公众号（犀牛安全）：whoAMI 攻击使黑客能够在 Amazon EC2 实例上执行代码
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/3786819.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论