AWS internal metadata accessed through SSRF by Chaining an Open Redirect bug
My name is Santosh Kumar Sha, I’m a security researcher from India(Assam). In this article, I will be describing how I was able to get AWS metadata accessed through SSRF by chaining it with a open direct vulnerability.
I am now offering 1:1 sessions to share my knowledge and expertise:
TOOLS used for the exploitation
1. Subfinder (https://github.com/projectdiscovery/subfinder)
2. httpx (https://github.com/projectdiscovery/httpx)
3. gau(Corben) — https://github.com/lc/gau
4. waybackurls(tomnomnom) — https://github.com/tomnomnom/waybackurls
Story Behind the bug:
This is the write of my Recent bug that i found . While I was doing recon for gathering all urls from internet archives using waybackurls and gau. So started fuzzing the for ssrf vulnerability and found one but there was some filter going on behind the server which not allow me access the internal metadata but i chained it with open redirect bug to bypass the waf to access the internal AWS metadata.
Here it goes:
Suppose we assume the target name is example.com where every thing is in-scope like this:
In-scope : *.example.com
To gather all the urls from internet archives i have used waybackurls tool and gau.
gau -subs example.com
So the chance of missing the urls still exist so in-order to be ahead of the game I don’t want to miss any urls for testing so I used subfinder and pipe to waybackurls to get all the urls for all the subdomain if exist and save it to a file.
So the final command will look like this:
gau -subs example.com >> vul1.txt
waybackurls example.com >> vul2.txt
subfinder -d example.com -silent | waybackurls >> vul3.txt
Now, we have collected all the urls ,so its times to resolve all the urls to filter out the dead urls from the list and filter out all the urls containing parameter for testing for vulnerability. So the command look like this below
cat vul1.txt vuln2.txt vul3.txt | grep “=” | sort -u | grep “?” | httpx -silent >> FUZZvul.txt
After Collecting all the urls containing parameter I starting fuzzing all the urls for finding SSRF but no success as the program is an well know bug-bounty program so I thought that all the other bugbounty hunter have already been tested and harden enough and If i find also the chances of duplicate is more because all others must have done these testing. Now, I was feeling burnout then i went out for some refreshment but still i was thinking about it.Suddenly something hit my mind, why not test for some hidden parameters. So i decided to use my magic trick which I call parameter sparing with some bash tricks to add my burp collaborator payload and proxy all urls to burp proxy to check the urls one by all as there was 200 urls .Here Is the command used for my magic parameter sparing
xargs -a /root/magicparameter/ssrf.txt -I@ bash -c ‘for url in $(cat FUZZvul.txt); do echo “$url&@=http://burpcollabrator.net”;done’ | httpx -http-proxy http://127.0.0.1:8080
Now I finally got an hit on my burp collaborator server with http and dns request with urls as
So that to fuzzing further to get AWS internal metadata for the vulnerable domain like these:
I tried the above url it gives me 200 OK, but no success as there was some filtering going on behind or waf/firewall was not allowing to get the response for internal data access. I used all bypass i know and also google it about to bypass. But still i was not able to bypass it to access the internal metadata.
NOW the actual Chaining start:
So after all this I was stuck because If I report it then it will be an blind SSRF with low impact and one might I already found it so it might duplicate. So I decided to not to report and take these as an challenge to bypass it. As, I knew that i was able to access the internal metadata because i was getting 200 OK response but I was not able to see the response.
But after sometime I remember that there was an open-redirect vulnerability that i have already found on it but it out of scope. So I decided why not chain the open redirect bug with my SSRF bug. The open redirct url was like below.
So after chaining with my ssrf vulnerable url it look like this
I quickly reported the bug and in the next day the report was triage to critical
After seeing this my reaction …
I’m sure that a lot of security researcher had already see there process but this how I approach to bypass the firewall to get AWS metadata accessed through SSRF by chaining it with a open direct vulnerability .So never stop when across any filtration or firewall or WAF because there are way to way them and always try to chain the low severity bug to increase the impact for higher bounties.
That’s one of the reasons why I wanted to share my experience. also to highlight other techniques to exploit such vulnerability.
Thanks for reading :)
Santosh Kumar Sha — Security Researcher — Bugcrowd | LinkedIn
View Santosh Kumar Sha’s profile on LinkedIn, the world’s largest professional community. Santosh Kumar has 2 jobs…