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

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

过于宽松的IAM信任政策

研究人员从该客户的GitHub页面上找到了该客户的运行AWS账户ID。GitHub页面托管用于与客户产品集成的指令和脚本。有了账户ID，研究人员就可以通过假设一列角色名称来列举错误配置的IAM角色。很快就找到了一个可以匿名扮演的配置不当的角色。图7展示了研究人员如何识别和确认攻击者可以采取的破坏环境的步骤:

攻击者攻击云的路径

攻击者通过侦察和枚举获得一个角色名称列表(例如prodApp-nat, prodApp-app2-nat)。因为角色名称不长，而且在某种程度上是可预测的，所以可以通过枚举找到配置错误的角色。

允许匿名访问的IAM角色信任策略

2. 攻击者通过伪装成错误配置的角色获得临时访问令牌，使用访问令牌，攻击者可以枚举权限并找到它可以访问的资源。

配置错误的IAM角色限制了对EC2、S3和KMS服务的访问

3.攻击者可以看到所有EC2实例并读取它们的元数据，从元数据中的启动脚本中，攻击者可以获得诸如VM部署的Docker映像、VM查询的数据库以及S3存储VM从中提取数据等信息。

EC2元数据示例显示了VM可以访问的S3 存储桶

4. 然后攻击者访问在EC2元数据中找到的S3 存储桶并下载所有数据。有证书密钥、用于部署应用程序的多个shell脚本和一些包含凭证的加密文件。

被破坏的S3 存储桶中的敏感文件

5. 攻击者使用角色可用的AWS KMS解密功能解密密文，现在向攻击者提供明文访问凭据。

6. 在获得明文凭据之后，攻击者可以横向移动并访问Docker Hub存储库、Splunk服务器和数据库。

Docker Hub中受攻击的源代码存储库

这个错误配置的IAM角色是一个关键的漏洞，因为它允许未经身份验证的攻击者远程利用它。有了证书的私钥，攻击者就可以发起中间人攻击，或者模仿公司的官方网站。通过访问源代码库，攻击者可以泄漏公司的知识产权，发现漏洞，甚至在源代码中注入恶意软件。幸运的是，没有恶意攻击者成功利用这种错误配置。

野外错误配置IAM信任策略

由于可以通过远程和匿名的方式检查IAM信任策略的配置，Unit 42的研究人员很好奇地发现这种错误配置非常普遍。研究人员的方法是利用GitHub上的公开数据进行侦察行动。

搜索错误配置的IAM角色类似于搜索允许不使用密码登录的公开数据库，Unit 42的研究人员没有扫描IP地址和端口，而是扫描AWS的账户ID。研究人员搜索的不是无需密码即可通过身份验证的数据库用户，而是可以匿名扮演的IAM角色。如果正确猜测了配置错误的角色的名称，则研究人员(或攻击者)可以伪装成该角色并获得访问令牌。

总的来说，Unit 42的研究人员分析了145623个存储库中的283751个文件，确定了32987个已确认的AWS账户ID和68361个角色名称。图13展示了研究方法:

在GitHub上找到错误配置的IAM角色的方法

Unit 42研究人员使用GitHub API搜索可能包含亚马逊资源名(ARN)或AWS IAM角色名称的文件。研究人员使用IAM文档中列出的所有可能的资源名称作为关键字来查询GitHub API。例如，关键字arn:aws:amplify与aws amplify arn匹配，关键字arn:aws:cloud9与aws cloud9 arn匹配。IAM角色名称也可能出现在IAM ARN中，如ARN:aws: IAM:123456789012: Role /MyTestRole。因为AWS在3个不同的分区中操作，所以在搜索关键字中也使用了不同的分区名(AWS、AWS -cn、AWS -us-gov)。

在下载完所有文件后，Unit 42的研究人员首先使用正则表达式提取出潜在的帐户ID和角色名称。如果文件为AWS CloudFormation或Terraform格式，则该文件将进一步解析为一个JSON对象，并分析所有的属性名称。由于IaC模板的流行，下载的文件中有70%以上是IaC，这使得分析更容易、更准确。

因为不是所有提取的帐户ID都是有效的，研究人员使用AWS管理控制台页面来验证每个帐户ID。AWS在为每个活动帐户创建一个控制台页面。如果帐户ID存在并且是活动的，发送一个http请求到这个URL将收到一个HTTP 200响应。在AWS -cn和AWS -us-gov分区中的AWS帐户也可以使用类似的url分别测试https://account_alias_or_id.signin.amazonaws.cn/console/和https://account_alias_or_id.signin.amazonaws-usgov.com/console/。

尝试访问不存在的AWS帐户ID的控制台页面

