不只是水桶：你知道你所有的公共资源吗？-搞营销

公开接触资源是许多安全从业者的恐惧点。对于寻求访问敏感信息或操纵活动的攻击者来说，公共资源是唾手可得的成果——甚至否认关键任务资源的可用性。

公开资源的一个众所周知的罪魁祸首是 AWS 内置机制。虽然错误配置它们是负责保护 AWS 环境的安全从业人员常见且合理的问题，但我们经常看到另一种可能更容易错误配置的机制：基于资源的策略。

我们将简要介绍内置机制，但主要关注这个鲜为人知的原因：资源策略的配置错综复杂，可以使资源像头灯下的鹿一样暴露在外。

谨慎行事：内置机制

AWS 提供了用于将某些资源类型配置为公共的内置机制。一种独特的机制是S3（简单存储服务）存储桶的访问控制列表(ACL)——一种广泛使用且高度耐用的 AWS 存储服务。ACL 机制可以使特定操作可公开访问以在存储桶上执行。

使用 ACL 时授予公共访问权限所需要做的就是允许“所有人”组的权限。您可以公开启用列出、写入或覆盖存储桶内容，甚至更改 ACL 本身。

不鼓励向所有人组授予权限是一种做法。当用户尝试进行此类配置时，AWS 会明确警告用户。此外，值得称赞的是，我们可以报告在 ACL 中将写入配置为公共权限或覆盖 ACL 的功能无法通过控制台使用，只能使用 cli。此限制将错误授予此类全面权限的可能性降至最低。AWS 还提供了有效的机制来彻底拒绝在存储桶和账户级别应用 ACL。

其他 AWS 内置机制也可用，包括 RDS 快照共享和 AMI EC2 图像共享，用于将不同于存储桶的资源类型配置为公共。现在让我们看看基于资源的策略，它可能与暴露资源的内置机制一样危险。

基于资源的策略不再通配符

基于资源的策略是一种可用于多种类型的 AWS 资源的机制，允许直接授予对资源的访问权限。与只能向账户中管理的委托人授予权限的 IAM 策略相比，基于资源的策略允许向账户外的委托人授予访问权限。一个指定用于授予权限的委托人……令人惊讶，惊喜：这最终可能是来自任何 AWS 账户的任何 AWS 委托人。让我们看看如何。

基于资源的策略中的语句可能如下所示：

{

      "Sid": "AllowAccessToExternalAccount",

      "Effect": "Allow",

      "Principal": {

        "AWS": "arn:aws:iam:::root"

      },

      "Action": [

        ":"

      ],

      "Resource": ""

 }

在这种情况下，“委托人”字段指定了一个配置，该配置允许另一个账户通过 IAM 策略授予对其中委托人的访问权限。基本的东西，对吧？然而，如果配置错误，基于资源的策略可以授予对任何主体的访问权限。

在多个现实世界场景（包括生产环境）中，我们发现基于资源的策略带有使用以下“Principal”字段定义的语句：

“主要的”：

{

     "AWS": "*"

}

当开发人员或 DevOps 工程师不确切知道哪个主体需要访问资源时，此通配符配置很方便。他们可能本能地认为开放式指定只允许访问资源帐户中的委托人，但事实并非如此。通配符“*”表示该声明适用于该策略可能适用的所有委托人——基于资源的策略可能适用于任何 AWS 账户中的任何 AWS 委托人。因此，该语句的实际效果是将该资源公开用于该语句允许且在其他地方未被拒绝的任何操作。

正如 Inigo Montoya 所说：

当“操作”字段也使用通配符时，情况会更糟，允许所有主体对资源执行可能的操作。还应该注意的是，在这种情况下，拒绝访问以执行由语句授予的操作的唯一方法是在基于资源的策略上使用另一个语句，条件是拒绝访问。例如，服务控制策略 (SCP) 不会有任何帮助，因为 SCP 仅适用于它们所附加到的帐户中的委托人。根据定义，SCP 不会影响来自外部账户的委托人。

错误的权力：错误配置的资源策略

我们在下面详细介绍了我们发现此类开放式或其他错误角色或策略配置的 AWS 资源类型及其对公开资源的潜在影响。请记住，这些实例不是理论上的；相反，它们是在由知名组织的精明基础架构团队配置的真实环境中检测到的。

为承担而公开的 IAM 角色

IAM 角色是一种令人兴奋的资源类型，我们发现它已配置为公开展示。IAM 角色是 AWS 资源，其“信任关系”是基于资源的策略。允许 sts: Assume Role to “AWS”: {“*”} 将使该角色可能由任何委托人承担。

这个用例很有趣，因为允许担任 IAM 角色的外部委托人将能够使用附加到该角色的每个策略中的所有权限。这种错误配置具有巨大的潜在后果：它很可能允许环境中的所有外部主体拥有令人难以置信的强大权限（直至管理员级别）。

破坏 ECR 存储库中的图像权限

