文章总结： 本文揭示了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. 1. 应用一个 SCP，拒绝被入侵主体执行所有操作。
2. 2. 等待完整的约 4 秒传播期结束。
3. 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最终一致性实现持久化访问》