OTP brute
OTP brute-force via rate limit bypass
When you intercept the request after clicking on the forget password button, what you get on a proxy, like Burp Suite is something like:
At this part when one has to input the OTP, inbox’d to them.
Hello everyone, sharing with you my first bug bounty write-up on how I was able to brute force an OTP (One Time Password) mechanism where rate limitation was in place, on a private bug bounty program.
As per my assumption, I am expecting, you already know about rate limiting. If not, allow me to clarify its concept for you. In simple bug-bounty terminology, a rate-limiting technique is implemented in order to restrict the number of requests being sent, that seem to be abnormal in nature.
I didn’t straight up bypass the rate limit feature at first. Instead, I noticed that the prevention was setup at a forget password endpoint. An OTP is sent at the supplied email address on the forget password page, that you will enter and then create your new password.
Sending it to intruder, and repeating the request, by almost 20 times, got me responses like:
I figured out a simple trick to toggle around with this rate limit technique, by adding an X-Forwarded-For header in the request.
You can find more details at: https://book.hacktricks.xyz/pentesting-web/rate-limit-bypass
Looped the request 50 times, from 127.0.0.1 till 127.0.0.50 (value of the X-Forwarded-For header).
The attached screenshot below, shows 10 repeated requests, with the indication, emailSent: True. And that’s, what happened: My inbox was flooded with my desired number of OTPs.
The rate limit on the forget password feature had been bypassed here.
I reported this vulnerability separately, but there’s another part to this entire scenario. Here, starts the part when the rate limit on the OTP is bypassed, hence launching a brute-force attack.
I supplied an incorrect OTP, and proxy’d that specific action:
I repeated the same action by providing 5 incorrect OTPs, and the server responded with:
Rate limit occurrence.
Here, I tried to connect the dots. I thought that I had managed to bypass the rate limit feature on the forget password feature. Why not try the same technique here? After all, brute forcing an OTP can open doors to a possible account takeover in an instance I like this.
In the highlighted portions of the above request, looped the host ID of the X-Forwarded-For parameter till 0 till 255, and supplied an arbitrary amount of 6 digit numbers in the tokenVerify parameter that takes place for the OTP.
When rate-limiting on OTP is placed:
Response length 545 denotes rate limit present.
Note the response length after the first 5 requests. After the rate limit on OTP had been bypassed (Payload1 containing X-Forwarded-For, Payload2 for tokenVerify parameter):
Response length 520 denoting normal workflow.
The payload set, indicating the successful OTP brute-force attempt, with the absence of a rate limit:
Hope you enjoyed reading till here, Cheers!
Regards,
Punker-Bhai | Medium