From Wayback Machine to AWS Metadata: Uncovering SSRF in a Production System Within 5 Minutes

Oh my waybackmachine! It’s really great tool to get hidden urls. You can use some tools to get urls like gau and waybackurls, but in this story I easily used this url;

When I choose a website (e.g., redacted.com in the URL parameter), I look for API endpoints and valuable parameters from my wayback url, such as getImage, url, path, etc. During one of my searches, I found an API that generates a PDF from a provided parameter. This parameter passed as GET parameter. Seems like;

At first, I tried reading some local files, but I didn’t find anything significant. Like;

Then I tried passing a URL to this parameter.

But that also failed, and I received an internal error with this request. Then, I tried some characters to see if I could bypass this validation. Then;

It worked! I saw Google in the PDF. That was a PDF generator; it converts pages into a PDF. Then I tried it with the collaborator URL, and I discovered that it was on AWS ec2. I saw a couple of IPs.

Then of course I tried to get meta data but I saw blank pdf page. It was good because when I passed a domain that the server couldn’t reach, it returned an internal server error. Then I tried to get the metadata again, and after some requests, I saw that some of the servers responded with a 200 status and returned AWS metadata.

Actually, this was sufficient to report the vulnerability, but I was curious about the internal network as well. I didn’t take any action with ec2 because it was a production environment. I found some internal domains, but they weren’t useful.

Then I tried to get some ports from localhost and I got 3000 port thats nodejs. After several attempts, I realized that scanning localhost caused a denial of service. Once I understood this, I stopped all scans. I really didn’t expect this situation, so I quickly reported the vulnerability. In 5 minutes, I found the URL, and I spent more than 6 hours preparing the PoC…

Thanks for reading…