A unique SSRF hunt ( Invite user functionality vulnerable to blind SSRF attack )

Server-Side Request Forgery (SSRF) refers to an attack, wherein an attacker can send a crafted request from a vulnerable web application. SSRF is mainly used to target internal systems behind WAF (web application firewall), that are unreachable to an attacker from the external network. Additionally, it’s also possible for an attacker to mark SSRF, for accessing services from the same server that is listening on the loopback interface address called (127.0.0.1).

What is Blind SSRf ?

Blind SSRF arises when an attacker can initiate SSRF but does not directly obtain the response. Instead, they depend on alternative methods, such as out-of-band (OOB) requests, to verify the success of the attack. This adds complexity to both detection and mitigation efforts.

My hunt:

I was all in on hunting on the Target website but wasn’t having any luck. I noticed there was a referral functionality on the website where we can create our custom unique referral link and send it to users to invite them to join the website. They will get some percentage of their deposit as a commission. Seeing that, I was like “SSRF” “SSRF” “SSRF”. I passed my Burp Collaborator link to create a referral but didn’t get any HTTP requests in my collaborator. I thought, hmm, let’s try creating an account using this referral link and as soon as I created the account, boom, there was an HTTP request in my collaborator from the website server.

I was like I knew it man I know it, but now I was thinking how can I exploit it as it was blind SSRF, I taught if trying to perform internal port scanning this time I create my referral link with burp collaborator link and add a port number in last ex: 123burp.com:443, created an account using that link boom I got both DNS and HTTP response then I tried using a port that must be closed to see if I get any different response from the server in my collaborator so I passed port 21 this time has it is mostly closed due to security perspective and DAMN I only got DNS response this time no HTTP.

With this discrepancy in response, I was successfully able to determine which port is open and which is closed in the internal server as the port giving HTTP response is open and the one only with DNS is closed hence I was successfully able to perform an internal port scan.

I promptly reported this vulnerability to their bug bounty program, and they are currently analyzing the report. I’ll update the article with their final response and also the video POC if they allow it once they address the vulnerability.

Learn more about SSRF:
https://www.youtube.com/watch?v=voTHFdL9S2k