RSAC议题解读-通过影子资源攻击AWS帐户

1. 前言

2024 年的 BlackHat 会议上三位研究员分享了名为《Breaching-AWS-Accounts-Through-Shadow-Resources》的议题，议题主要探讨了一种新型的攻击方式，称为“影子资源”（Shadow Resources），以及如何通过这些资源对AWS账户进行攻击。

2. 背景

首先来讲一下什么是影子资源：

影子资源是指在AWS环境中自动或半自动生成的资源，通常在用户不知情的情况下创建，可能会被账户所有者忽视。

在AWS中，影子资源可以是为支持各种服务而创建的 AWS S3 bucket。以AWS CloudFormation 服务为例，AWS CloudFormation是一个AWS提供的，可以帮助用户快速创建云资源的工具。一般来说，创建AWS资源，可以使用CLI，API或者各种SDK直接创建资源或者通过控制台页面进行点击操作，这些方式对于创建单类资源还好，如果要用来管理整个team或公司的资源就显得力不从心，而CloudFormation是专门用来管理AWS资源的工具，可以清晰的描述和修改资源。下面是一个Template示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

AWSTemplateFormatVersion: '2024-09-25'
Description: create ELB for query service
Parameters:
  EnvName:
    Type: String
    Description: Name of current running environment
Resources:
  AWSCFELB:
    Type: AWS::ElasticLoadBalancing::LoadBalancer
    Properties:
      LoadBalancerName: !Join
      - ''
      - - aws-cf-lb-
        - !Ref 'EnvName'
      Subnets: 'xxxxx'
      SecurityGroups: 'yyyyy'
      CrossZone: true
      Listeners:
      - LoadBalancerPort: '2443'
        InstancePort: '3443'
        Protocol: TCP
        InstanceProtocol: TCP
      ConnectionSettings:
        IdleTimeout: 300

其中：

• template可以是本地文件，也可以是放在S3上的文件
• stack: 管理资源的集合，一个template对应一个stack
• changeset: 描述对一个stack的修改

简单理解可以类比k8s pod的配置文件，通过kubectl apply xx.yaml 即可批量创建多个资源。

在使用 AWS CloudFormation 时，当用户通过 AWS 控制台在新区域首次使用该服务创建新stack时，该服务会自动触发 AWS 创建一个 S3 存储桶，用于存储用户的 CloudFormation 模板。

众所周知，AWS S3 存储桶名称必须是唯一的。如果用户创建了一个名为my-bucket的存储桶，那么其它用户都无法创建相同名字的新存储桶。

但是，服务于CloudFormation的 S3 存储桶，除了区域名称外，所有 AWS 区域的存储桶名称都是相同的。 这里面就存在一个安全问题，如果外部攻击者以某种方式猜到 CloudFormation S3 存储桶的名称，并抢在受害者之前在不同的区域创建一个新的存储桶，从而实现劫持的效果。研究发现，攻击者确实抢先注册一个新存储桶，并等待受害者在新区域中使用 CloudFormation 服务，从而使用攻击者控制的 S3 桶作为 CloudFormation 服务的一部分。 通过上述操作，攻击者可以利用S3 bucket执行代码、修改或窃取数据，甚至在用户不知情的情况下完全控制受害者账户。

3. 使用S3 Bucket作为影子资源

S3 存储桶是一种在线存储容器，用于管理文件、图像、视频和其他数据，类似于基于云的硬盘驱动器。

在 AWS 管理控制台使用 CloudFormation 上传模板文件时，CloudFormation会在用户没有明确指示的情况下自动生成一个 S3 桶，该桶遵循特定命名规范：

• 前缀：这是通过 AWS管理控制台上传模板时为 CloudFormation 服务创建的 S3 存储桶的前缀（“cf-templates”），在所有 AWS 账户中均相同
• 哈希：随机的12个字符的哈希值，包含字母数字字符（a-z，0-9）
• 区域：表示使用 CloudFormation 服务的区域名称

研究发现，在不同可用区为同一账户创建模板将生成具有相同前缀和哈希值的 CloudFormation S3存储桶名。唯一不同的是地区部分。举个例子，如果某个帐户在 us-east-1 区域使用 CloudFormation，则相关的桶名称为cf-templates-a3gjv31ap90h-us-east-1。当同一账户在另一个区域（如 eu-west-2）使用 CloudFormation 时，AWS 会创建一个名为cf-templates-a3gjv31ap90h-us-east-2的新存储桶。唯一不同的是地区名称。

总之，CloudFormation 的存储桶名称由三部分组成：常量服务名称前缀 cf-templates-、一个包含 4,738,381,338,321,616,896 个可能选项的12个字符的随机字符串（不可能暴力猜解）以及区域名称（公开信息，已知所有33 个AWS可用区）。那么攻击者如何获取哈希值呢？我们将在本文章的后续部分讨论这个问题。

4. AWS CloudFormation 漏洞：cf-templates-{Hash}-{Region}

