How I Discovered SSRF on Hackerone Program
Hi guys, I am Kerstan. Today, I will share you how I discoverd SSRF on hackerone Program. The process of discovering bugs can be lengthy, but the results are often rewarding. Keep trying harder, bro! If this writing has been helpful to you, please consider giving it a clap and following. Thanks bro. So, let’s get started.

---
1. Sensitive endpoint discovered
First, I gathered some business information from the Program scope on Hackerone.
I conducted regular tests such as web bug and IDOR, but I found absolutely no opportunity. The filters and authentication mechanisms were very robust, and users were authenticated using uuid as parameters.
I couldn’t exploit the uuid to cause an IDOR bug.

It’s already the next morning and I haven’t found any bug yet. I decided to take a break and grab a cup of coffee.
I decided to go through Burp’s HttpHistory again to see if there were any sensitive requests that I might have missed.
Wow, finally, I came across a sensitive Graphql request.
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
__typename\n }\n ... on GenericError {\n
__typename\n }\n __typename\n
2. Find a Blind SSRF
I noticed that the URL was being passed as a parameter in json, so I decided to try ssrf. I immediately used Burp’s Collaborator to test for dns log.


As expected, I received HTTP requests from two different IP addresses. This is a Blind SSRF.
However, only two keys from the json response were being echoed back: “url” and “__typename”.
I checked and found that the IP belonged to Google Cloud. Google Cloud metadata requests require specific headers to be included, as shown below:
request example:
curl "http://metadata.google.internal/computeMetadata/v1/instance/image" -H "Metadata-Flavor: Google"
Clearly, direct exploitation is not possible here.
3. Exploring new attack surfaces using GraphQL
So, let’s go back to the previous point. This endpoint is based on Graphql for querying. We can customize the query’s column (param). If such a column exists, it will return valid results for that parameter. Therefore, let’s start fuzzing.

But still, there are no exploitable parameters.
I was tempted to give up, but upon taking another look at the request URL, I carefully observed the “op” parameter in the Graphql query request, which gave me a slight idea.

The “op” field is set to “UrlReachableVerifierQuery”.
Why not try using it as a column in the query?
As a result, when testing with the “UrlReachable” field, I found a valid echo of “Reachable” in the response.

Wow, now we can use this API to probe the availability of internal network ports.
I directly used the Google Cloud metadata address to check the port connectivity, but unexpectedly, it simply responded with “Not_Reachable”…

4. Bypassing SSRF restrictions to probe the internal network
I tried methods like 302 redirection and short links, but none of them worked. So, I resorted to using DNS rebinding. I configured the DNS rebinding IP address on Ceye (using the IP address from Google Cloud metadata, which is 1xx.xxx.xxx.xxx) to verify the internal network connectivity.


So, we can directly use DNS rebinding to bypass SSRF restrictions. We have successfully obtained the “Reachable” result! Now, the next step is to probe the port connectivity.


Port 80 is reachable, but other ports are not reachable. This proves that SSRF can be used to probe the internal network in this case.
After submitting, the vulnerability has been triaged and is currently awaiting review.

---
If this writing has been helpful to you, please consider giving it a clap and following. Thanks bro.
Alternatively, you can just buy me a coffee here, any sort of support is much appreciated. Enjoy your reading.
If you want to learn more knowledge about Bug Bounty Tuesday, please be sure to take a look at my previous articles.



Comments