错误配置的IAM角色导致成千上万的云负载受攻击（上）

在2020年春天，Unit 42云威胁情报团队遇到了一位客户，他想让团队测试他们的亚马逊网络服务(AWS)基础设施的防御能力。客户运行了数千个工作负载、数百个Amazon Simple Storage Service (S3)桶，并维护了云本地数据库，该数据库拥有超过500个活跃的开发用户和跨越4个AWS帐户的近1000个角色。在这次渗透测试中，Unit 42的研究人员仅获得有关内部架构的有限信息，并获得了对环境本身的有限访问权限。研究人员使用两种不同的身份和访问管理(IAM)错误配置，获得了访问两个AWS账户的特权。这些错误的配置使得研究人员能够以匿名用户的身份访问云，然后转向托管在云之外的源代码存储库。

首先发现的配置错误利用了风险较高的策略组合，这些组合允许具有IAM角色的用户提升为AdministratorAccess。当成百上千的用户被赋予此角色时，这就为利用这个漏洞获得管理员访问并危及整个云提供了许多潜在的途径。第二个标识的错误配置利用了一个过度允许的IAM信任策略，该策略允许未经身份验证的用户以匿名方式访问内部资源。研究人员成功地在云中横向攻击，并最终获得证书、数据库证书和存储库源代码的私钥。

在分析了过度允许的IAM信任策略的严重性之后，Unit 42的研究人员随后对GitHub进行了调查研究，以查找配置错误的IAM信任策略的AWS账户。研究发现，一家美国制药公司和一家总部设在巴西的金融公司的账户被错误配置。

所有这些错误配置都可能导致重大数据泄漏，从而泄漏有关云工作负载的数千个敏感细节，例如虚拟机（VM）快照、数据库表和S3存储桶。

渗透测试和GitHub侦察研究的细节可以在威胁报告中找到 Unit 42 Cloud Threat Report, 2H 2020 (CTR)，本文介绍了用于识别云中的攻击路径的技术和流程，还分析了IAM策略风险组合的根本原因，还包括针对已识别的错误配置的保护和补救策略。IAM是一套全面的建立和维护数字身份，并提供有效地、安全地IT资源访问的业务流程和管理手段，从而实现组织信息资产统一的身份认证、授权和身份数据集中管理与审计。

身份和访问管理是一套业务处理流程，也是一个用于创建和维护和使用数字身份的支持基础结构。通俗地讲：IAM是让合适的自然人在恰当的时间通过统一的方式访问授权的信息资产，提供集中式的数字身份管理、认证、授权、审计的模式和平台。当你首次创建 AWS 账户时，最初使用的是一个对账户中所有 AWS 服务和资源有完全访问权限的单点登录身份。此身份称为 AWS 账户根用户，可使用你创建账户时所用的电子邮件地址和密码登录来获得此身份。强烈建议你不使用 根用户 执行日常任务，即使是管理任务。请遵守仅将 根用户 用于创建首个 IAM 用户的最佳实践。然后请妥善保存 根用户 凭证，仅用它们执行少数账户和服务管理任务。

Unit 42研究人员指出，在渗透测试中发现的所有错误配置都是客户的错误配置，而不是AWS平台安全的错误配置。当IAM信任策略配置错误时，AWS已经尽力检测并提醒用户。然而，虽然IAM信任策略在默认情况下是安全的，但用户仍然可以覆盖这些策略并引入不安全的配置。AWS还提供了免费的IAM访问分析器，以帮助识别与外部实体共享的资源和数据的意外访问。

AWS IAM

AWS IAM是任何云环境中最复杂的服务之一，它控制每个用户、服务和资源之间的交互。虽然云IAM服务是由云服务提供商(csp)安全设计的，比如AWS，但如果客户配置不当或使用不当，可能会影响多个服务和资源。例如，2019年的Capital One数据泄漏让公司损失了8000万美元，原因是过度宽松的IAM配置允许攻击者绕过AWS Web应用防火墙(WAF)横向移动到Amazon Elastic Compute Cloud (EC2)和S3 存储桶s。

由于知道IAM服务及其配置的重要性，Unit 42的研究人员考虑如何处理客户要求的渗透测试时，我们决定从IAM开始。我们通过测试不同的IAM特性来测试客户的云环境。在两个不同的AWS账户中发现了两个独立的与IAM角色相关的错误配置，这使得研究人员能够成功地破坏他们的云环境。下一节提供AWS IAM角色的入门教程。

AWS IAM角色

AWS IAM角色是一个IAM身份，提供对云用户或服务的临时访问。IAM角色的概念基于角色的访问控制。需要相同访问权限的用户被分配相同的角色，可以将多个角色分配给单个用户。在AWS中，分配角色的角色(即用户或服务)可以通过“伪装成”角色获得短期访问令牌。令牌允许角色访问授权资源，每个令牌都可以设置为在授予后的15分钟到12小时之间过期。一旦一个令牌过期，就需要请求一个新的令牌来继续访问。IAM角色的常见用例包括:

1.需要临时访问某些云资源的用户可以与一个授予特定权限的IAM角色相关联；

2.像EC2或AWS Lambda这样需要与特定云资源交互的云服务可以附加到IAM角色中；

3.具有现有身份提供者（IdP）（例如Azure Active Directory（AD）或OpenID）的组织可以使用IAM角色向由IdP管理的用户授予云访问权限。 AD中的现有用户可以简单地承担访问云的角色，而无需在云中拥有用户帐户。

