攻击者|错误配置的IAM角色导致成千上万的云负载受攻击( 二 )


由于知道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 wasIAM: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服务承担角色。仅当满足以下所有条件时,委托人才能将角色传递给目标服务:

推荐阅读