此时，我们有两个主要问题需要解决：

• 如果另一个用户已经用指定名称创建了一个存储桶，会有什么影响？
• 如何猜到哈希值？我们是否应该将其视为秘密？

首先来看一下CloudFormation创建存储桶的具体流程：

1、用户选择上传模板文件以启动CloudFormation创建资源，该这个过程底层会调用CreateUploadBucket API请求，创建存储桶。 2、如果用户的 S3 存储桶不存在，CloudFormation会自动创建一个 S3 存储桶，名字为：cf-templates-{Hash}-{Region}。如果桶已经存在，CloudFormation 将直接使用原有存储桶。 3、服务器返回 S3 存储桶名称。 4、系统调用 PutObject API 请求将模板文件存储到 S3 存储桶中。 5、验证等操作将在后台执行（例如，GetTemplateSummary和DescribeStacks）。 6、启动 CreateStack API 请求，创建堆栈资源。

CloudFormation存储桶已被攻击者占用会的情况

假设攻击者知道受害者CloudFormation存储桶中哈希值部分，受害者在us-east-1可用区中创建了一个桶，因此攻击者可以在受害者尚未使用过的其它可用区创建一个具有可预测名称的存储桶。

当受害者首次尝试在eu-west-2中部署新的CloudFormation资源时，将发生以下一系列事件：

1、受害者启动操作：受害者在账户A中操作，通过 AWS 管理控制台上传 CloudFormation 模板启动流程。 CloudFormation服务将检查名称为 cf-templates-{Hash}-{Region} 的 S3 存储桶是否存在。如果不存在，它将尝试创建一个。

**2、存储桶名称唯一：**由于 S3 存储桶名称在所有 AWS 账户中都是全局唯一的，因此目标存储桶名称已被占用。 3、CloudFormation ERROR：当受害者账号中的 CloudFormation 服务尝试创建 S3 桶并将模板文件上传到该桶时，服务遇到了问题。虽然服务识别到桶已经存在，但上传过程失败，CloudFormation返回错误，通常是 “AccessDenied”（拒绝访问），表明服务未能将模板文件上传到现有的 S3 桶。

这个问题可以看做是一种拒绝服务（DoS）攻击。出现这种情况是因为 S3 存储桶默认设置为阻止所有公共访问、上传，因此受害者没有权限在攻击者创建的存储桶上执行操作。那么如何将危害升级呢？

4.2. 存储桶设置为公开读写

首先将存储桶权限设置为公开读写：

那么再来看一下CloudFormation运行的整个过程，受害者账户中CloudFormation服务尝试创建 S3 存储桶并将模板文件上传到该存储桶，但由于该存储桶已经存在（在攻击者的账户中），它将信任该存储桶，访问该存储桶并将模板文件上传到该存储桶。

这就导致CloudFormation存在信息泄露漏洞，攻击者可以读取受害者CloudFormation服务写入恶意 S3 存储桶的模板文件。如果CloudFormation模板包含环境变量、凭据等敏感信息，该漏洞可能会造成更加严重的影响。

4.3. 编辑CloudFormation模板

如何进一步扩大危害呢？研究发现，rhino实验室提出一种资源注入技术，简单说就是：创建一个Lambda函数，并利用AWS的PutBucketNotification 事件触发，修改传入的CloudFormation模板（插入恶意代码如：将攻击者赋予管理员权限），因此，只要有文件被上传到该文件桶，Lambda 函数就会自动对其进行修改。

4.4. 如何获取哈希值

如前面章节所述，CloudFormation 服务通过 AWS 控制台使用的 S3 存储桶名称包括以下格式：cf-templates-{Hash}-{Region}。其中哈希值它由12个字符（a-z，0-9）的字母数字序列组成，可产生 4,738,381,338,321,616,896种可能的组合，因此无法简单猜测或暴力破解。目前暂时无法通过算法计算出特定用户的哈希值。尽管如此，还是通过使用GitHub等代码托管平台的搜索到大量泄露的哈希值：

研究发现，除了CloudFormation存在存储桶问题外，还发现了多种产品存在类似的问题，一些 AWS 服务使用可预测的名称创建S3桶。这些服务不使用哈希值，而是使用 AWS 帐户ID作为这些存储桶的唯一标识符。例如，某个 AWS 服务使用的存储桶名称存在以下规律：{服务前缀}-{AWS 帐户 ID}-{可用区}，经过分析研究，最终发现了6个AWS服务的问题。

5. AWS Glue漏洞：aws-glue-assets-{Account-ID}-{Region}

AWS Glue 是一项无服务器数据集成服务，可让使用分析功能的用户轻松发现、准备、移动和集成来自多个来源的数据。您可以将其用于分析、机器学习和应用程序开发。它还包括用于编写、运行任务和实施业务工作流程的额外生产力和数据操作工具。

研究中发现，当用户使用AWS管理控制台和Visual ETL工具创建作业时，会使用一个S3桶来存储 Glue 作业，这些作业主要是由 Glue 执行的 Python 脚本。

