黑客利用 whoAMI 攻击在亚马逊 EC2 实例上执行代码
HackerNews 编译，转载请注明出处： 安全研究人员发现了一种名为“whoAMI”的名称混淆攻击，该攻击允许任何人通过发布具有特定名称的亚马逊机器镜像（AMI）来访问亚马逊网络服务（AWS）账户。 “whoAMI”攻击由 DataDog 研究人员于 2024 年 8 月提出，他们证明了攻击者可以通过利用软件项目检索 AMI ID 的方式，在 AWS 账户内获得代码执行权限。 亚马逊确认了这一漏洞，并在 9 月推出了修复措施，但问题在客户侧仍然存在，尤其是在组织未能更新代码的环境中。 实施“whoAMI”攻击 AMI 是预配置了必要软件（操作系统、应用程序）的虚拟机，用于创建在 AWS 生态系统中称为 EC2（弹性计算云）实例的虚拟服务器。 AMI 有公共和私有之分，每个都有特定的标识符。对于公共 AMI，用户可以在 AWS 目录中搜索所需的 AMI ID。 为了确保 AMI 来自 AWS 市场中的可信来源，搜索需要包含“所有者”属性，否则“whoAMI”名称混淆攻击的风险会增加。 “whoAMI”攻击之所以能够实现，是由于 AWS 环境中 AMI 选择的配置错误： 软件使用 ec2:DescribeImages API 检索 AMI 时未指定所有者 脚本使用通配符而不是具体的 AMI ID 一些基础设施即代码（IaC）工具（如 Terraform）使用“most_recent=true”，自动选择符合过滤条件的最新 AMI 这些条件允许攻击者通过命名资源与受信任的资源相似来插入恶意 AMI。如果没有指定所有者，AWS 会返回所有匹配的 AMI，包括攻击者的 AMI。 如果参数“most_recent”被设置为“true”，受害者的系统会提供最新添加到市场中的 AMI，这可能包括一个名称与合法条目相似的恶意 AMI。 演示检索恶意 AMI 而不是受信任的 AMI 攻击者只需发布一个符合受信任所有者使用的模式的 AMI 名称，用户就很容易选择它并启动一个 EC2 实例。 “whoAMI”攻击不需要突破目标的 AWS 账户。攻击者只需要一个 AWS 账户，将他们的后门 AMI 发布到公共社区 AMI 目录中，并战略性地选择一个模仿目标 AMI 的名称。 DataDog 表示，根据他们的遥测数据，他们监控的大约 1% 的组织容易受到“whoAMI”攻击，但“这一漏洞可能影响数千个不同的 AWS 账户”。 亚马逊的回应和防御措施 DataDog 研究人员通知了亚马逊这一漏洞，该公司确认内部非生产系统容易受到“whoAMI”攻击。 问题在 2024 年 9 月 19 日得到修复，12 月 1 日，AWS 引入了一个名为“Allowed AMIs”的新安全控制功能，允许客户创建受信任 AMI 提供商的允许列表。 AWS 表示，除了安全研究人员的测试外，该漏洞未被利用，因此没有客户数据通过“whoAMI”攻击被泄露。 亚马逊建议客户在使用“ec2:DescribeImages”API 时始终指定 AMI 所有者，并启用“Allowed AMIs”功能以获得额外保护。 新功能可通过 AWS 控制台 → EC2 → 账户属性 → Allowed AMIs 访问。 从 2024 年 11 月开始，Terraform 5.77 在使用“most_recent = true”而没有所有者过滤器时开始向用户发出警告，并计划在未来的版本（6.0）中实施更严格的措施。 系统管理员必须审查他们的配置并更新 AMI 源代码（Terraform、AWS CLI、Python Boto3 和 Go AWS SDK），以安全地检索 AMI。 要检查是否正在使用不受信任的 AMI，可以通过“Allowed AMIs”启用 AWS 审计模式，并切换到“强制模式”以阻止它们。 DataDog 还发布了一个扫描器，用于检查 AWS 账户中由不受信任的 AMI 创建的实例，可在 GitHub 仓库 中获取。 消息来源：Bleeping Computer； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文