How can you leverage an SSRF (“Server Side Request Forgery”) vulnerability to evade filters and leak internal AWS credentials on a web application? Today I will discuss how I managed to utilize a webpage screenshot feature to bypass certain filters and exfiltrate server side AWS Metadata.
While looking through a certain BBP (“Bug Bounty Program”) I came across an interesting feature in the application. This feature allowed for a user to supply any URL and have the specified webpage captured as an image which would then be provided back to the user.
This feature appeared very interesting because if there were any errors in its configuration or input validation, its functionality could provide an attacker a wide variety of different attack methods. This includes possibly accessing endpoints on the website that I do not otherwise have access to, having the server request any domain of my choosing, and being able to request local resources on the server to screenshot and view myself.
Below I will walk through the methods I applied to attempt to discover flaws in this functionality. Many of these attempts failed but after continuously testing this functionality, it led me to one method that successfully returned any AWS metadata from the back-end server that I requested.
The very first few attempts I made to try and manipulate this into returning sensitive information were relatively simple. This included adding endpoints from the current domain that would contain sensitive information. I thought by doing so, I could view these pages with heightened privileges since the request originated from the back-end server, which may be linked to a high privilege account. These tests included endpoints such as:
After multiple attempts, it showed that the server was not authenticated to the application, and it would just return the login page for the site. Therefore I knew exploiting this would not end up being as simple as that and I would have to attempt other techniques if I wanted to find a bug within it.