| 关联规则 | 关联知识 | 关联工具 | 关联文档 | 关联抓包 |
| 参考1(官网) | |
| 参考2 | |
| 参考3 |
执行摘要
第42单元的研究人员发现了一类Amazon Web Services（AWS）API，这些API可被滥用以泄漏AWS Identity and Access Management（IAM）用户和任意帐户中的角色。研究人员证实，可以以相同的方式滥用16个不同AWS服务中的22个API，并且该漏洞利用可以在所有三个AWS分区（aws，aws-us-gov或aws-cn）上工作。可能被攻击者滥用的AWS服务包括Amazon Simple Storage Service（S3），Amazon Key Management Service（KMS）和Amazon Simple Queue Service（SQS）。恶意行为者可能会获取帐户花名册，了解组织的内部结构并针对个人发动有针对性的攻击。在最近的红队演习中，第42单元的研究人员使用此技术确定的错误配置的IAM角色，使客户的云帐户遭受了数千个工作负载的侵害。
问题的根本原因在于，AWS后端会主动验证附加到资源（例如Amazon Simple Storage Service（S3）存储桶和客户管理的密钥）的所有基于资源的策略。基于资源的策略通常包括一个委托人指定允许访问资源的身份（用户或角色）的字段。如果该策略包含不存在的标识，则创建或更新该策略的API调用将失败，并显示一条错误消息。但是，可以滥用此便利功能来检查AWS账户中是否存在身份。对手可以使用不同的主体重复调用这些API，以枚举目标帐户中的用户和角色。此外，目标帐户无法观察到枚举，因为API日志和错误消息仅出现在操作资源策略的攻击者帐户中。该技术的“隐身”特性使检测和预防变得困难。攻击者可以有不受限制的时间对随机或目标AWS账户执行侦察，而不必担心被注意到。
AWS基于资源的策略
AWS IAM使用各种类型的策略来管理用户，资源和应用程序之间的权限。基于资源的策略是一种附加到AWS服务内资源的策略。每个AWS服务可以具有多个资源，并且每个资源都可以附加不同的策略。例如，一个S3服务可以创建多个存储桶资源，而SQS服务可以创建多个消息队列资源。在撰写本文时，有26种AWS服务支持基于资源的策略，如表1所示。该策略确定委托人可以对附加资源执行的操作。委托人可以是AWS用户，角色或服务。可以执行的操作取决于服务的类型。
[出自:jiwo.org]
图1.基于资源的策略说明。
图2是附加到S3存储桶的示例基于资源的策略。允许两个主体访问存储区，账户123456789012中的用户“ Bob”和账户98765431098中的IAM角色“ qa-role”。主体可以对S3存储桶“ awsexamplebucket”执行三个操作，即GetObject，GetBucketLocation和ListBucket。请注意，主体不必与存储桶位于同一帐户中，这意味着策略也可以授予跨帐户访问资源的权限。
图2是策略的最简单形式。一个更复杂的策略可能包含多个语句和条件。为了避免人为错误，AWS会先验证策略中的每个字段，然后才能将策略应用于资源。验证器确保指定的主体实际存在并且服务支持指定的操作。在图2中，由于不支持“ GetFiles”操作，因此出现错误消息。
图2.示例S3存储桶策略（左）和错误指定操作的错误消息（右）。
滥用基于资源的策略API
策略验证是AWS的一项功能，可促进用户体验。尽管大多数用户都从该功能中受益，但对手也可能会发现该功能对于在另一个帐户中执行侦察很有用。因为策略验证器检查指定的委托人是否存在，所以它为对手提供了一种逐步建立目标帐户花名册知识的方法。正如我们将显示的，对手可能会滥用支持基于资源策略的多个AWS服务中的策略验证器。
在基于资源的策略中定义主体时，用户要求AWS进行身份验证并授权该主体访问AWS账户中的资源。如果我们提供的用户名或角色名称无效，则身份验证将失败。实施安全认证过程的认证最佳实践之一是避免在错误消息中给出特定于帐户的信息。
AWS策略验证程序会在错误消息中无意中泄露特定于帐户的信息。创建或更新资源策略时，AWS策略验证器会明确显示指定的主体是否存在。攻击者可以使用错误消息来检查目标帐户中是否存在用户或IAM角色。通过用单词表重复此过程，对手可以枚举并发现目标帐户中的现有身份。图3和图4显示了当我们在不同的AWS服务的资源策略中指定不存在的IAM角色时的错误消息。这些政策被拒绝，无法保存。还可以使用AWS API以编程方式执行该过程，从而使枚举可扩展。
该技术的一个令人关注的特性是，目标或受害者完全无法观察到该技术。更改资源策略时，AWS CloudTrail日志和错误消息仅显示在资源所有者或攻击者的账户中。“隐形”属性使得几乎不可能进行检测和预防。
Rhino Security Labs首先在博客中发布了类似的技术，他们在其中使用IAM角色信任策略来检查是否存在跨帐户IAM角色。第42单元的研究人员确定并确认，可以利用16个AWS服务中的至少22个API，如表1所示。这些API之间的共同点是它们都将资源策略作为输入，并且该策略需要具有有效的“主体”字段。
图3.主体不存在的资源策略。AWS SQS（左）和AWS SNS（右）。
图4.主体不存在的资源策略。AWS KMS（左）和AWS Glue（右）。
结论
由于目标帐户中没有可观察到的日志，因此使用这种技术来检测和阻止身份侦查非常困难。但是，良好的IAM安全卫生措施仍可以有效缓解此类攻击带来的威胁。尽管无法阻止攻击者枚举AWS账户中的身份，但是枚举可能会变得更加困难，并且您可以监视侦察之后进行的可疑活动。为了缓解此问题，我们建议组织采用以下IAM安全最佳做法：
-
- 删除不活动的用户和角色以减少攻击面。
- 在用户名和角色名称中添加随机字符串，以使其更难以猜测。
- 使用身份提供者和联合身份登录，这样就不会在AWS账户中创建其他用户。
- 记录并监视所有身份验证活动。
- 为每个用户和IAM角色启用两因素身份验证（2FA）。
附录
表1.支持基于资源的策略的AWS服务。第42单元的研究人员在16种可滥用的AWS服务中确定了22种API。
