My First Case of SSRF Using Dirsearch

Hello, I am a 16-year-old bug bounty hunter. I would like to appreciate God Almighty for helping me to find this bug.

This is my first Medium Blog Post and in this blog post, I will share my experience of finding my first SSRF vulnerability using Dirsearch and explain the steps I took to discover it.

Server-Side Request Forgery (SSRF) is a type of web application vulnerability that allows an attacker to send HTTP/HTTPS requests from the server to a third-party domain, potentially leading to sensitive data disclosure or even remote code execution.

I started by getting all the subdomains of my target using Subfinder by Project Discovery.

It happened while I was going through the Usage of Dirsearch on Github, I found an option that I have never used before on Dirsearch, which was the deep recursive option.

I then decided to use the option (thanks to the HolySpirit), and this was the final command:

Although it took time because I had to fuzz over 300 subdomains, I found a directory that was like:

but because I used the deep-recursive option, Dirsearch did another fuzzing on the proxy.stream parameter. It then found another parameter which then made the full URL like:

I visited the URL and it rendered google.com to me, so I tried rendering other URLs to be sure there was no whitelisting involved and they rendered. So I tried using an Out Of Band Interaction Tester (OOB) like BurpSuite Collaborator but I didn’t have one so I used an alternative, and it worked. I received a pingback.

I now searched the parameter on Google and found a tweet where someone tried to use the AWS Metadata URL, so I tried using it, and behold it worked. I was able to view the AWS Metadata credentials and I immediately reported it.

Thanks for reading the blog post, if you have any questions, DM me on Twitter.

Goodbye.