重生之我是赏金猎人(十一)-从忽略到triage再到失望bounty的SSRF挖掘之旅

0x01 起因

前两天和朋友聊天，他发现了一家在hackerone上赏金颇高的Program，并且发现了其中的漏洞

让老夫羡慕不已

去hackerone看了看厂商信息，漏洞奖励确实是非常诱人的

而且BugBounty Program Launched on Apr 2015….

8年hackerone的老厂商了，业务点本来就不多，又被世界各国牛逼的黑客们挖了八年，难度可想而知

但是为了赏金迎难而上，才应该是真正的漏洞猎人该有的风格。

0x03 走业务点万念俱灰到发现敏感请求

从Hackerone的Program scope中搜集了一下业务信息，虽然展开测试

测试了常规的一些WEB漏洞，IDOR等漏洞，发现完全没有一点机会，Filter和鉴权写的非常过硬，而且用户都是通过uuid类型来传参进行身份鉴权

首先目标没有IDOR，其次哪怕有IDOR也非常难以利用

从晚上九点测到了第二天凌晨两点，啥也没测出来，万念俱灰准备洗洗睡了

但是心想还是看看Burp的HttpHistory吧，万一有自己没注意的敏感请求呢

结果没想到。。。还真就看到了一个graphql的敏感查询请求

POST /agw/graphql?op=UrlReachableVerifierQuery&client_trace_id=09bee58d-8358-4f00-acc0-8d26d0018d32,rst:1678201703792 HTTP/1.1
Host: xxxxx
Cookie: xxxx
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0
Accept: */*
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.2
Accept-Encoding: gzip, deflate
Content-Type: application/json
Authorization: xxxxx
Content-Length: 386
Origin: https://xxxxx
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Te: trailers
Connection: close

{"operationName":"UrlReachableVerifierQuery","variables":{
"url":"http://xxxx.com/"},"query":"query UrlReachableVerifierQuery($url: String!) {\n  verifyUrlReachable(url: $url) {\n    ... on UrlReachableResult {\n      url\n       __typename\n    }\n    ... on GenericError {\n      errorCode\n      message\n      __typename\n    }\n    __typename\n  }\n}\n"}

url在json中传参，测啥漏洞，我想大家应该都懂

立马用Burp的Collaborator测试dnslog

果不其然，收到了来自两个IP的Http Request，但是目标的回显少的可怜

只有url，__typename两个键的JSON返回了回来

查了一下，两台发送请求的服务器都部署在GoogleCloud，瞬间就让人兴奋了起来

但是想了一下又萎了，GoogleCloud meta data(元数据)的获取不像国内的某某云，其必须带有特定的Header

这个SSRF点既没有回显也没法通过构造恶意页面的js发送带有header的数据，真是操蛋

request example:

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

思前想后，寻思也算个盲SSRF，先交了再说

0x04 秒忽略NoBugBounty到利用Graphql发掘新的攻击面

交完这个盲SSRF点，睡了一觉起来，发现直接被厂商的安全团队给忽略了

真是操蛋，盲SSRF看样不太行，混不到钱，我们必须得发掘新的攻击面

（不了解Graphql的兄弟可以看下下面这张图，生动地解释了Restful类型接口和Graphql接口的区别，上方为restful接口请求样式，下方为graphql的接口请求样式）

既然这个点是基于Graphql进行查询的

那么我们可以自定义查询的column(param)，如果存在该column，那么就会返回这个参数的有效结果，二话不说开始FUZZ

最终结果让人非常寒心，啥勾八东西也没有(这里当时的图忘存了)

再次陷入万念俱灰，但是仔细观察graphql查询请求的op参数，让我有了一点想法

op字段为UrlReachableVerifierQuery，我们为啥不试试拿他当query的column呢？

结果发现测试到UrlReachable这个字段时，reponse中出现了有效回显”Reachable”

nice，现在我们可以用这个接口来探测内网端口开放情况了

我直接使用GoogleCloud的meta data地址来探测端口连通性

没想到直接告诉我了个”Not_Reachable”。。

那么就得用点方法绕过了

0x05 绕过SSRF限制探测内网

试了试302跳转，短连接等方式，都不好使

于是寄出dns rebinding

在ceye上配置好dns rebinding的IP地址（googleCloud meta data的ip地址为169.254.169.254，借此来验证内网连通性）

直接dns rebinding来绕过SSRF限制

发现我们成功获得了“Reachable”的结果！

接下来就是常规操作了，探测端口连通性

80端口reachable，其他端口Not_Reachable，已经证明了此处SSRF可探测内网

0x06 再次提交漏洞到triage与bounty

再次提交后漏洞得到了Triage

triage的severity为medium

最终bounty按照low发的

仍在交涉中，估计是大写的寄

J0o1ey's blog