In this post, I’ll describe how I easily managed to exploit an SSRF vulnerability on target.com, a lot of information will be redacted for privacy reasons, but I hope you enjoy reading it.
Last year, while hunting with my bug hunting team (named Vendetta), I came across a feature that allows the user to specify a URL for an online file that the application (target.com) automatically fetches the file from and upload to the user’s account.
As I cannot include a screenshot of the application, image a simple button written “Upload with a link”, with a text box where the user can specify the URL that will be requested.
When I saw this functionality, the first thing that came to my mind was to test if the application was vulnerable to SSRF.
For those who are unfamiliar with SSRF, basically, Server-Side Request Forgery (SSRF) is a type of vulnerability that allows an attacker to force an application to issue requests on behalf of the attacker, to unintended resources. like interacting with the Company’s internal network.
So I created the endpoint below:
And configured it to redirect any HTTP request to the Internal AWS API endpoint that returns EC2 credentials. I recommend using https://beeceptor.com as a tool for inspecting requests, customizing endpoints, and customizing API responses.
Then, I inserted the https://lopseg.free.beeceptor.com/ url in the fetch function and the server hit it and followed the redirect to the internal API. After a few seconds, Target.com credentials were loaded into my account.
The security team quickly triaged and resolved this vulnerability.
Cheers to them.
- When you see some server-side fetch functionality, try SSRF.
- Use Beeceptor
Vendetta White hat team.