Cloud

正如我们前面所说的，cloud 是我们看到的许多公司有不安全环境配置的一个领域。最常见的一些问题是:

• Amazon S3 Missing Buckets: https://hackerone.com/reports/121461
• Amazon S3 Bucket Permissions: https://hackerone.com/reports/128088
• Being able to list and write files to public AWS buckets:
  • aws s3 ls s3://[bucketname]
  • aws s3 mv test.txt s3://[bucketname]
• Lack of Logging

在开始测试不同的 AWS 存储桶上的错误配置之前，我们需要首先发现它们。我们将尝试一些不同的工具，看看我们能在受害者的 AWS 基础设施上发现什么。

S3 Bucket Enumeration（S3 存储桶 枚举）

有许多工具可以为 AWS 执行 S3 bucket 枚举 。这些工具通常利用关键字或列表，应用多种排列，然后尝试去发现不同的 bucket。例如，我们可以使用一个名为 Slurp 的工具来查找关于目标 CyberSpaceKittens 的信息:

• cd /opt/slurp
• ./slurp domain -t cyberspacekittens.com
• ./slurp keyword -t cyberspacekittens

Bucket Finder

另一个工具 Bucket Finder 不仅会尝试查找不同的 bucket，还会从这些 bucket 中下载所有的内容进行分析:

• wget https://digi.ninja/files/bucket_finder_1.1.tar.bz2 -O bucket_finder_1.1.tar.bz2
• cd /opt/bucket_finder
• ./bucket_finder.rb —region us my_words —download

你一直在基于 Cyber Space Kittens 的基础设施进行搜寻，并发现了他们的一个 S3 bucket( cyberspacekittens.s3.amazonaws.com )。在 S3 bucket 中检索可见的和不可见的内容时，你的第一步要做什么呢？你可以首先把它弹到浏览器中来看一些信息:

在开始之前，我们需要创建一个 AWS 帐户来获得一个访问密钥 ID。你可以在 Amazon 免费创建你的帐户。创建帐户后，登录 AWS，转到你的安全凭据，然后转到访问密钥。一旦你有了 AWS Access ID 和密钥，我们就可以查询 S3 bucket 了。

查询 S3 并下载一切内容：

• 下载 awscli：
  • sudo apt install awscli
• 配置凭证：
  • aws configure
• 查看 CyberSpaceKittens 的 S3 bucket 的权限:
  • aws s3api get-bucket-acl —bucket cyberspacekittens
• 从 S3 Bucket 中读取文件：
  • aws s3 ls s3://cyberspacekittens
• 下载存在 S3 Bucket 中的所有内容：
  • aws s3 sync s3://cyberspacekittens

除了查询 S3 之外，接下来要测试的是写入该 bucket。如果我们有写的权限，可能就可以对它们的应用程序完成 RCE（远程命令执行）。我们经常看到，当 S3 bucket 上存储的文件被用于它们的所有页面时(并且如果我们可以修改这些文件)，那么我们就可以将恶意代码放到它们的 Web 应用服务器上。

写入 S3:

echo “test” > test.txt
aws s3 mv test.txt s3://cyberspacekittens
aws s3 ls s3://cyberspacekittens

注意，write 已被从 Everyone 组中删除。这只是为了示范。

修改 AWS Buckets 中的访问控制

在分析 AWS 的安全性时，我们需要检查关于对象和 bucket 的权限控制。对象是单独的文件，bucket 是存储的逻辑单元。如果配置不正确，任何用户都可能修改这些权限。

首先，我们可以查看每个对象来判断这些权限是否配置正确:

• aws s3api get-object-acl —bucket cyberspacekittens —key ignore.txt

我们可以看到只有一个名叫 “secure” 的用户对该文件有写的权限。文件不是对所有人开放的。如果我们有写的权限，就可以使用 s3api 中的put对象来修改该文件。

接下来，我们看看是否可以修改这些 bucket 本身。这可以通过以下命令来完成:

• aws s3api get-bucket-acl —bucket cyberspacekittens

同样，在这两种情况下，读权限都是全局允许的，但是完全控制或任何写入的权限只有名为 “secure” 的帐户才有。如果我们可以进入 bucket，那么我们可以使用—grant-full-control来赋予我们自己对 bucket 和对象的完全控制权限。

资源:

• https://labs.detectify.com/2017/07/13/a-deep-dive-into-aws-s3-access-controls-taking-full-control-over-your-assets/

子域名劫持

子域名劫持是一个常见的漏洞，如今我们几乎可以从每一个公司看到这个漏洞。如果一个公司使用用一些第三方 CMS/内容/云提供商，并将它们的子域名指向这些平台，那么就有可能发生子域名劫持漏洞。如果公司忘记配置第三方服务或从该服务器注销，攻击者就可以使用第三方来劫持该主机名。

举个例子，你使用 testlab.s3.amazonaws.com 这个域名注册了一个 S3 Amazon Bucket。然后，你让你公司的子域名 testlab.company.com 指向了 testlab.s3.amazonaws.com。一年后，你不再需要 testlab.s3.amazonaws.com 这个 S3 bucket 并注销了它，但是忘记了 testlab.company.com 的 CNAME 重定向。现在，一些人可以去 AWS 搭建 testlab.s3.amazon.com，并在受害者的域中有一个有效的 S3 bucket。

一个检查子域名漏洞的工具叫做tko-subs。我们可以用这个工具来检查是否有任何我们找到的子域名指向了一个 CMS 提供商(Heroku, Github, Shopify, Amazon S3, Amazon CloudFront 等)，这样该子域名可能可以被劫持。

运行 tko-subs:

cd /opt/tko-subs/
./tkosubs -domains=list.txt -data=providers-data.csv -output=output.csv

如果我们找到了一个悬挂记录，我们可以使用 tko-subs 来劫持 Github 页面和 Heroku 应用程序。否则，我们将不得不手工操作。

译者注: dagling CNAME, 即为 dangling DNS record，简称 Dare, 一般翻译为悬挂记录。这类 DNS 记录指向的资源无效，但记录本身尚未从 DNS 清除，攻击者可以借此实现 DNS 劫持。 拓展阅读：Understanding the Security Threats of Dangling DNS Records

另外两个可以帮助域名劫持的工具是:

• HostileSubBruteforcer
• autoSubTakeover

想了解更多关于AWS漏洞的信息吗?一个很棒的的 CTF AWS 演练 -> http://flaws.cloud/