背景介绍：
Aquatone是什么？
Aquatone 是一种对大量主机上的网站进行可视化检查的工具，可以方便地快速了解基于 HTTP 的攻击面。
工具地址：https://github.com/michenriksen/aquatone
使用方法：
略
那么我们来看看某位白帽子使用 Aquatone 配合挖洞的收获：
漏洞
赏金
SSRF 允许访问 Google VM 元数据 $2400
SSRF 允许访问内部端口 $500
XXXX Portal Tickets 泄露 $750
SSRF 允许访问 Google VM 元数据 ：
首先从 Aquatone 结果中脱颖而出的是一个应用测试的网页，Web 根目录如下所示：
它要求我们提供一个网站 URL 来“开始测试”，虽然不知道这将执行什么样的测试，但可以尝试给它 https://example.com 然后看看它会做什么。
经过一段时间的等待后，出现了 https://example.com 的屏幕截图，其中包含许多其它性能指标。
我们感兴趣的是 https://example.com 的页面截图，证明该应用程序向 https://example.com 发送了请求并向我们提供了网站截图。
这是应用程序的预期行为，请求任意 URL 的能力本身并不是漏洞，当应用程序向云元数据 URL 或本地主机等能够暴露敏感信息的受限 URL 发出请求时，才会出现漏洞。
那么给它 https://127.0.0.1 来测试看看。经过一段时间的等待后，结果令人失望。
显示错误“无法访问此站点”。
我们将请求发送到 Burp Suite Intruder 并开始对前 1000 个端口进行端口扫描，所有这些测试都需要 2-3 分钟才能完成。就算 2 分钟完成1个测试的最佳情况，我们仍需要 2000 分钟（即 33.33 小时）来执行 1000 个端口的扫描。
为了找到解决方法，我们尝试找到一些选项来禁用一些我们认为花费了大部分时间的“测试”。
虽然禁用了一些选项，但 2-3 分钟的延迟依然存在，所以这可能是某种互联网问题或浏览器问题。
然而，在测试这个时，白帽小哥不小心犯了错误，在提交新 URL 进行测试之前，所有旧 URL 测试必须已完成，如果未完成，则新的 URL 测试将进入等待队列，但是在这之前，白帽小哥已经向服务器发送了 1000 个端口扫描的请求。
苦等两天后，所有的测试终于完成了，在检查了所有屏幕截图后，再次失望，因为没有一个端口正在运行 HTTP 服务…
于是白帽小哥又尝试使用 file:// 协议来检索 /etc/passwd ，但这同样不起作用。
于是白帽小哥继续尝试检索云元数据，因为目标将所有基础设施托管在 GCP (Google Cloud Platform)上。
要检索 Google 元数据，我们需要在请求中带有两个自定义标头的http://metadata.google.internal/computeMetadata/v1/ URL，如下所示：
X-Google-Metadata-Request: True
Metadata-Flavor: Google幸运的是，该应用程序提供了在开始测试之前添加自定义标头的功能。
添加了标头并再次进行测试，空白截图再次令人失望。图片
于是白帽小哥决定放弃云元数据，并尝试检查一些常见端口，例如 8080、8125、80、5000 等，结果跟上面一样。白帽小哥决定让自己休息一下。
5 天后，再次尝试检索 Google 云元数据，这次尝试了其它几个端点，例如：
/computeMetadata/v1/instance/hostname
/computeMetadata/v1/instance/id
/computeMetadata/v1/instance/image白帽小哥还使用了非常有用的 Cloud Metadata Wordlist Gist，然而，这些端点似乎都不适用于现在的情况。
于是白帽小哥开始用用谷歌搜索“谷歌云元数据”，第一个结果是关于如何访问虚拟机元数据的官方文档，当阅读这份文档时，它提到了以下端点：
/computeMetadata/v1/instance/tags尝试使用该端点进行测试，令人惊讶的是，截图终于有了输出！
屏幕截图的质量非常糟糕，截图尺寸太小，很难看清。为了能够查看这些有意义的元数据，需要找到更好的方法。
在研究了不同的功能之后，白帽小哥找到了一种查看生成的 HTML 内容的方法，就是单击“查看 JSON 结果”按钮，单击后，应用程序以 JSON 格式显示性能指标和所有其它信息。
通过这个按钮，能够在名为“html”的 JSON 字段中看到生成的 HTML 内容。
再次检查以下端点：
/computeMetadata/v1/instance/disks/?recursive=true
成功列出了所有磁盘信息！
SSRF 允许访问内部端口：
某个 IP 的 Web 应用程序根目录显示了搜索功能，如下所示。
在这里，可以看到“Cluster”下拉列表旁边显示了一个 URL，我们可以将下拉列表更改为其它 URL 选项，经过初步猜测，我们应该可以在开发/生产环境之间切换Cluster。
搜索字符串“test”时，会向 /search 端点发送 POST 请求以及许多其它参数。
几个关键参数的详细说明如下：
参数
解释
url 这是搜索请求发送到的URL，如果使用下拉列表更改集群，则此URL也将更改
sortby 这是对结果进行排序的标准
sortorder 根据值升序或降序
keyword 在集群中搜索的关键字
page 用于分页目的
storeid 必须搜索的商店标识符
根据以上参数，假设 Web 应用程序的流程如下：
在这里， url 参数是否可以作为 SSRF 进行攻击，先把这个疑问放一边，先尝试寻找 SQL 注入看看。
测试了所有参数和所有集群 URL后，发现它们都是安全的，并且在任何集群中都不存在 SQL 注入。
现在，回到 SSRF，将 url 参数更改为PoC，可以看到服务器响应了 JSONDecodeError 和详细的堆栈跟踪。
你可能会问“为什么会出现这种异常？”这是因为 Web 应用程序正在尝试从 PoC URL 返回的数据进行 JSON 解码，但 PoC URL 未发送有效的 JSON 数据，它发送的是正常的 HTML。
通过利用这个错误信息，就可以枚举易受攻击服务器上打开的 HTTP 服务了。
这背后的逻辑是：如果服务器上运行 Web 服务，它将返回一些 HTML 数据， Web 应用程序将尝试对 HTML 数据进行 JSON 解码，因此将引发异常。
将请求发送给 Burp Suite Intruder，并将 url 参数更改为 http://127.0.0.1:§1§ ，Fuzz 1 – 5000 端口。
探测结束后，可以看到端口 5000 已打开并正在运行易受攻击的服务。
其它端口则返回 ConnectionError 异常。
XXXX Portal Tickets 泄露：
下面这台主机的根目录显示了某种有趣的仪表板：
它显示了不同的功能，如事件、Tickets、变更等，API 限制了对某些功能的访问，然而，只有部分功能受到保护，大多数功能无需任何身份验证即可访问。
下图可以查看所有开放的 Tickets 信息。
经验分享：
-与志同道合的人合作
-如果利用方式不起作用，请不要轻易放弃，休息一下然后再试试看
-漏洞挖掘并不是那么容易，有时你会花费 12 小时以上，却找不到任何漏洞，甚至无法找到有用的东西，有时却能很幸运，通过像 Aquatone 这样的工具发现多个漏洞
-适当地给自己放个假或是休个假
感谢阅读，希望本文对你有所帮助。如果觉得还不错的话，欢迎分享给更多喜爱的朋友们。
