Uncovering SSRF Vulnerabilities Made Simple: Leveraging the Wayback Machine’s Saved Pages
- Hello there, my name is Khaled Mohamed — xElkomy
- Bug hunter at Hackerone, Detectify CrowdSource, Synack Red Team Member.
What is the SSRF or Server-Side Request Forgery?
In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases, or perform post requests towards internal services which are not intended to be exposed.
The above string about SSRF, it’s from OWASP, I’m not a fan of remaking the wheel from scratch for that I just copy the description from OWASP To here :).
Way back machine
The Wayback Machine is a digital archive of the World Wide Web. It was founded by the Internet Archive, a nonprofit library based in San Francisco, California. Created in 1996 and launched to the public in 2001, it allows the user to go “back in time” and see how websites looked in the past. Its founders, Brewster Kahle and Bruce Gilliat, developed the Wayback Machine to provide “universal access to all knowledge” by preserving archived copies of defunct web pages.
My Scenario
Let’s start, the scenario was about to make some of the recons on the XYZ program to find some bugs, the thing is, when I begin my recon I do the following.
1 — Enumeration of the subdomains with subfinder.
2 — check the alive subdomains and gather the CNAME to check if there is any subdomain takeover available.` Dig command and Httpx`
3 — Test the subdomains with scanners like nuclei to scan some of the CVEs and some of the misconfigurations.
4 — Gather all the Way back machines about my XYZ program.
5 — Start the manual scan with the previous step.
We will start here with the last step from the above words.
It was when I checked the way back machine with that URL.
https://web.archive.org/cdx/search/cdx?url=*.xyz.com/*&output=text&fl=original&collapse=urlkey
And after scrolling on the page, I found a subdomain with an interesting name, after some manual search about bugs on that site, I found an action to make a request with a URL parameter.
https://redected.redected.com/REDECTED.XD?url=https://redected.redected.com/xd&XD=true&XD=ETC&XD=ETC
When I started to test that URL, it was with Interact.sh
My first check was to know are the server works on Microsoft Azure or AWS or Google Cloud, to try some internal IPs.
The first test was to make the URL to be like that
https://redected.redected.com/REDECTED.XD?url=http://xx.interactsh.com/&XD=ETC&XD=ETC&XD=ETC
PDF RESPONSE EXAMPLE
The Site response to me was to make my interact URL response to PDF.
I go back to https://app.interactsh.com/#/
- And I take the IP from the interact.sh dashboard and check the IP on that site
And Boom the IP from AWS after that directly, I go to GitHub and open the PayloadsAllTheThings and get that folder.
I take that payload and check if the site allows me to print the internal content or resources or not.
The Payload:-
http://169.254.169.254/latest/meta-data/hostname
The escalation found Secret token:-
After some prints on the PDF with http://169.254.169.254/latest/meta-data, I found the secret token and access token with that URL.
After That, I go to the Program page on the Hackerone platform and create a report.
In the Final, The Report was accepted as critical.
Hackerone Triage team response.
I hope you enjoyed that article. If it was helpful to you, make sure you follow me on
If you have any questions, feel free to contact me on
Re-publish Old Write-up from 2021
Don’t Miss Our Company @cyberar:
Exposing AWS Credentials Through SSRF in Cloud Automation Features (cyberar.io)
