0-Click ATO: How I Can Take Over Every Account on the Website

“اللهم صلِّ وسلِّم على سيدنا محمد عليه أفضل الصلاة والسلام”

Hello, Hackers!
I hope you’re all doing well. This is my first write-up and also my first Valid Bug, and I wanted to share it with you. If there are any mistakes, please let me know in the comments.

Whoami?
My name is Ahmed Esmail, or you can call me “Som3a”. I’m 20 years old, and I started bug hunting three weeks ago.

Summary
The vulnerability I’m sharing with you is in a VDP program in hackerone. Since the issue hasn’t been fixed yet, let’s call it target.com. It’s an Account Takeover vulnerability caused by a misconfiguration in the Reset Password function. This flaw allowed me to change the password of any account on the website, including admin accounts, which could give me full access to the entire site.

Let’s start the story in detail.

The first thing I always do when testing a website is create an account and explore the main domain to understand its features and functions without using Burp Suite or any tools. This usually takes me around 1–2 hours to organize my thoughts and plan my approach.

Once I finished that, I decided to start testing the Login and Register functions with various scenarios, which I might share in a future write-up. Unfortunately, they were secure, and I couldn’t find any issues.

Then, my attention shifted to the Reset Password function. I started testing different scenarios, such as:

Host Header InjectionChecking if the Reset Password Token is leaked in the responseSending two emails in one request to see if both receive the same tokenReusing the token multiple times or testing if it doesn’t expireChecking for the absence of Rate Limiting on Reset Password requests, which could enable email bombingAnd many other ideas.

Unfortunately, none of these tests worked — the function was secure. At this point, I started losing hope, thinking the website was secure and that I wouldn’t find anything. But give up? No way!

I decided to keep testing the same function, paying closer attention to how the requests flow — from when I click the Reset Password button to when the password gets changed.

And then I noticed something strange… After resetting my password using my email, receiving the link, entering a new password, and clicking Change Password, I found that my email was being sent in the request.

Strange, right?

Of course, the first thought that came to mind was, what would happen if I changed the email to someone else’s email? So, I quickly created another account and tried to reset its password by replacing my email with the second account’s email in the request. Unfortunately, I got a 200 OK response, but it said Reset Password Failed.

Looks secure, doesn’t it?

But giving up isn’t an option!

I then noticed a parameter called frm_check, which seemed like a token tied to my original email. If I changed the email, the server would check this token to ensure it hadn’t been altered. So, I started thinking about how to bypass the frm_check.

And what do you think happened when I simply removed the frm_check parameter from the request?

It worked !!

The request bypassed the check, returned a 302 redirect, and sent me to the login page. When I tried logging in with the second account’s email and the new password, it successfully logged me in.

With this, I realized I could take over any account on the website without any user interaction.

I reported the vulnerability, and within just one day, it was triaged and marked as Critical.

I also found 3 privilege escalation vulnerabilities on Bugcrowd, and I will explain them in an upcoming write-up.

In the end, I hope you found my write-up helpful. If you have any feedback or suggestions, please let me know in comments.