4.一个云帐户的用户或服务可以跨帐户访问另一个云帐户，例如，假设云中的一组开发人员需要使用AWS CodeBuild与云B中的开发人员协作。在这种情况下，可以在云B中创建一个IAM角色，以授予云A中的开发人员访问权限。

风险组合策略

Unit 42为研究人员提供了开发人员在客户开发环境中的角色，以模拟内部攻击或由凭证泄漏引起的攻击。为了质量保证(QA)的目的，该环境承载了运行基础设施的多个副本，并被数百名开发人员积极使用。

Unit 42研究人员发现，具有开发人员角色的用户可以通过链接一组权限来获得管理员访问权限。AWS的管理员访问权限是“打开王国的钥匙”，允许攻击者对组织发起任何攻击，比如窃取敏感数据或摧毁整个基础设施。尽管这个开发环境没有运行工作负载，但攻击者可以使用在开发环境中观察到的信息来转向运行环境。研究人员发现，两种环境中都存在证书、代码库甚至错误配置。运行帐户中也有IAM角色，允许开发帐户中的用户担任这个角色，这意味着开发帐户中的攻击者可以通过假设获得运行帐户中的访问令牌，AssumeRole是允许跨账户访问的独特AWS角色。

One IAM permission that led to this vulnerability was IAM:PassRole. 

导致此漏洞的一个IAM权限是IAM:PassRole。 PassRole具备一项功能，允许委托人将IAM角色附加到另一个服务。例如，具有PassRole权限的用户可以创建EC2实例并将角色附加到VM。然后，该VM可以使用与角色相关联的权限来访问AWS资源。当角色需要使用AWS服务来管理其他AWS资源时，需要IAM PassRole权限。诸如EC2，Lambda，Glue和ECS之类的AWS服务都可以附加IAM角色以执行特定操作。

由于PassRole功能允许委托人向云服务授予权限，因此，如果其权限策略不受限制，就会被滥用。恶意角色可以将不需要的权限传递给服务，并利用该服务来代表其执行恶意活动。

委托人可以传递的IAM角色取决于委托人的权限策略和IAM角色的信任策略。权限策略限制了角色可以传递的IAM角色和角色可以传递给的服务。信任策略限制角色可以附加到的服务。

在下图1中，左侧是一个权限策略，该权限策略允许角色将具有特定名称（role/DevOpsEC2-* 和 role/DevOpsECS-*）的角色传递到服务列表（ec2.amazonaws.com 和 ecs.amazonaws.com）。右侧是IAM角色的信任政策。在这种情况下，它仅允许EC2服务承担角色。仅当满足以下所有条件时，委托人才能将角色传递给目标服务：

1.委托人的权限策略具有IAM:PassRole权限；

2.角色的名称与权限策略的资源字段中定义的模式匹配。

3.目标服务列在权限策略的条件字段中，如果没有条件字段，则委托人可以将角色传递给任何服务。

委托人的信任策略允许目标服务承担角色。

委托人将角色传递给服务的条件

如果委托人比角色具有更高的特权（具有更多的允许权限），则委托人可以访问该角色所附加的服务，那么潜在的权限也会升级。

图2说明了Unit 42研究人员是如何发现、利用并最终获得客户AWS云环境中的管理员访问权限的。研究人员确定并证实了攻击者为破坏环境可能采取的步骤。

攻击者使用权限链接来升级特权

1.攻击者通过网络钓鱼（例如，开发人员角色会话令牌）从员工那里窃取证书，攻击者通过使用AWS IAM API或枚举服务来查找令牌的权限。

2.攻击者发现令牌具有IAM:PassRole权限，并且对可以传递的角色没有任何限制，攻击者可以传递任何角色。

不受限制的PassRole权限

3.攻击者检查现有角色及其信任策略。通常，每个角色只能由服务承担。攻击者需要找到服务可以伪装成访问的角色，攻击者可以在找到满足条件的角色子集后继续前进。

现有角色及其信任策略

4.攻击者检查可以利用的角色的权限策略，如果这些角色中的任何一个都比攻击者的当前身份拥有更多的特权(即拥有更多的权限)，则攻击者可以将此角色传递给服务，并从该服务获得提升的特权。攻击者可以找到多个由EC2承担的具有AdministratorAccess的角色。

AdministratorAccess的现有角色

5.攻击者创建一个新的EC2实例，并将EC2ManagerRole附加到VM。然后，攻击者登录到VM，并在http://169.254.169[.]254/latest/meta-data上调用元数据服务API来检索会话令牌，该会话令牌使攻击者AdministratorAccess可以访问整个云。

在EC2实例中使用AdministratorAccess获取会话令牌

上面的步骤仅说明了使用错误配置的IAM:PassRole的一种可能的攻击路径，Unit 42的研究人员确定了客户环境中的多个IAM角色和服务，可以以相同的方式加以利用。

这个攻击路径的“类”是可利用的，因为开发人员角色的权限策略对PassRole操作没有限制(图3)。此外，AdministratorAccess被授予多个可以利用的IAM角色。考虑到每天都有数百名开发人员使用这个IdP角色，如果其中一名开发人员的笔记本电脑被黑客攻击，结果很有可能是整个网络都被破坏了的。有了网络管理员访问权限，恶意行为者可以侵入敏感数据，破坏业务运营或锁定整个基础架构。

在发现问题后，Unit 42的研究人员立即与客户合作，纠正错误配置并检查日志。幸运的是，目前还没有恶意攻击者成功利用了这种错误配置。