4. 在AWS帐户中查找现有角色名称类似于在数据库中强制使用无密码用户名，由于Rhino Security Labs发布的技术，可以检查AWS帐户中是否存在角色名称，而不会在目标帐户中留下任何跟踪信息。该技术滥用AWS IAM信任策略验证器来检查角色字段中指定的IAM角色是否存在。Unit 42研究人员用步骤2中确定的角色名称的子集来枚举每个经过验证的帐户ID。首先测试了在GitHub存储库中与账号ID相同的角色名称，然后是GitHub中最常见的500个IAM角色名称。

尝试将角色设置为不存在的IAM角色

5. 为了检查现有的IAM角色是否可以匿名伪装成，Unit 42的研究人员尝试使用assume-role命令来伪装成每个角色。如果可以以匿名方式伪装成该角色，则将返回一个密钥和会话令牌集。注意，该步骤将日志保留在目标帐户上，而不管是否成功地伪装成了该角色。

在配置错误的帐户中，发现了数十万个EC2快照、数千个EC2卷和数百个S3 存储桶，从配置错误的IAM角色泄漏的资源依赖于角色本身的权限策略。Unit 42研究人员发现配置错误的DevOps角色接近系统管理员权限，还发现了配置不当的DBAccess角色，这些角色可以访问数据库服务，如Amazon DynamoDB和Amazon Redshift。最后，LambdaExecution角色只允许对Lambda函数进行基本的Get和Invoke操作。

最值得注意的是，该研究发现属于十亿美元组织的帐户配置有误，一家美国制药公司和一家位于巴西的金融公司。

无论这些配置不当的角色可以访问哪种类型的资源，它们都泄漏了恶意攻击者可以利用的信息。一个受攻击的云帐户可能比受攻击的云主机更糟糕，因为云帐户可能访问数百或数千个云资源。云中的资源似乎无穷无尽，这使得基础设施成为一个吸引攻击的目标，甚至一个只有LambdaExecution权限的帐户也可以通过调用大量的函数调用来发起攻击。

总结

人类在很多事情上都很擅长，但是识别数百个身份中的危险权限是自动化的最佳任务。研究表明，几乎每个云环境中都存在过度宽松或陈旧的帐户。尽管云提供商为实施权限的最小特权方法提供了一个良好的基准，但是随着云在多个提供商之间的采用，这种情况就被打破了。 IAM的复杂和动态性质使其很难连续保持在安全状态，当添加新角色或编辑现有策略时，今天的安全IAM明天可能变得不安全。尽管如此，良好的IAM策略也可以大大降低风险。

Unit 42的研究人员建议使用以下最佳做法：

AWS用户

对敏感数据和工作载荷的粒度访问控制（最低特权）：仅向用户和服务授予绝对需要的权限。一些例子：

如果某项服务仅需要访问S3存储桶中的几个文件，则不要授予该服务对整个存储桶的访问权限。

如果服务仅需要使用KMS中的特定密钥对数据进行解密/加密，则不要授予服务访问整个KMS的权限。

如果仅特定服务访问S3存储桶中的敏感文件或KMS中的密钥，请阻止来自该服务以外的其他来源的所有流量。

强化IAM角色的信任策略：切勿向任何IAM角色授予匿名访问权限 (“Principal” : { “AWS” : “*” }) 。通过添加随机字符串，使角色名称难以猜测。如果该角色在AWS账户之间共享，则强制使用不可猜测的外部ID作为另一层保护。如果角色仅由用户或来自特定IP地址的服务承担，请对委托人的源IP施加条件。

强化IAM：PassRole权限：在策略中授予IAM：PassRole权限时，请始终对以下内容实施限制：

1.角色可以传递的角色名称；

2.委托人可以传递角色的服务。

所有CSP用户

启用MFA：如果主要密码被泄露，多因素身份验证（MFA）可提供另一层安全保护，可以同时为用户和IAM角色启用MFA。

自动执行凭据轮换：实施自动化流程以轮播在云环境中使用的凭据。定期轮换凭证可以缓解凭证泄漏的风险。

强化IAM：PassRole权限：在策略中授予IAM：PassRole权限时，请始终对以下内容实施限制：

1.角色可以传递的角色名称；

2.委托人可以传递角色的服务；

创建具有精细权限的组或角色：同一项目中的用户往往具有相似的权限要求，可以将其置于同一组或角色中以简化权限管理。但是，如果有较小的团队在项目的不同部分工作，则应为每个团队创建具有较小权限边界的角色或组。

监控IAM API：所有主要的云服务提供商都具有监控IAM使用情况的服务，这些服务有助于识别异常活动，例如暴力攻击和无法识别的设备或位置的日志记录。

利用云原生安全平台：通过访问不断扩展的敏感资源来管理大量特权用户可能是一个挑战。 最重要的是，云资源本身具有需要管理的权限集。 Prisma Cloud等云原生安全平台（CNSP）有助于利用云资源的身份来实施安全策略并确保跨多个云环境的安全用户行为。