A Tale of Account Takeover
Reset Or Forgot Password is one of the most important functionalities when it comes to the security of an application. If an attacker can bypass the password reset/change functionality by any means. In that scenario, it is possible to perform privileged actions, enumerate sensitive information and further possible to completely takeover the accounts which can cause chaos resulting in technical, business, and reputational impact.
It is often observed that most modern applications allow users to reset/change their account passwords in two different ways, either after login(password change) or before login(forgot password). Both implementations are different. In the first case, you already have authenticated user, but in the second case, you do not have a clue who will access the functionality, so you must apply some checks to confirm the user’s identity.
In Forgot password functionality anyone can access that page and request for password change, so few checks must be implemented but due to logical reasons, many developers still lag in writing perfect code. Due to this an attacker bypasses the logic and exploits the functionality. In this blog, we will discuss a related scenario where I have exploited a logic flow because of missing proper checks, leading to accounts takeover of the complete database accounts. i.e., Multi-Step Function Bypass Leads To Account Takeover.
As the name suggests, We have bypassed the Multi-Step Function in the forgot Password Functionality to Compromise the account. Here we have Chained two Vulnerabilities to Create an impact to the next level. Let’s break down this attack into small pieces and understand how one can perform successful exploitation.
Here I have combined no rate limiting and broken access control vulnerabilities to perform this attack. During the initial engagement, we found out that the application has not implemented any protection against the rate limit, and this was throughout the application. I have found 3–4 scenarios where I was able to perform the no-rate limiting attack, one of them was the forget password.
It was the first step of the forgot password functionality, where no rate limit occurred. In this, we entered our username, and then the system checked for it, if it is valid it moved to another step. For the exploitation of this step, I just captured the request in the burp suite fired a list of common usernames from the SECLIST, and filter the output based on the response received.
using this I have found about 10 valid usernames from the wordlist of about 500 usernames.
now let’s understand the flow of our forgot password functionality, During the testing of the, forgot password functionality I figured out that the application is first checking the username, then the secret questions, and finally enters the new password. after two-three attempts, I figure out that the application is checking the username and assigning a cookie in the first step, in the second step, it was just checking for the valid secret question-answer using the cookies assigned in the first step, on entering the correct information it redirected to the third step without assigning the cookie, here the third step was using the same cookie assigned in the first step.
it does not take much time to figure out that I can bypass the second step, which was the main step in the validation. after comparing the requests from the second and third steps, I got to know that only the URI and referer headers are changing, which means the only verification, they have implemented is the referer header, I confirmed my claim by checking it.
After the claimed success, I merge all three steps and checked if it is working properly, and yes, it worked. I reported the vulnerability to Bugcrowd and after 2 days it got triaged as a valid submission in p1, this was a point program so I was rewarded with 40 points and hall of fame by Bugcrowd. this was one of my favorite findings where I used rate limiting to take over the accounts presented in the database of the application.
Conclusion:
Do not be in a hurry to report small vulnerabilities, always check whether you can merge them with any other vulnerabilities, Using which you can easily escalate the severity of your vulnerabilities from even low to critical.
