专栏名称: 愿做一名渗透小学徒

分享渗透，安服方面的知识，从浅到深，循序渐进。在渗透的路上，让我们从学徒出发。此公众号提供的任何工具仅供实验使用，如用于其它用途使用，本公众号概不承担任何责任。

【Black Hat 2024议题翻译】三：如何劫持AWS账户的S3存储桶并进一步入侵其他资源

愿做一名渗透小学徒 · 公众号 · · 2024-08-23 08:00

正文

概述：

议题主要讲的是存储桶劫持。共性原因是因为AWS的一些云服务在正常创建的过程中，会在后端创建特定名称的S3存储桶用来存储服务需要的一些数据（创建存储桶过程对用户无感知），而Aqua的研究员发现这里存储桶名称本身具有一定的规律性，比如CloudFormation 服务创建的存储桶格式如下攻击者可以通过该规律提前创建存储桶，导致用户在创建云服务的过程中将数据上传到了攻击者提前创建的S3存储桶，也就是所谓的桶劫持。这些数据或是用来执行任务的、或者存储了用户的敏感数据、或者用来执行特定的脚本的，所以不同的云服务受影响不同。Aqua的研究员将AWS多种云服务创建存储桶的规律总结了下，从其中挖掘出了提到的6种受影响服务

什么是AWS账户ID？

每个AWS账户都有一个独特的12位数字账户ID。一些用户将其视为秘密，而其他用户则不这么认为。

利用ID枚举AWS的信息（角色） ‍ ‍ ‍ ‍

https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/https://blog.plerion.com/aws-account-ids-are-secrets/

简介：AWS IAM 角色

Amazon Web Services (AWS) IAM 角色是一组权限，是向用户或服务委派访问权限的常用方法。角色可以授予内部和外部 IAM 用户、AWS 服务、应用程序，甚至 AWS 之外的外部用户账户。用户利用的角色可以为某些任务启用额外权限。使用角色的应用程序获得与 AWS 服务进行交易所需的访问权限，而无需永久嵌入 AWS 密钥。每当需要临时授予额外访问权限时，IAM 角色都是常见的解决方案。

承担 IAM 角色是获取角色指定的权限集以及相应的临时凭证的过程。当实体承担角色时，安全令牌服务 (STS) 会发出一组角色凭证，这些凭证可用作访问环境的安全令牌。承担角色可以通过 AWS 管理控制台进行，也可以通过 PowerShell、AWS CLI 或各种编程语言的 SDK 以编程方式进行。为了实现更精细的控制，还可以将其他策略应用于请求以进一步限制角色权限。承担角色后发出的请求将使用此新身份执行，但可以使用 CloudTrail 日志来辨别底层实体。

AWS 账户 ID 泄露

AWS 账户 ID 可唯一标识每个 AWS 账户，并且比您想象的更敏感。虽然泄露 ID 不会直接暴露账户，但攻击者可以利用此信息进行其他攻击。应尽合理努力保持 AWS 账户 ID 的私密性，但在实践中，它们经常会无意中暴露给公众。

账户ID通常通过以下方式泄露：

截图
GitHub 和其他代码存储库
许多 AWS 错误消息（甚至拒绝访问）
公共 EBS 快照（EC2 -> 快照 -> 公共快照）
公共 AMI（EC2 -> AMI -> 公共映像）
RDS 公共快照（RDS -> 快照 -> 所有公共快照）
在网上寻求故障排除帮助并发布其 ID 的人

如果攻击者拥有您的 ID，则各种攻击场景都变得可行，包括资源枚举（识别现有角色、用户等）、Lambda 函数调用和 IAM 角色承担。

本文以及我们发布的随附脚本介绍了如何使用 AWS 账户 ID 来识别现有角色。作为此概念的延伸，攻击者可以更进一步，承担配置错误的 IAM 角色以获得未经授权的访问。

IAM 角色枚举

