作者简介：肖文迪，OWASP中国广东分公司负责人，网络安全Plus社区杰出专家，现任外企安全架构师，负责应用安全设计、管理和审核。最近，一位外籍同事向我推荐了WIZ发起的名为Big IAM挑战赛的CTF，通过它我可以窥见豹子，深入了解AWS的IAM安全。
AWS IAM （Identity and Access Management） 是 Amazon Web Services 中的一项身份和访问管理服务，用于管理对 AWS 资源的访问和安全性。 IAM 允许用户与 AWS 交互，并且每个用户都会获得一个唯一的凭证（访问密钥 ID 和秘密访问密钥），以便使用 API 或 SDK 调用与 AWS 服务进行交互。
IAM 包括 IAM 用户、组和角色等概念，可用于精细控制对 AWS 服务和资源的访问。 通过使用 IAM，可以更好地管理和限制对 AWS 资源的访问，并实施权限分离和安全最佳实践。
需要注意的是，在使用 IAM 时，您需要遵循最佳实践，例如分离权限、创建复杂的密码策略以及定期更改 API 密钥，以确保 AWS 资源的安全性。 但这些做法就足够了吗？IAM安全的具体漏洞有哪些，我们可以看看IAM CTF，亲身体验一下。
AWS IAM CTF 和其他 CTF 一样，就是通过对标题的描述来寻找隐藏的旗帜，也就是所谓的夺旗比赛。 如果您对 AWS IAM CTF 感兴趣，可以访问以下地址：
此 CTF 共有 6 个级别，即 6 个 IAM 安全问题。
第一级
这个级别比较简单，IAM的策略，如下图所示：
不难发现，该策略允许匿名访问 s3 存储桶“thebigiamchallenge-storage-9979f4b”的目录和 ** 中的文件，很明显标志文件在 s3 存储桶的 files 文件中。 这里的顺序如下：
aws s3 ls s3://thebigiamchallenge-storage-9979f4b/aws s3 ls s3://thebigiamchallenge-storage-9979f4b/files/aws s3 cp s3://thebigiamchallenge-storage-9979f4b/files/flag1.txt -尤其是第三个命令，如果你没有权限创建文件或文件到本地计算机，你可以直接使用这个命令查看文件的内容。
第二级
该问题与SQS有关，IAM策略不限制SQS的权限。 IAM 策略如下：
既然没有限制，我们可以自己订阅这个sqs，然后看里面的内容，旗帜就在里面。 此处使用的命令行包括：
aws sqs receive-message --queue-url --attribute-names all --message-attribute-names allSQS 的 URL 可以根据 IAM 策略的内容按以下格式进行组合：
https://sqs..amazonaws.com，根据上述结果，很容易获得 sqs is 的 URL。
从返回值的正文中获取 URL，并打开它以获取标志。
第三层
此级别与 SNS 有关，请参阅 IAM 策略，并且终端节点受到限制。 IAM策略如下图所示：
此处的限制是 sns：endpoint 必须包含@tbicwiz.io。乍一看，它看起来像一个电子邮件地址，但如果它是一个电子邮件地址，我们就无法获得 TBICwiz.io。 如果你仔细看 sns 的 endpoint 描述，你会发现有多种 endpoint 类型，并且所有 endpoint 都是使用 sns：endpoint 定义的，这方便我们绕过这个限制。
通过简单的分析，很容易知道，当端点是 http s 时，端点的地址就是 url，我们可以在 url 中包含@tbicwiz.IO，如 https：，可以满足获取 SNS 内容的要求。
我们只需使用 Python 的 Flask 来构建一个 Web 服务，它接受 HTTP 请求并打印出 HTTP 请求或 Repspose，或者通过 BurpSuite 等工具捕获传入和传出的 HTTP 请求。
接下来，使用 ngrok 将本地服务映射到 Internet，例如“ngrok http localhost：8080”。
然后使用以下 url：https： 订阅 SNS，命令如下：
aws sns subscribe --topic-arn arn:aws:sns:us-east-1:092297851374:tbicwizpushnotifications --protocol https --notification-endpoint https:/此时，观察 Web 服务，您首先会收到一个带有 URL 的请求，单击此 URL 以确认订阅。 然后我收到一个返回值中带有标志的请求。
4级
这仍然是关于 S3 的，请参阅 iam 策略：
从IAM策略中可以看出，读取S3对象不需要任何权限，但需要特定用户admin来获取S3存储桶的对象列表，因此该级别的关键是如何绕过特定用户的限制来获取S3存储桶的对象列表。
答案非常简单，只需添加一个特殊参数“-no-sign-request”即可绕过此限制，命令行如下：
aws s3 ls s3://thebigiamchallenge-admin-storage-abf1321/files/ --no-sign-request然后就可以使用普通命令来获取文件的内容，具体参考第一级的内容，从而获取标志。
5级
此级别看起来像是关于 Cognito 的，IAM 策略如下：
但是，从 IAM 策略中，我们只能知道我们想要获取 Cognito 证书，然后使用这个 Cognito 证书来获取 S3 存储桶中的内容，并且标志应该在 S3 中。
如果什么都看不到，我们考虑看页面的来源**，这时有一个惊喜的发现。
从源**可以看出，AWS认证信息其实是写在页面上的，而此时，使用chrome控制台，很容易获取到这些信息，并复用这些信息来获取S3存储桶中的内容。
在这里，您将遇到CORS错误的新问题，错误消息为：
这时候，换个思路，不是直接获取数据，而是拿到S3的签名URL，这个时候不会出错。
此时，您可以通过访问签名的 URL 来查看标志文件的名称。 然后，使用与上述相同的思路，您可以获取与文件对应的签名 URL。
打开此签名 URL 以获取相应的标志。
6级
此级别仍与 Cognito 有关，其 IAM 策略为：
内容没有问题，认知身份的价值受到严格限制。 该标题还提供了 iam 角色的名称 arn：aws：iam：：092297851374：role cognito s3accessauth role，让我们尝试使用此 iam 角色进行访问。
以上信息是从 Cognito 到 IAM 角色建立连接，这能做到吗？显示是可以实现的。
首先，您可以通过命令获取 id：：of cognito-identity
aws cognito-identity get-id --identity-pool-id us-east-1:b73cb2d2-0d00-4e77-8e80-f99d9c13da3b然后，基于此 ID，您可以获取 cognito-identity 的开放 ID 令牌
aws cognito-identity get-open-id-token --identity-id最后，使用获取的 Open ID 令牌与 IAM 角色建立连接。
aws sts assume-role-with-web-identity \ duration-seconds 3600 \ role-session-name ctf2 \ role-arn arn:aws:iam::092297851374:role/cognito_s3accessauth_role \ web-identity-token "jwt token"这将创建一个 ctf2 role-session，然后使用此 role-session 获取 s3 存储桶列表并读取内容。 这可以使用 python boto3 库来完成。
通过此 S3 客户端对象，您可以获取 S3 存储桶列表，并通过生成签名 URL 来获取标志来读取内容。
通过以上6个层次的总结，你会发现在不经意的地方存在漏洞。
例如，在Level 1中，由于没有权限限制，S3存储桶在互联网上暴露给公众很多情况，导致敏感数据泄露。
例如，在第 2 级中，由于对 SQS 没有限制，因此可以在任何地方访问 SQS。 作为 SaaS 服务，即使您创建了自己的 VPC，也可以通过 Internet 直接访问 SQS，这一点非常重要。 我不禁想到了 Elasticsearch、Kafka 等服务，这些服务经常暴露在互联网上，暴露的资源也可以通过扫描轻松获取，导致敏感数据泄露。
例如，在第 3 级中，SNS 似乎有权限限制，但为了方便起见，使用了通配符 *，旨在限制对公司自己邮箱的访问，但 SNS 的端点设计不考虑一个点，所有端点共享一个参数进行控制。 此时很容易被绕过，导致敏感数据泄露。 有时便利是安全的敌人，便利也是恶意攻击者的便利，所以要小心。
例如，在第 4 级，我不熟悉 S3 的 API 命令，也不知道 AWS 为什么要设置这个 API 接口，所以我可以在未经许可的情况下获取 S3 存储桶中的列表。 我觉得最严重的是s3桶被设置为人人都能拿到文件，这是最致命的。 通过目前的实践，我们发现大家都没有意识到自己的内容已经放到了公网上，如果你不做好权限控制，大家都可以获取到你的信息。 您可以返回，看看是否会在 S3 存储桶中发现任何惊喜。
比如Level 5，这个就是设计缺陷，真没想到把AWS访问密钥的信息放在前端，难道你不知道前端**是大家都能看到和操作的吗？并且前端**的变量也可以纵。 这不仅限于CTF游戏，您可以查看是否有类似的情况。
例如，在第 6 级中，Cognito 服务可以与 IAM 角色相关联，这很糟糕。 基于以上经验，如果能获取到Cognito的开放ID令牌，然后知道IAM角色的ARN，就可以生成一个IAM角色会话，其中包含AWS会话的AWS访问ID、AWS私有密钥、敏感信息，然后利用这些信息伪造使用这个IAM角色进行操作。 看起来有点吓人，你有这种感觉吗？
基于以上分析，IAM安全可能看起来并不那么安全，所以你应该根据AWS官方文档查看安全最佳实践，或者使用KICS等工具扫描Terraform、CloudFormation等，以确保我们的IAM在一开始就符合最佳安全实践。
IAM安全说起来容易做起来难，我们需要谨慎。