A story about my first SSRF finding on a bug bounty target web app, where I further exploited the SSRF bug into reading internal server files, which leads to AWS instance secret leakage. There were no filtering or firewalls on my target. So let's jump straight into the bug exploitation.

The target was a productivity app. There was a feature to create and manage projects in it. After spending almost 8+ hours exploring app.target.com features, I came to notice a button that prints the projects created on my account.

When I clicked the button, a PDF was generated with my project in it. Okay, enough for opening up Burpsuite, it seems interesting to dive deep into it. And I intercepted the HTTP request that is going to the server when I click on the Print button. And it was very interesting.

There was an html parameter, which contains a whole bunch of HTML codes, which the PDF generates from it.

I tried sending the request by entering some random HTML codes as the html parameter value, and it generated the PDFs successfully.

Alright, now let's try sending some iframe tags as the html parameter's value. I tried embedding my personal website using the <iframe> tag.

<iframe src=https://www.usamav.dev width=100% height=100%>

The generated pdf contained my personal website embedded in it. Cool...

The next step is to access the internal files using <iframe> tags. First, let's start with /etc/passwd.

<iframe src=file:///etc/passwd width=100% height=100%>

This generated a pdf with the following content.

The target was running on an AWS EC2 server. So it's time to access AWS EC2 server meta-data. As per AWS documentation,

"To view all categories of instance metadata from within a running instance, use the following URI. http://169.254.169.254/latest/meta-data/. The IP address 169.254.169.254 is a link-local address and is valid only from the instance."

We can try embedding the above URI in the PDF using the <iframe> tag to access the meta-data.

<iframe src="http://169.254.169.254/latest/meta-data"+width="100%"+height="100%"></iframe>

This was also successful. I immediately got the pdf with the meta-data in it.

I was able to access some confidential data such as secret_key, private access key, internal server files, mac address, user details, instance details, etc.

The whole process took a little while than I expected. Because whenever I sent a request with the HTML codes to the server, I get a unique code for that PDF, to access the generated PDF, I needed to copy that unique code and paste it on another endpoint on that API. So to automate this boring task, I made a quick python script to automate the PDF generation.

And finally, I spend almost 1 day alone writing a bug report and sent it to the responsible security team. Within a few hours, they responded to my report. I also sent the python script along with the report. I was so excited as this is my first ever SSRF finding on a real-world target.

Although, the bug was not a critical finding as I expected.

And finally, I received the bounty amount of $400 on 22nd April 2021.

---

As you have read till here, you would've noticed that this bug is such an easy-to-exploit bug. No firewall, no fancy bypassing techniques, not so complicated, just a straightforward bug.

However, writeups of easy findings motivate me oftentimes. Every time I read similar writeups of some kind of easy bugs, I feel like I have enough skill to start hunting a target application. Usually, those writeups help me to escape from the tutorial hell and push me to start doing the work.

I hope this write-up will also motivate someone to hunt your target for bugs. You can always reach out to me on Twitter at @usama_dev

Good luck... and Thanks for reading till here...