AWS 详细错误消息会透露角色是否存在，让我们可以枚举角色名称。在测试过程中，我们发现 AWS 响应中存在信息泄露，但我们不知道在多次尝试担任角色失败后，账户是否会被锁定。我们最终发现，用户可以生成任意数量的请求，这使得这种枚举技术具有高度可扩展性。还应注意，如果 AWS 在一定时间后阻止某个账户，这将使暴力破解过程更加困难，但并非不可能。通过在一组分散的节点和账户中运行此攻击，攻击者可以绕过可能生效的任何 IP 或基于账户的阻止。

简单列举角色名称就可以揭示：

公司内部正在使用哪些 AWS 服务
内部软件/堆栈
IAM 用户的名称（针对社会工程学）
正在使用的第三方集成（可能会被单独定位）

我们观察到的一些常见集成包括 CloudSploit、Okta 和 Datadog。

一旦列举了角色，人们就可以尝试承担任何开放的角色并窃取角色凭证。

如果您尝试担任您没有权限的角色，AWS 将输出类似以下内容的错误：

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUserisnot authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS

此错误消息表明该角色存在，但其承担角色策略文档不允许您承担该角色。通过运行相同的命令，但针对不存在的角色，AWS 将返回：

An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole

令人惊讶的是，这个过程可以跨账户进行。只要给出任何有效的 AWS 账户 ID 和精心设计的单词表，您就可以不受限制地枚举该账户的现有角色。

劫持错误配置的角色

与其他 AWS IAM 策略一样，AssumeRole 权限非常灵活，如果配置错误，可能会导致意想不到的后果。例如，如果访问角色 “AWS”：“*” 已关联，则任何账户中的任何用户都可以担任该角色（前提是他们拥有正确的 AWS 账户 ID 和角色名称）。虽然这是非默认状态，并且相对罕见，但我们已经确定（并正确报告）了 50 多个具有 AssumeRole 全局权限的账户实例。

配置不当的 AssumeRole 策略允许任何经过身份验证的 AWS 用户承担该策略并检索临时凭证。

AWS“AssumeRole”枚举脚本

我们创建了一个独立脚本，允许您枚举目标帐户中的角色。默认情况下，它附带一个包含 1100 多个单词的单词表，其中包含一些常见/通用角色名称。当发现角色时，脚本会提醒您。如果发现一个角色并且配置错误以允许来自广泛群体的角色承担，则脚本能够自动承担发现的角色并输出已颁发的凭据。

该脚本刚刚在 GitHub 上发布。Pacu （ AWS 开发框架）现在也通过专用模块包含此功能。

所需的只是您的目标帐户的帐户 ID – 它们遍布互联网。

Usage: assume_role_enum.py [-h] [-p PROFILE] [-w WORD_LIST] -i ACCOUNT_ID

注意： 使用的密钥必须具有任何资源的“sts:AssumeRole”权限 (*)，才能承担配置错误的角色。如果没有此权限，角色仍然可以被识别，但不能承担。

可选参数：

-h, --help            show 




    
this help message andexit
  -p PROFILE, --profile PROFILE
                        The AWS CLI profile to usefor making API calls. This
                        is usually stored under ~/.aws/credentials. You will
                        be prompted bydefault.
  -w WORD_LIST, --word-list WORD_LIST
                        File path to a different word list to use. Thereis a
                        default word list with1100+ words. The word list
                        should contain words, one on each line, to use to try
                        and guess IAM role names. Role names ARE case-
                        sensitive.
  -i ACCOUNT_ID, --account-id ACCOUNT_ID
                        The AWS account ID of the target account (12 numeric
                        characters).

以下屏幕截图演示了该工具在模拟环境中的使用情况。它开始枚举角色，并找到名为“5”和“ADS”的受限角色，以及名为“APIGateway”的配置错误的角色。该脚本尝试承担该角色至少一个小时，然后承担该角色并显示 JSON 格式的角色凭据。然后显示结果摘要。

演示如何使用脚本成功枚举并承担角色。然后显示已颁发的角色凭据。

