研究人员发现 Amazon ECS 中的 ECScape 漏洞可导致跨任务凭证盗窃

2025-08-07 08:22:02 0 146

研究人员在黑帽大会上披露,Amazon ECS 存在“ECScape”漏洞,攻击者可通过模拟 ECS 代理窃取同一 EC2 实例上其他容器的 IAM 凭证,实现权限提升和横向移动。该漏洞源于 ECS 元数据服务的信任机制缺陷,影响共享主机上的任务隔离性。建议使用 AWS Fargate 实现真正隔离、禁用元数据服务访问并最小化权限,以防止凭证泄露及云环境控制权被窃取。该事件反映出云服务隔离机制的潜在风险。



网络安全研究人员展示了亚马逊弹性容器服务( ECS )中的“端到端权限提升链”,攻击者可以利用该链进行横向移动、访问敏感数据并控制云环境。

Sweet Security 研究员 Naor Haziz 将这一攻击技术命名为 ECScape,他今天在拉斯维加斯举行的美国黑帽安全会议上公布了这一研究成果。

Haziz 在与 The Hacker News 分享的一份报告中表示: “我们发现了一种滥用未记录的 ECS 内部协议的方法,可以获取同一 EC2 实例上其他 ECS 任务的 AWS 凭证。具有低权限 IAM(身份和访问管理)角色的恶意容器可以获得在同一主机上运行的高权限容器的权限。”

Amazon ECS 是一种完全托管的容器编排服务,允许用户部署、管理和扩展容器化应用程序,同时与 Amazon Web Services (AWS) 集成以在云中运行容器工作负载。

Sweet Security 发现的漏洞本质上允许权限提升,通过允许在 ECS 实例上运行的低权限任务窃取其凭证来劫持同一 EC2 机器上高权限容器的 IAM 权限。

换句话说,ECS 集群中的恶意应用程序可以承担更高权限任务的角色。这可以通过利用在 169.254.170[.]2 上运行的元数据服务来实现,该服务会公开与任务的 IAM 角色关联的临时凭证。

网络安全
虽然这种方法可以确保每个任务都能获得其 IAM 角色的凭证,并在运行时交付,但 ECS 代理身份的泄露可能会让攻击者冒充代理并获取主机上任何任务的凭证。整个过程如下:

获取主机的 IAM 角色凭证(EC2 实例角色),以模拟代理
发现代理与之通信的 ECS 控制平面端点
收集必要的标识符(集群名称/ARN、容器实例 ARN、代理版本信息、Docker 版本、ACS 协议版本和序列号),以使用任务元数据端点和 ECS 自检 API 进行代理身份验证
伪造并签署代理通信服务 (ACS) WebSocket 请求,冒充代理,并将 sendCredentials 参数设置为“true”
收集该实例上所有正在运行的任务的凭证
“伪造的代理通道也保持了隐秘性,”哈齐兹说。“我们的恶意会话模仿了代理的预期行为——确认消息、增加序列号、发送心跳——所以看起来没什么不对劲。”

通过模拟代理的上游连接,ECScape 完全破坏了该信任模型:一个受感染的容器可以被动收集同一 EC2 实例上每个其他任务的 IAM 角色凭证,并立即使用这些权限采取行动。”

在共享 EC2 主机上运行 ECS 任务时,ECScape 可能会产生严重后果,因为它为跨任务权限提升、机密泄露和元数据泄露打开了大门。

在负责任地披露之后,亚马逊强调客户需要在适用的情况下采用更强大的隔离模型,并在其文档中明确指出EC2 中没有任务隔离,并且“容器可以访问同一容器实例上其他任务的凭证”。

作为缓解措施,建议避免在同一实例上部署高权限任务以及不受信任或低权限任务,使用 AWS Fargate 进行真正的隔离,禁用或限制任务的实例元数据服务 (IMDS) 访问,限制 ECS 代理权限,并设置 CloudTrail 警报以检测 IAM 角色的异常使用情况。


“核心教训是,你应该将每个容器视为潜在的易受攻击对象,并严格限制其影响范围,”Haziz 说。“AWS 便捷的抽象(任务角色、元数据服务等)让开发人员的工作更加轻松,但当多个具有不同权限级别的任务共享一个底层主机时,它们的安全性仅与隔离它们的机制一样强——而这些机制可能存在微妙的弱点。”

身份安全风险评估
近期,云计算相关的安全漏洞频频出现,而此次事件正是在这样的背景下发生的:

Google Cloud Build 的 GitHub 集成中存在竞争条件,可能允许攻击者在维护者发出“/gcbrun”命令后绕过维护者审核并构建未经审核的代码
Oracle 云基础设施 (OCI) 代码编辑器中存在远程代码执行漏洞,攻击者可利用该漏洞劫持受害者的 Cloud Shell 环境,并通过诱骗已登录 Oracle 云的受害者访问服务器上托管的恶意 HTML 页面,从而可能在 OCI 服务之间切换。
一种名为I SPy的攻击技术,利用 Entra ID 中 Microsoft 第一方应用程序的服务主体 (SP),通过联合身份验证实现持久性和权限提升
Azure 机器学习服务中存在权限提升漏洞,仅具有存储帐户访问权限的攻击者可以修改存储在 AML 存储帐户中的调用程序脚本,并在 AML 管道内执行任意代码,从而能够从 Azure Key Vault 中提取机密信息、提升权限并获得对云资源的更广泛访问权限
旧版AmazonGuardDutyFullAccess AWS 托管策略中存在一个范围漏洞,该漏洞可能允许通过注册任意委派管理员从受损成员账户全面接管组织
一种利用Azure Arc进行权限提升的攻击技术,利用 Azure Connected Machine 资源管理员角色,并通过设置为命令和控制 (C2)作为持久机制
Azure 内置读者角色权限过高的情况以及 Azure API 中的漏洞可能会被攻击者利用,从而泄露 VPN 密钥,然后使用该密钥获取内部云资产和本地网络的访问权限
Google Gerrit 中存在一个供应链漏洞,名为 GerriScary,该漏洞允许向至少 18 个 Google 项目提交未经授权的代码,包括 ChromiumOS(CVE-2025-1568,CVSS 评分:8.8)、Chromium、Dart 和 Bazel,利用默认“addPatchSet”权限中的错误配置、投票系统的标签处理以及代码合并过程中与机器人代码提交时间的竞争条件
Google 云平台配置错误,导致互联网交换点 (IXP) 用于成员交换的子网暴露,从而使攻击者有可能滥用 Google 的云基础设施来获取对内部 IXP LAN 的未经授权的访问。
谷歌云权限提升漏洞ConfusedFunction的扩展,可以分别使用 AWS Lambda 和 Azure Functions 适应其他云平台,例如 AWS 和 Azure,此外还可以扩展它来执行环境枚举
Talos 表示:“保护您的环境免受类似威胁行为者行为侵害的最有效缓解策略是确保云环境中的所有服务帐户 (SA) 都遵循最小特权原则,并且不再使用任何旧版云服务帐户 (SA)。确保所有云服务和依赖项都已安装最新的安全补丁。如果存在旧版服务帐户 (SA),请将其替换为最小特权服务帐户 (SA)。

关于作者

zsc081043篇文章89篇回复

评论0次

要评论?请先  登录  或  注册