攻击者可以通过预先创建具有可预测名称的S3存储桶，从而访问AWS账户或敏感数据，而这些存储桶将被各种服务和工具自动使用。
研究人员发现了一种攻击AWS服务或自动配置AWS S3存储桶的第三方项目的新方法，这种被称为“Shadow Resource”的新攻击向量可能导致AWS账户被接管、远程代码执行或敏感数据泄露。
安全公司Aqua Security的研究人员发现，六种AWS服务会创建具有可预测名称的S3存储桶，这些存储桶易受新劫持技术的攻击，他们在本周的Black Hat USA安全会议上展示了他们的研究成果。
“Shadow Resource”攻击涉及攻击者在其他AWS区域提前创建存储桶，然后等待目标用户在这些区域启用易受攻击的服务，从而导致敏感文件和配置被存储在由攻击者控制的存储桶中。
Aqua确定易受此技术攻击的AWS服务包括CloudFormation、Glue、EMR、SageMaker、ServiceCatalog和CodeStar。亚马逊已经修复了这些服务中的问题，并正在调查过去是否曾被利用过，其他表现出类似S3存储桶配置行为的AWS服务和第三方工具可能仍然存在漏洞。
具有后门潜力的影子存储桶
Aqua的研究人员在注意到AWS CloudFormation每次在新的AWS地理区域启用时，都会在后台创建一个S3存储桶后，开始了他们的调查。这个S3存储桶用于存储用户创建的CloudFormation模板，其名称格式为[固定前缀]-[唯一哈希值]-[AWS区域名称]，例如cf-templates-123abcdefghi-us-east-1。
S3存储桶名称在整个AWS基础设施中是唯一的，因此研究人员想知道，如果攻击者提前在用户可能稍后启用的不同区域中注册了CloudFormation预期会创建的存储桶名称，会发生什么。
存储桶名称的前缀和哈希部分在各区域之间保持不变——只有区域部分会改变。因此，如果攻击者确定了哈希值，他们可以在用户尚未使用的区域中预先注册该存储桶。尽管猜测哈希值是不可能的，但Aqua研究人员设法在GitHub的公共仓库或公开的错误票中找到了这些哈希值。
接下来他们想知道，当用户在某个区域部署服务时，CloudFormation是否会使用攻击者创建的现有存储桶，还是会在尝试创建存储桶时出现错误。他们发现，CloudFormation确实会响应一个错误——但只有在存储桶未配置为公共访问时才会如此，这是因为它无法向存储桶写入文件。
因此，如果攻击者配置了非常宽松的策略以允许服务所需的操作，并启用了公共访问，CloudFormation将直接使用这个恶意存储桶。
问题的影响取决于易受攻击服务在存储桶中存储的内容。对于CloudFormation(一个基础设施即代码工具)来说，存储在存储桶中的模板用于自动部署由用户定义的基础设施堆栈。
这些模板可能包含敏感信息，如环境变量、凭据等，但问题更严重的是，攻击者可以在存储桶中保存的模板中注入后门代码，这些代码将在用户的账户中执行。例如，攻击者可以在模板中注入一个恶意的Lambda函数，该函数可以在账户中创建一个新的管理员角色，供攻击者使用。
使用账户ID生成可预测的S3存储桶名称
CloudFormation攻击依赖于服务为用户在某个区域创建的现有S3存储桶名称被泄露在代码仓库中，但其他自动创建S3存储桶的AWS服务使用了更为可预测的命名模式。例如，AWS EMR(Elastic MapReduce)生成的S3存储桶名称为aws-emr-studio-[account-ID]-[region]，而AWS SageMaker则使用sagemaker-[region]-[account-ID]。
根据AWS文档，AWS账户ID不被视为机密或敏感信息。因此，它比由特定服务生成的唯一哈希值更有可能在多个地方被暴露。
AWS EMR是一项服务，用户可以使用Apache Hadoop、Apache Spark、Apache Hive和Jupyter Notebook等框架处理和分析大数据集。由EMR Studio创建的S3存储桶用于存储敏感的配置文件，同样易受此类攻击。
例如，攻击者可以在受害者的EMR服务存储的Jupyter Notebook文件(.ipynb)中注入恶意函数，导致Jupyter Notebook界面中出现跨站脚本(XSS)漏洞。研究人员表示，这种漏洞可用于将用户重定向到伪造的AWS登录页面，从而窃取他们的凭据。
AWS SageMaker是一个用于构建、训练和部署机器学习模型的服务，也存在类似的漏洞，因为SageMaker Canvas会自动设置一个可预测的S3存储桶。如果攻击者预先注册了这个存储桶，他们可以访问敏感的模型训练数据，甚至可以污染数据集，从而创建不准确的模型。
研究人员还警告说，许多组织用于在其AWS环境中部署资源的开源工具也会创建具有可预测名称的S3存储桶，这些名称通常依赖于AWS账户ID、固定前缀和区域名称，这些工具是否易受攻击取决于它们在存储桶已存在的情况下是否会报错，或者它们是否会继续使用现有存储桶(该存储桶可能是由攻击者拥有的)。影响还取决于存储在这些存储桶中的文件和资源类型。
研究人员在GitHub上搜索AWS账户ID模式，得到了将近160,000个结果。此外，还有其他人建立的包含AWS账户ID的列表，以及可能包含账户ID的S3存储桶名称列表。AWS账户ID还可以通过已知技术从AWS访问密钥ID中推导出来。
桶垄断攻击及其缓解措施
为了最大化攻击成功的可能性，攻击者可以使用可预测的命名模式在组织尚未使用的所有AWS区域中创建影子S3存储桶。AWS目前有33个区域，而一个组织不太可能使用其中的所有区域。研究人员将这种攻击称为“桶垄断攻击”。
首先，攻击者找到一个基于AWS账户ID生成具有可预测名称的S3存储桶的服务或开源工具。然后，他们识别出使用该服务或工具的组织，并找到其账户ID。确定这些组织尚未使用哪些区域来部署服务或工具并不困难，因为存储桶名称在整个服务中是唯一的，容易检查它们是否已存在。
Aqua Security的研究人员提出的一种缓解措施是，组织可以为其使用的服务或工具所使用或假定的角色定义一个范围化的策略，并在策略中包含`aws:ResourceAccount`条件元素，这可以用于检查拥有资源(如S3存储桶)的AWS账户ID是否与条件中提供的用户自身的AWS账户ID匹配。
想要检查某些服务的存储桶是否遵循可预测名称模式且由自己拥有的组织，可以使用以下命令：`aws s3api list-objects-v2 --bucket --expected-bucket-owner `。如果回复为“访问被拒绝(Access Denied)”，则表示尽管存储桶名称中包含您的账户ID，但该存储桶并不属于您的账户。
那些基于AWS账户ID并使用可预测模式自动生成存储桶名称的工具应转向使用唯一的哈希值和随机标识符来为每个区域生成存储桶名称。
