0-Click Account Takeover via Insecure Password Reset Feature
If you enjoy what I do, please support me Buy Me Ko-fi! https://ko-fi.com/h0tak88r
Last updated
If you enjoy what I do, please support me Buy Me Ko-fi! https://ko-fi.com/h0tak88r
Last updated
In the name of Allah, the Most Beneficent, the Most Merciful
Hello Hackers! Today, I am excited to share my recent discovery of a 0-Click Account Takeover vulnerability on a public program on the HackerOne platform, During Collaboration with my friend @
0x3adly
.
The vulnerability We found resides in the password reset mechanism. This flaw allows an attacker to manipulate the password reset URL parameters, specifically the p_hash
and p_sign
parameters, to access the password reset page without any further authentication. Here’s a step-by-step explanation of how this vulnerability can be exploited
Subdomain Monitoring: I started by monitoring subdomains using my tool subfalcon with the following command:
During this process, I found an employee portal at https://brandcentral.target.com/
.
Exploring JavaScript Files: I examined the JavaScript files for unauthenticated paths using this script:
Unfortunately, I didn’t find anything significant with this method.
Discovering the Vulnerable Feature: I then found an interesting feature called "request user," which allows the creation of a new user and sends an email with the credentials provided.
Initially, I thought of testing HTML injection in the email and found it was vulnerable. The portal was sending credentials via email, so an attacker could potentially steal the user's credentials using HTML injection. For instance, the attacker could use payloads like those found in HackTricks' guide on Dangling Markup. However, I didn’t fully explore this avenue because I received a quick response indicating the issue was a duplicate.
I tried to log in with the credentials but couldn’t because my user was not activated and needed approval from someone on the portal.
So, I turned my attention to the "Forgot Password" feature
And whenever i see captcha i try captcha bypass techniques
Intercept the password reset request using a web proxy tool (e.g., Burp Suite).
Locate the g_recaptcha_response
parameter in the request.
Modify the value of the g_recaptcha_response
parameter to any random string (e.g., randomString123
).
Send the modified request.
Observe that the password reset link is sent successfully to the entered email address without proper CAPTCHA verification.\
Password Reset Vulnerable Logic:
Enter the victim's email address (e.g., 0x88@wearehackerone.com
) in the provided field and submit the password reset request.
Check the password reset email sent. This email contains the password reset token URL, which looks like this:
The reset link contains a hash (p_hash) and a signature (p_sign). I was inspired by common JWT bugs, like tokens being accepted without signatures or with arbitrary signatures, and decided to test the reset link similarly. I removed the value of the p_sign parameter, leaving it empty, while keeping the p_hash value correct. Surprisingly, the server accepted the request normally.
So i started Manipulate the reset URL by fuzzing the p_hash
parameter while leaving the p_sign
parameter empty:
Through fuzzing, identify that the specific reset token B367AD4F
is valid and leads to the password reset page.
Click on the manipulated URL containing the valid reset token:
This URL grants access to the password reset page without requiring further authentication.
On the password reset page, set a new password for the victim's account.
Use the newly set password to log in to the victim's account.
If credentials true you will receive this response
If credentials is not true you will get this response
The Max. Severity for this domain was High So the Bug was reported with high severity