文章总结： 本文揭示了AWSIAM最终一致性导致的安全漏洞，攻击者可在密钥删除后的约4秒传播窗口内利用旧凭证创建新密钥或移除限制策略，实现持久化访问。传统轮换和策略限制措施在此期间无效。建议利用AWSOrganizations服务控制策略（SCP）进行账户层封锁，优先使用STS临时凭证，并加强红队演练以防御此类风险。
综合评分： 95
文章分类： 云安全,红队,漏洞分析,应急响应,实战经验
利用AWS IAM最终一致性实现持久化访问
Dubito
云原生安全指北
2025年12月18日 08:36
江苏
注：本文翻译自OFFENSAI的文章《Exploiting AWS IAM Eventual Consistency for Persistence》[1]，可点击文末“阅读原文”按钮查看英文原文。
全文如下：
一、引言
已删除失陷的 AWS 访问密钥？但由于 AWS IAM 的最终一致性（eventual consistency），它们可能依然有效。OFFENSAI 的研究揭示了 AWS IAM 最终一致性如何创造一个攻击者可以利用的持久化窗口，在此期间，诸如访问密钥删除或策略更新等操作不会立即生效。
我们发现，禁用 AWS 访问密钥时存在一个陷阱，该问题同样存在于其他 AWS IAM 资源中。其根源在于 AWS 身份和访问管理的最终一致性。如果处理不当，攻击者便可利用此漏洞，在防御者以为凭证已撤销后，仍然能访问您的 AWS 环境。
这为传统的 AWS 访问密钥轮换和撤销流程增加了一层新的风险。
二、理解最终一致性
为庞大的用户群构建全球分布式的系统具有挑战性。处理日常计算负载通常需要按多个维度进行扩展，正如 AKF Scale Cube 所描述的：
- • 水平扩展（X 轴）：通过在多个服务器或区域克隆/复制相同的实例
- • 功能扩展（Y 轴）：通过将系统按不同功能分解为独立的服务/微服务
- • 数据分片扩展（Z轴）：通过将相似的数据或用户拆分到不同的分片或分区
虽然这些扩展策略提升了系统性能和可用性，但它们也给数据一致性带来了复杂性。当数据跨多个区域或数据库副本复制时，更新不会瞬时传播。这会造成一个时间窗口，在此期间，系统的不同部分对同一数据可能拥有不同的视图。让我们来看一个通用示例：
场景：管理员将用户权限从”管理员”降级为”只读”。用户权限数据库在多个区域拥有只读副本。
- • T+0秒：权限降级操作写入主数据库（美国东部）
- • T+1秒：用户（位于欧盟区域）删除了关键数据——此时欧盟副本仍显示其为”管理员” ✓
- • T+2秒：用户修改了系统设置——仍然拥有提升的访问权限 ✓
- • T+4秒：欧盟副本更新完成——用户最终失去管理员权限 ✗
分布式系统中关于授权的一致性挑战
虽然系统最终会达到一致状态，但在一个4秒的窗口期内，该用户仍保留着未授权的管理员访问权限。对于许多用例而言，最终一致性通常是可以接受的。但正如我们接下来将详述的，在弱一致性架构中处理授权时，会出现特殊的安全隐患。
三、轮换 AWS 访问密钥时的安全风险
考虑以下这种不当禁用 AWS 访问密钥的常见场景：
一套访问密钥被发现已泄露，安全团队（
defender）尝试直接禁用或删除该密钥。假设用户’bob’的账户被入侵，攻击者将其权限提升至管理员。若配置文件为defender，以下命令将在防御者的机器上执行；若配置文件为attacker，命令将在攻击者的机器上执行。
你认为当下面两个命令相继执行时会发生什么？
# 安全团队轮换已泄露的访问密钥
aws --profile defender iam delete-access-key --access-key-id AKIA3P... --user-name bob
# 攻击者在密钥被删除后立即创建新的访问密钥
aws --profile attacker iam create-access-key --user-name bob
如果攻击者在防御者执行命令后立即执行其命令，由于最终一致性，已删除的密钥在一段时间内仍被视为有效。这确实很投机，但正如我们稍后将看到的，这个问题是可以克服的。
已删除的访问密钥仍可能被使用
安全风险窗口：
- • T+0秒：安全团队删除用户
bob的已泄露 AWS 访问密钥 - • T+1至3秒：攻击者使用已被删除的相同密钥来创建一套新的访问密钥
- • T+4秒：IAM 传播完成——旧密钥完全失效
风险所在：AWS 基础设施的分布式特性意味着，凭证验证层、缓存层和边缘服务可能会造成短暂的时间窗口，使得已撤销的访问密钥在一段时间内仍然有效。简而言之，攻击者可以利用一套已删除的访问密钥来创建新的密钥，以此实现持久化访问。
3.1 AWS IAM 可预测的“最终”一致性
当涉及传播时间时，AWS 的最终一致性表现得非常一致。在我们进行的每一次测试中，无论防御者/攻击者所在区域是 us-east-1/eu-central-1，还是两者位于同一区域，传播时间都始终接近但略小于 4 秒。
访问密钥被删除后仍存在 3-4 秒的使用时间窗口
3.2 消除机会主义因素
防御者删除密钥后，攻击者在约 4 秒的可用窗口期内创建新的 AWS 访问密钥，这种场景极具机会主义色彩。但情况并非必须如此。在这约 4 秒内，攻击者可以发起任何请求，包括列出您用户的访问密钥。奇怪的是，当您在删除后的约 4 秒内列出访问密钥时，您会得到一个空数组，这表明密钥确实已被删除。
密钥删除不当时造成的持久化风险。
攻击者可以通过 IAM ListAccessKeys API 调用，每 3 秒检查一次其密钥是否被删除。当响应为空数组时，意味着密钥已被删除。此时，攻击者可以在达到最终一致性之前的剩余时间窗口内，创建一套新的 AWS 访问密钥。
四、当前事件响应预案中的不足
在安全事件期间应对 AWS IAM 最终一致性问题，带来的挑战比预期更大。传统修复方法难以妥善处理，挑战程度可见一斑。
4.1 基于策略的限制措施无效
尝试通过 AWS IAM 策略来限制被入侵的用户，同样易受此问题影响。即使您为该用户添加了 AWSDenyAll 或会话策略，攻击者仍有约 4 秒的时间窗口来检测新策略并将其移除。禁用访问凭证也存在相同问题。
# 这种方法在一致性窗口期内会失效
aws --profile defender iam attach-user-policy \
--user-name compromised-user --policy-arn arn:aws:iam::aws:policy/AWSDenyAll
4.2 有效的缓解策略
最可靠的方法是利用 AWS Organizations 服务控制策略，该策略在账户层级生效。鉴于攻击者无法控制 SCP，这将阻止他们检测和修改 SCP。
- 1. 应用一个 SCP，拒绝被入侵主体执行所有操作。
- 2. 等待完整的约 4 秒传播期结束。
- 3. 随后执行传统的密钥轮换和策略清理。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCompromisedUser",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:user/compromised-user"
}
}
}
]
}
另一种解决方案是向 AWS 提交工单，请求他们隔离访问凭证。
4.3 CloudTrail 如何处理这种情况？
我们立刻产生的一个疑问是 CloudTrail 如何处理这些事件。即使日志记录与您认为的逻辑顺序不符，CloudTrail 似乎仍能按预期工作。
在下图中，用户’eduard’删除了一套访问密钥，随后，同一套访问密钥又被用于执行 “ListAccessKeys” 和 “CreateAccessKeys” API 调用。
CloudTrail 记录的最终一致性事件
尽管我们很高兴看到 CloudTrail 能按预期工作，但仍不禁要问：有多少检测方案和规则能覆盖此类情况呢？
五、不止于 AWS 访问密钥
我们对 AWS IAM 最终一致性行为的研究表明，这 4 秒的安全窗口期不仅影响 AWS 访问密钥，还波及多个 IAM 操作。在研究过程中，我们系统性地测试了多种 IAM 资源，并在整个 IAM 生态中发现了类似的漏洞。
通过全面的测试，我们发现以下 IAM 操作均表现出相同的最终一致性漏洞：
- • 策略的附加（attach）/分离（detach）
- • 角色承担权限
- • 角色的创建与删除
- • 登录配置文件更改
此持久化窗口期可以与我们记录的其他基于身份的技术结合使用，例如攻击者控制的 OIDC 提供商可通过 RogueOIDC[2] 实现长期的 AWS 持久化访问。
六、协调披露流程
遵循负责任的披露实践，我们通过 AWS 的漏洞披露程序向 AWS 安全团队报告了这些发现。
AWS 确认了这些发现，并指出该行为源于其分布式架构设计。虽然这本身未被归类为漏洞，但他们认识到其对事件响应流程的安全影响，并选择从开发角度解决问题，同时围绕该主题提供更完善的文档。
作为回应，AWS 应用了修复措施，并发布了一篇博文来探讨最终一致性问题：凭证清理程序[3]
6.1 AWS 官方声明
IAM 使用一种称为 最终一致性[4] 的分布式计算模型。这意味着您在 IAM 中进行的任何更改都需要时间才能在所有端点生效。产生延迟的部分原因包括数据在服务器之间、复制区之间以及区域之间传输所需的时间。同时，IAM 也使用缓存来提高性能，但在某些情况下，这可能会增加额外的时间。更改可能要到先前缓存的数据超时后才会显示。AWS 建议客户实施安全最佳实践，并设计应用程序时考虑到这些延迟。例如，客户应避免使用长期有效的 IAM 访问密钥[5]，因为它们具有无限有效期，存在被盗或意外泄露的风险。相反，客户应使用通过 AWS 安全令牌服务（STS）[6] 生成的临时凭证，或利用 IAM 角色[7] 和联合身份验证，以实现对 AWS 服务的程序化访问，因为这些方法提供的是有时间限制、会自动过期的访问权限。我们建议您遵循我们在 re:Post 上发布的操作手册来解决此问题：凭证清理流程[3]。
6.2 重新测试
现在这个问题修复了吗？从某种程度上说是的，但并非完全如此。当前的修复措施阻止了已删除的 AWS 访问密钥被用来创建新密钥。
然而，仍然存在一个时间窗口，在此期间您可以检测到 IAM 数据变更，但相应的授权控制却尚未生效。正因为如此，仍然有可能检测 AWS 访问密钥是否被删除，并创建一个外部账户可以代入、且附加了 AdministratorAccess 策略的角色。
此外，AWS 在 凭证清理流程[3] 中提出的建议效率不高。被入侵的凭证可以检测到何时有新的策略附加到其用户上，并在该策略生效前直接将其移除。
在下图中，防御者为攻击者用户附加了一个限制性更强的策略。攻击者可以持续查找附加给自己的新权限，识别新策略，并在其生效前直接将其移除。这使得官方推荐的操作方案收效甚微。
在拒绝所有策略生效前检测并将其移除
七、OFFENSAI 能提供什么帮助
OFFENSAI 是一个 AI 驱动的对抗性验证平台，旨在模拟您最不希望出现的攻击者行为。它利用专有的生成对抗模型和未公开的攻击向量，发现真实、可利用的攻击链，并为每项发现提供一键式修复指导。所有这些都是通过持续、安全的模拟完成的，绝不会干扰生产环境。
当我们发现诸如利用 AWS 最终一致性实现持久化以及类似的供应商未公开漏洞的技术时，我们不会等待整个生态系统慢慢跟进。OFFENSAI 平台会为未公开或未解决的漏洞部署检测规则。这意味着：
- • 在供应商解决漏洞之前，我们不会公开攻击向量。
- • 从我们发现漏洞的第一天起，您就能获得检测规则。
- • 在官方补丁或缓解措施可用前的数周甚至数月内，您都能得到持续保护。
OFFENSAI 对未公开漏洞的检测
这些场景凸显了为什么组织能从持续云安全红队演练中受益，这能确保 IAM 弱点在攻击者发现之前就被暴露出来。
八、为什么这个 AWS IAM 一致性问题很重要
这个问题在一定程度上仍然存在，我们预计它将成为一种已知的持久化技术。AWS 收到了我们的复测结果，并确认其初步评估与发现相符。我们建议工程师相应地调整其 AWS IAM 检测规则和事件响应预案。
在检测期间，未发现此问题在野利用的攻击。
九、披露时间线
- • 初步发现：2025 年 4 月 18 日
- • 向 AWS 安全团队报告：2025 年 4 月 19 日
- • AWS 初步分类响应：2025 年 4 月 20 日
- • AWS 首次回应与确认：2025 年 4 月 28 日
- • 与 AWS 安全团队会议：2025 年 7 月 28 日
- • 与 AWS 确认修复的会议：2025 年 11 月 20 日
- • 分享复测结果并获得 AWS 确认：2025 年 12 月 5 日
引用链接
[1] 《Exploiting AWS IAM Eventual Consistency for Persistence》: https://www.offensai.com/blog/aws-iam-eventual-consistency-persistence
[2] RogueOIDC: https://www.offensai.com/blog/rogueoidc-aws-persistence-and-evasion-through-attacker-controlled-oidc-identity-provider
[3] 凭证清理程序: https://repost.aws/articles/ARnwmVC8-KQdCc4HJM8b5TwA
[4] 最终一致性: https://wikipedia.org/wiki/Eventual_consistency
[5] IAM 访问密钥: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
[6] AWS 安全令牌服务（STS）: https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html
[7] IAM 角色: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito《利用AWS IAM最终一致性实现持久化访问》