Account TakeOver | Abusing the Application logic flaw in the reset password functionality

While hunting on a well tested program on bugcrowd, or so it seemed. I came accross an interesting find.

I came across the URL/endpoint shown in the attached screenshot.

You spot that number (12716) before the password reset token begins?

My initial thought was that this seemed like a user ID. So, I tried some obvious things, such as SQL Injection, switching it to another user ID, etc., but nothing worked.

From my past experience with logic flaws, I know they can be elusive sometimes. So, I registered a new account in the application and initiated the password reset process.

Then, I switched the user ID in the original URL to match the user ID of the new account (but without changing the token), and… Voila! It allowed me to reset this new user’s password.

What does this mean? Having a valid password reset token allowed me to reset the password for any user who had already initiated a password reset process.

At that point, I used Burp Suite Intruder to test different user IDs until I had identified a significant number of users for whom I could execute an account takeover.

The number of valid user IDs I found also suggested that the password reset token was not expiring or being deleted after a certain period, which the company later confirmed.

An attacker could initiate a password request on behalf of the victim and change their password successfully.