Glue 服务会根据以下命名规则为用户自动创建这个 S3 存储桶：aws-glue-assets-{Account-ID}-{Region}。

攻击思路和前面的相同，在此不做赘述：

其中一个有趣的现象是，即使攻击者修改了Glue 脚本的内容，当受害者在AWS管理控制台中查看该函数时，显示的仍然是正常的内容，并不是修改后的内容，但受害者的 Glue 服务仍会运行修改后恶意的脚本，猜测是由于缓存机制造成的。

6. AWS EMR漏洞：aws-emr-studio-{Account-ID}-{Region}

Amazon Elastic MapReduce (Amazon EMR) 是一种 Web 服务，能够轻松快速并经济高效地处理大量数据。

研究中发现，当用户使用EMR 服务和EMR Studio创建studio时，EMR 服务会自动生成一个 S3 存储桶。该 S3 存储桶的命名过滤为：aws-emr-studio-{Account-ID}-{Region}。

攻击思路：

一旦受害者的 EMR 服务将文件写入攻击者的存储桶，攻击者就可以通过注入恶意代码来加以利用。在这种情况下，Lambda函数会将恶意代码注入由受害者的 EMR 服务写入攻击者存储桶的 Jupyter 笔记本（.ipynb）文件中。当用户在 EMR Studio 中打开笔记本时，可能会导致跨站脚本 (XSS) 攻击。例如，攻击者可以将用户重定向到欺骗的 AWS 登录页面，从而窃取凭据。

有趣的是在该服务下，AWS 在策略中强制执行了检查条件，即检查 EMR所用 S3 存储桶的 aws:ResourceAccount，这样可以确保 S3 存储桶属于受害者的账户。若不相同，会触发一个告警。

此时，用户还是有两个选项来继续创建Studio：

无论用户选择哪种，均可以成功创建Studio。

7. AWS SageMaker漏洞：sagemaker-{Region}-{Account-ID}

AWS SageMaker 是一项用于大规模构建、训练和部署机器学习模型的服务，为整个工作流程提供全面的工具。Amazon SageMaker Canvas 是该生态系统的一部分，它是一个无代码的可视化平台，使非开发人员和业务分析师能够轻松开发、训练和部署模型。

研究发现，当用户创建 SageMaker Canvas时，SageMaker 服务会自动创建一个 S3 存储桶来存储服务使用的文件。该 S3 存储桶的命名规律为：Sagemaker-{Region}-{Account-ID}。

攻击思路如下：

每次 SageMaker Canvas 用户尝试创建数据集或将数据导入服务时，这些数据都会被写入攻击者的 S3 存储桶（Canvas/default-{Time}/* 下）。之后，SageMaker Canvas 服务将为用户使用这些数据，从而导致以下重大风险：

8. AWS CodeStar 漏洞：aws-codestar-{Region}-{Account-ID}

AWS CodeStar是一项通过集成用于编码、构建和部署应用程序的 AWS 开发工具来简化项目管理的服务。

创建 CodeStar项目时，CodeStar服务会自动为所用项目生成一个 S3 存储桶。该 S3 存储桶的命名规律为：aws-codestar-{Region}-{Account-ID}。

攻击思路如下：

与前一种情况类似，如果桶名被攻击者提前注册，合法用户将无法使用该服务，并在尝试创建 CodeStar 项目时收到 “项目创建失败 ”的消息。 从而造成拒绝服务（DoS）攻击，即攻击者阻止用户使用特定的 AWS 服务。

9. AWS Service Catalog漏洞：cf-templates-{Hash}-{Region}

AWS Service Catalog允许组织集中管理、创建和分发获准在AWS上使用的IT服务目录，这些服务包括虚拟机映像、服务器、软件、数据库以及完整的多层应用程序架构等。

有几种方法可以将产品添加到服务目录中，其中一种是使用 AWS CloudFormation。如果选择这种方法，用户可以选择上传 CloudFormation 模板。上传 CloudFormation 模板后，AWS 服务目录会创建一个 S3 存储桶来存储模板， 这个就和前面的攻击相同了。

10. 启示

为了解决影子访问问题，需要采取一系列措施来减少不必要的访问并加强身份验证和授权控制。

首先，**组织应该实施最小权限原则，**只为所需人员提供所需的访问权限。这可以通过限制对敏感资源的访问和使用强密码策略来实现。此外，组织还应定期审查和更新账户权限，以确保它们仍然有效且符合最佳实践。

此外，组织还应实施多因素身份验证（MFA），这是一种更安全的身份验证方法，要求用户提供额外的验证步骤才能登录账户。这可以大大减少未经授权的访问尝试并提高安全性。

另一个重要的步骤是监控和日志记录。组织应使用监控工具来跟踪和记录账户活动，以便及时发现任何可疑行为或未经授权的访问尝试。这有助于组织快速响应安全事件并采取适当的措施来防止进一步的数据泄露或其他安全事件发生。