No Rate Limiting on Forget Password Page Leads to OTP Bypass and Account Takeover.
I mean, seriously, who needs rate limiting anyway? It’s not like anyone would ever try to brute force their way into someone else’s account, right?
Sure, it might seem like a minor oversight, but let’s be real here: if you’re not going to take basic security measures, you might as well just hand over your users’ sensitive information on a silver platter.
What is the impact of such a vulnerability?
If a hacker can get their hands on a user’s email address or phone number, they can easily request a password reset and then use an OTP bypass to gain access to the account. It’s like taking candy from a baby! An attacker would be basically owning all accounts.
A little bit about Rate Limit:
A rate limiting algorithm is used to check if the user session (or IP-address) has to be limited based on the information in the session cache. In case a client made too many requests within a given time-frame, HTTP-Servers can respond with status code “429: Too Many Requests.”
A little bit about Burp:
“Burp” is a proxy-based tool used to evaluate the security of web-based applications and do hands-on testing.
How does it work?
Let us assume that the website is www.justexample.com . First of all, the website on which I found the vulnerability needs users’ phone number to sign up on their platform.
- I entered my registered mobile number on the vulnerable site and clicked on forget password on the login page.
2. I entered my mobile number and then clicked on set password.
3. Now, the One Time Password has been sent to my registered mobile number.
4. I entered any random 6 digits number into the One Time Password Section and also the new password which I needed to set for the account.
5. Then I started Capturing the request in the Burp and sent that captured request from the Burp to Intruder.
6. I created a Payload of 6 digits numbers and started the attack in the intruder. We run an iteration of numbers since rate limit is not there.
7. I got a ‘200 OK’ response for all the requests until one valid One Time Password hit the request, we see the Status Code as ‘302 FOUND’ response and valid request length is also different than other requests length.
8. The valid One Time Password which I got from the attack results is the same OTP which I’ve received on my mobile number.
9. I Entered the correct One Time Password I have got from the results and clicked on SET PASSWORD. (Note- It’s showing invalid OTP because first we entered any random number in the OTP section to intercept the request and to get the correct One Time Password; So, I just deleted the wrong OTP entered and entered the corrected OTP received from the attack results.)
10. Now I just logged in with the phone number and the new Password which I have set of the account and get access to the account without any legitimate user interaction.
11. As you can see, I am able to change the password of the account and get logged in to the account and able to access users’ profile.
I didn’t get any bounty though, but it was a great learning experience for me as a beginner Bug Bounty Hunter and I was able to exploit same vulnerability on many more Web App's.
This was my first write-up, thanks for reading. If you have any questions feel free to let me know.
