Tale of 3 vulnerabilities to account takeover!
Hi Guys,
So, after a gap of around 8 months, I recently did some bug hunting with the hope that I could learn something, and eventually, it also fetches me a decent reward. This blog will be around not only what vulnerabilities I was able to find but I would also be drilling into specific tools that helped me here. As the title suggests, this is about a tale of not one or two but three vulnerabilities chained together which leads to account takeover. Let’s get into details —
As everything starts with a bit of recon, I ran a couple of tools to gather information about the target(redacted.com). Specifically for subdomain enumeration, I keep the following tools handy — aquatone, Sublist3r, subfinder and, altdns. On the top of it, I had a script that adds the found subdomain in the burp suite scope and enables spidering and passive scanning. It is always good to rely on multiple tools because there are always some edge cases that tools always miss out. Parallelly, I was trying to understand the application in general what all functionalities, pages, flow it has. It was an e-commerce website and to examine the authenticated pages, one needed to log in with OTP. And when there is OTP based login, the first thing which strikes everyone’s mind? Yes, you are right! I went ahead to try brute force.
But as I expected, after few attempts of burp intruder, it reached the rate-limiting rule and further requests start dropping. As can be seen in the screenshot, 429 HTTP status code was sent from the server.
If you check the response carefully, you will see CF-RAY header which is set by Cloudflare. Most likely there is a rate limiting rule at Cloudflare which blocked the brute forcing so if I can bypass Cloudflare i.e. if I can reach directly to the origin server then I can bypass rate limiting as well.
I tried different approaches to know its origin server — digging into the certificate, checked on Censys, ran some open source tools like crimeflare, Cloudflair but none of them actually gave me the server IP. The target was simple I have to get the origin server IP, a SSRF vulnerability here could do it.
By the time the recon got over, I started checking subdomains if that can help me in any way. Checking the list, I found a WordPress subdomain and it was their blog page — blog.redacted.com. It reminded me of an always infamous vulnerability — exploiting xmlrpc.php. I quickly checked it and as highly anticipated it was enabled.
To find if the pingback.ping method is enabled, I used system.listMethods.
Response-
Now the final part left, making an SSRF request. For which I used burp collaborator to receive the server response. One can also use request bin. This is how the post body request looked like—
<?xml version=”1.0″ encoding=”UTF-8″?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>[Burp collaborator link]</string></value>
</param>
<param>
<value><string>[Any valid blog post linl]</string></value>
</param>
</params>
</methodCall>Fired the request —
and received the delighted response in burp collaborator client ;)
Now I just needed to replace the host with the IP and run the intruder to brute force the OTP, hoping server side rate limiting is not there which proves to be true;) Put the vicitm’s mobile number, made the OTP login request, replaced the host with IP, and ran the intruder —
Cracked it! The complete tale was to get this “200 OK”!
The whole writeup in 1 liner — I bypassed the rate limiting on OTP brute force by bypassing cloudflare by reaching to it orgin sever IP which I found via SSRF by xmlrpc.php attack.
So,
- I found SSRF on the blog page by exploiting xmlrpc.php to get the origin server’s IP,
- Used the server’s IP to bypass Cloudflare by directly reaching to the origin server and
- Brute forced the OTP to tookover victim’s account (as “rate limiting” wasn’t set at the server side)
are actually the tale of 3 vulnerabilities that I exploited here. Since now Cloudflare firewall is completely bypassed, I could do tons of stuff. That’s it about this interesting finding!:)
Report details-
11-Nov-2020— Bug reported to the concerned company.
12-Nov-2020 — Bug was marked fixed.
13-Nov-2020— Re-tested and confirmed the fix.
17-Nov-2020 — Rewarded.
Thanks for reading!