除了我们要查找的已知用户和角色的默认列表之外，请查看Daniel Grzelak（ @dagrz ）创建的列表，其中包括许多已知的第三方集成。

预防

除非 AWS 降低角色假设失败后返回的错误消息的详细程度，否则攻击者将能够使用此方法枚举角色名称。幸运的是，缓解这种性质的攻击只需避免一些简单的配置错误。

保护环境可采取三个可操作的步骤：

要求严格的 AssumeRole 策略，专门列出需要额外访问权限的 AWS 服务或 IAM 用户/账户
不要对 AWS 资源使用常见的、可猜测的名称
避免向公众暴露您的 AWS 账户 ID

这种暴力破解技术和脚本将在您用于枚举的账户中生成大量“iam:AssumeRole”CloudTrail 日志。您瞄准的任何账户都不会在其 CloudTrail 日志中看到任何内容，直到您成功承担配置错误的角色，这意味着枚举在目标账户上完全没有日志。

言归正传，知道id泄漏的部分危害后我们看看其他的 ‍ ‍ ‍

影子资源

影子资源是自动或半自动生成的AWS资源，通常在没有用户干预的情况下生成，有时可能不被账户所有者注意到。

S3存储桶作为影子资源

S3存储桶具有全局唯一性，即如果创建了一个名为'cool-bucket-1'的存储桶，其他任何人都不能使用这个名字。然而，AWS CloudFormation存在一个漏洞，可以被利用来创建具有相同名称的存储桶。

下图是CloudFormation服务创建存储桶的命名规则 ‍ ‍ ‍ ‍

‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

AWS CloudFormation漏洞

AWS CloudFormation允许用户使用模板在S3存储桶中创建堆栈。如果存储桶不存在，CloudFormation会尝试创建它。攻击者可以利用这一点来创建一个与受害者相同名称的存储桶，并在其中放置恶意模板。

攻击场景

用户创建一个堆栈并上传一个模板。
通过PutBucketNotification触发的Lambda函数可以获取受害者的模板。
攻击者修改模板并重新上传。
用户提交堆栈并获取修改后的模板。
创建注入的资源，可能获得管理员角色。

重点

发起者需要IAM角色管理权限来创建管理员角色。
攻击者仍然可以根据模板文件修改资源。
等待在新区域中部署新堆栈。

简单点就是，攻击者A发现了一个用户B的资源名称和id。他在自动化编排系统中，写了一个模板，当aws有新区域发布的时候，去抢注这个名称，并放入恶意代码，或者等受害者来上传敏感信息。

当受害者开始使用这个服务的时候，后端去注册这个名称，服务是注册不成功的，因为这个存储桶已经存在了，而用户被无感知的引导了。 ‍ ‍ ‍ ‍ ‍ ‍

如上图所示，用户被抢占后无感知的将数据放在了攻击者的存储桶中，攻击者给其中的模板等文件中进行代码注入，受害者就会无感知的拉取并执行。

HASH怎么获取 ‍

大家可能会想，这个12个字符串呀。可能性有N种。不着急，我们前面说了，会在很多地方看到这个hash计算方式的泄漏

当然这种基本是第三方自己写的 ‍ ‍ ‍ ‍ ‍ ‍ ‍

要想把影响范围扩大，就得看看AWS官方的服务中，这些hash是怎么得来的。这里推出了一个抓包工具 TrailShark ‍ ‍ ‍ ‍

研究人员在漫长的研究后，总结如下： ‍ ‍

在以下AWS 服务中发现这些漏洞:CloudFormation、Glue、EMR、SageMaker、Servicecatalog和CodeStar，首次在新区域中创建这些服务中的任何一项时，将自动创建具有特定名称的 S3 存储桶。此名称分为 AWS 账户ID 的服务名称(在上述大多数服务中)和区域名称，因此，在所有 AWS 区域中，存储桶名称保持不变，只是区域名称有所不同。