AWS 的Elastic Container Registry (ECR) 是一项服务，可让您“在任何地方存储、共享和部署您的容器软件”。您创建存储库以轻松存储和管理您或与您共享它们的任何人稍后将拉取以在容器上部署应用程序的容器映像——例如，使用 AWS 的弹性容器服务上的任务定义。ECR 提供了其他出色的功能，例如扫描存储的容器镜像中的漏洞——它们的 API 允许您在部署过程中简化镜像和版本生命周期的管理。

ECR 存储库也是一种 AWS 资源。正如您可能已经猜到的那样，它们支持基于资源的策略，我们已经看到了错误配置。让我们来说明问题：允许身份将图像推送到 ECR 存储库需要以下一组权限：

“行动”：

[

      "ecr:CompleteLayerUpload",

      "ecr:UploadLayerPart",

      "ecr:GetAuthorizationToken",

      "ecr:InitiateLayerUpload",

      "ecr:BatchCheckLayerAvailability",

      "ecr:PutImage"

]

授予这些权限的身份可能能够将新图像推送到具有特定标签的存储库；这样做有效地替换了 ECS 任务定义中当前使用的版本，或者可以使用其他工具拉取以进行部署的版本。此配置具有潜在的严重影响。它可能允许恶意行为者使用受害者对部署它的服务的权限来运行其软件。

请注意，如果您在存储库上设置了不可变标签，则无法将图像推送到现有标签下。但是，有权访问 ecr:PutImageTagMutability 的恶意行为者也可以更改此配置。

恶意行为者还可以使用 ecr:DeleteRepository 或 ecr:BatchDeleteImages 删除存储库并中断其服务。最后，如果容器包含敏感信息或逻辑，则不一定要公开；即使是允许拉取图像的 ecr:BatchGetImage （以及用于身份验证的 ecr:GetAuthorizationToken）之类的权限也可能非常敏感。

通过 KMS 密钥拒绝服务和解密

在 AWS 中，使用 IAM 策略和密钥策略（KMS 的基于资源的策略）管理对客户管理的 KMS 密钥的访问，这也可以对公开可用的密钥采取行动。

在我们最近关于可用于对配置错误的 S3 存储桶执行勒索软件攻击的权限组合的研究中，我们讨论了使用 kms:PutKeyPolicy 权限来更改密钥策略集客户管理的 KMS 密钥。仅通过这个简单的操作，恶意行为者就可以劫持并拒绝访问密钥。这样做会限制在密钥上使用 kms:Decrypt 的能力——有效地对使用密钥加密的所有数据执行拒绝服务攻击。此拒绝在跨账户方案中不起作用，但允许对管理密钥的账户内的所有委托人授予权限。

另一个有趣的权限是 kms:CreateGrant，它可以跨账户使用，并为任何主体提供加密操作权限，包括密钥上的 kms:Decrypt。AWS 文档说： “受让人委托人可以是不同 AWS 账户中的身份。”

换句话说，如果此权限在密钥上公开，几乎任何人都可以使用它进行解密。

让其他人了解您的 Secrets Manager 机密

众所周知，AWS 的 Secret Manager 非常适合安全地保存敏感字符串，这些字符串可能会被运行在无服务器资源和其他计算功能上的应用程序访问。Secrets Manager 密钥是支持基于资源的策略的 AWS 资源。可以通过上述方法公开资源——并通过向外部身份提供访问权限，例如 secretsmanager:GetSecretValue，这是存储在秘密中的敏感信息。敏感信息可以是数据库连接字符串、API 密钥、访问令牌等。通过此权限轻松公开秘密是一个很好的例子，说明为什么使用客户管理的 KMS 密钥对秘密进行加密是一个很好的例子合理的想法：即使秘密被公开，

中断和访问 SQS 队列

AWS 的简单队列服务(SQS) 是一个完全托管的 MQ，根据 AWS 的说法，您可以使用它来“在软件组件之间发送、存储和接收消息”。这是一种以编写软件为代价将开发人员从管理和操作此类中间件中解放出来的好方法。但是，如果对队列的特定权限的访问受到损害，则队列可能会面临某些风险。例如，恶意行为者可能能够使用 sqs:ReceiveMessage 访问在其上传输的敏感数据，通过使用 sqs:SendMessage 发送消息来操纵队列的活动，中断其活动，并通过完全删除队列来导致您的操作发生故障使用 sqs:DeleteQueue（注意这个权限不能跨账户使用）或者使用 sqs:PurgeQueue 清除队列的当前内容。

搞砸 SNS 主题的交流

AWS 的简单通知服务(SNS) 是一种工具，可在发布者/订阅者模型上实现应用程序到应用程序或应用程序到个人的通信。用户为每个主题创建主题（AWS 资源）和订阅，包括对协议和端点（例如电子邮件地址）的描述，一旦在主题上发布消息就会到达这些端点。

获得 sns:Subscribe 访问权限的恶意行为者还可以访问在该主题上共享的信息。通过访问 sns:Publish，恶意行为者可以向主题的订阅者广播信息。使用 sns:DeleteTopic 或 sns:Unsubscribe 等权限可能会中断服务活动。即使使用模式 sns:List* 或 sns:Get* 的其他读取权限，恶意行为者也可以收集有关 SNS 支持的业务活动的敏感信息。