Bypassing Filters: SSRF Exploitation via DNS Rebinding with Just 1 in 30 Successful Requests
Hey everyone, hope you’re all doing well! I wanted to share a cool bug story I came across a few months ago. It’s about an SSRF vulnerability that lets attackers exfiltrate AWS metadata. The tricky part? It took me 30 requests just to confirm the bug! Only 1 out of every 30 attempts actually showed if the attack was successful or not. Since it’s based on DNS rebinding, it takes a while for the request to reach the backend and fetch the data.
I was working on a large program, let’s call it *.redacted.com. Like many of you, I started by running some tools to discover subdomains.
amass enum -passive -norecursive -noalts -df scope.txt | anew subs.txt
findomain -f scope.txt -q | anew subs.txt
cat scope.txt | subfinder -all -silent | anew subs.txt
cat scope.txt | assetfinder --subs-only | anew subs.txt
cat subs.txt | cero | anew cero.txt
cat cero.txt | while read line; do cat scope.txt| grep -E "\.$line$"; doneI found several subdomains and sent them for passive crawling in Burp. One of the domain got my eyes because of this
GET /test/?url= HTTP/2
Host: redactedI also tried Burp Collaborator and tested other domains to see if anything would work, but nothing did. All I kept getting were 501/503 errors. Whenever I see the potential for SSRF, I always run a bunch of test cases through Burp Intruder to check if anything works.
One of the requests responded differently — no 501/503 this time. Instead, I got a 200 OK with some JSON error. Initially, I ignored it, thinking it was just a fluke. But when I resubmitted the request, it went back to returning 501/503 errors.
After spending hours on this, I revisited that JSON error. Did you notice something odd? If you did, you’ve got hacker eyes. The response showed an ami-id in the JSON error. You know what that means, right? Our attack actually worked!
I tried resending the request again, but I kept getting 501/503 errors or access denied messages. So, I ran all the test cases through Burp Intruder again. This time, I got another 200 OK with a JSON error, but now the error was for something else…
/latest/meta-data/hostname
/latest/meta-data/ami-id
/latest/meta-data/local-ipv4
/latest/meta-data/public-ipv4
/latest/meta-data/security-groups
/latest/meta-data/instance-typeAfter many traily and ERROR I understood that only 1 in 30 request is actually working and giving me 200 OK with whatever I want to pull from the server.
What I was doing was sending a request that resolves to two different IPs — either 127.0.0.1 or 169.254.169.254 — through 7f000001.a9fea9fe.rbndr.us. For 29 requests, the server blocked my access because the IP resolved to 127.0.0.1. But then, out of nowhere, the request resolved to 169.254.169.254, allowing it to pass through the backend and giving me access to the information I was targeting.
Triager responded:
As you can see from the triager’s comment above, I was also able to find more hosts vulnerable to SSRF on the same endpoint. I did this by using FFUF to brute-force the endpoint across all the subdomains I had collected.
The customer rewarded an awesome bounty for this finding! :)
That’s all from my side. Thank you for reading! Don’t forget to follow me on twitter: https://twitter.com/tabaahi_
Have a beautiful day ahead :)
