1. 发现敏感接口

首先，我从 Hackerone 收集了一些项目信息。

我进行了常规的一些测试，例如 Web bug 和 IDOR，但我完全没有发现任何机会。过滤器和身份验证机制非常强大，使用 uuid 作为参数进行身份验证，所以无法利用 uuid 发现 IDOR 漏洞。

已经是第二天早上了，我还没有发现任何错误。我决定休息一下，喝杯咖啡。

我决定再次浏览 Burp 的 HttpHistory，看看是否有任何我可能遗漏的敏感请求。

哇，终于，我遇到了一个敏感的 Graphql 请求。

POST /agw/graphql?op=UrlReachableVerifierQuery&client_trace_id=09bee58d-8358-4f00-acc0-8d26d0018d32,rst:1678201703792 HTTP/1.1Host: xxxxxCookie: xxxxUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101Firefox/110.0Accept: */*Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateContent-Type: application/jsonAuthorization: xxxxxContent-Length: 386Origin: https://xxxxxSec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-siteTe: trailersConnection: close{"operationName":"UrlReachableVerifierQuery","variables":{"url":"http://xxxx.com/"},"query":"query UrlReachableVerifierQuery($url: String!) {nverifyUrlReachable(url: $url) {n... on UrlReachableResult {n__typenamen }n ... on GenericError {n__typenamen }n __typenamen

2. 找到一个 Blind SSRF

我注意到json数据中有一个url参数，所以我决定尝试 ssrf。我立即使用 Burp 的 Collaborator 来测试 dns 日志。

不出所料，我收到了来自两个不同 IP 地址的 HTTP 请求。这是一个blind型的 SSRF。另外，Graphql接口返回了json数据，其中包含两个键：“url”和“__typename”。

我确认了一下，发现这个IP属于谷歌云。Google Cloud 元数据请求需要包含特定的标头，如下所示：

request example:curl "http://metadata.google.internal/computeMetadata/v1/instance/image" -H "Metadata-Flavor: Google"

元数据是指在ECS实例内部通过访问元数据服务（Metadata Service）获取的实例属性等信息，如实例ID、VPC信息、网卡信息。通过元数据服务，您无需登录控制台或调用API，在实例内部即可获取实例信息，可以更便捷、安全地配置或管理正在运行的实例或实例上的程序。例如，在基于ECS实例的应用程序中，通过元数据获取实例RAM角色的临时访问凭证，以安全地访问相关授权资源（比如访问OSS下载文件）。

显然Metadata-Flavor头无法添加，所以这里不能直接利用。

3. 使用 GraphQL 探索新的攻击面

所以，让我们回到上一点。此接口基于 Graphql 进行查询。我们可以自定义查询的列（param）。如果存在此类列，它将返回该参数的有效结果。因此，让我们开始模糊测试。

但是，仍然没有可利用的参数。

我很想放弃，但再看一眼请求 URL，我仔细观察了 Graphql 查询请求中的“op”参数，这给了我一点想法。

“op”参数的值为“UrlReachableVerifierQuery”。

为什么不尝试将其用作查询中的列呢？

因此，在使用“UrlReachable”字段进行测试时，我在响应中发现了“Reachable”的有效回显。

哇，现在我们可以使用这个 API 来探测内部网络端口的可用性。

我直接用谷歌云元数据地址检查了端口连通性，没想到，它只是回复了“Not_Reachable”......

关于谷歌元数据地址169.254.169.254可参考：

4. 绕过 SSRF 限制以探测内部网络

我尝试了 302 重定向和短链接等方法，但没有一个奏效。因此，我求助于使用 DNS 重新绑定。我在 Ceye 上配置了 DNS 重新绑定 IP 地址（使用 Google Cloud 元数据 IP 地址）来验证内部网络连接。关于DNS重绑定技术可自行百度。

因此，我们可以直接使用 DNS 重新绑定来绕过 SSRF 限制。我们已经成功获得了“Reachable”的结果！现在，下一步是探测端口连接。

端口 80 可访问，但其他端口无法访问。这证明在这种情况下，SSRF 可用于探测内部网络。

原文始发于微信公众号（薯条机器猫）：如何让SSRF漏洞起死回生