Admin account takeover via weird Password Reset Functionality
Hello all, I hope you’re fine! Our story today is a funny ATO I recently found it, so I decided to share it with you.
Let’s assume that our vulnerable subdomain is
sub.redacted.com and it deals with an API subdomain called
api.redacted.com , and the forget password function on our site works like this :
- Go to
/forgetPassand type the email
- If the email exists, the site sends a reset email, if it doesn’t it gives you an error.
- The backend sends a third-party link with a unique token to redirect you to
https://sub.redacted.com/verify/<UNIQUE-HASH>to type a new password
I started looking into
/forgetPass and asked for a password reset link, and I started looking around the request
There’s nothing suspicious in the request, so let’s analyze the third-party reset link
So, when you click on the reset link which you received in your inbox, it gives you an endpoint to reset your password which is
Behind the scene, when you were be redirected to
https://sub.redacted.com/verify/<UNIQUE-HASH> there’s a request used to verify the hash with
api.redacted.com and its response is the email in which you requested to reset its password
I tried to play with the token, but I got nothing :(
Just let us continue, So the next request is the request for resetting the password. The request requires three parameters:
I tried to put another email, in this case, was victim email, but I got
400 bad request
In the last pic I observed some things:
- The verification of the token was in a separate request.
- The request to change the password doesn’t require any token or something to prove that you’re the account owner
- The response when I changed the email with the victim email was suspicious, I didn’t expect
400 bad requestever!
After some searching and trying some of the known techniques, actually, I got nothing
On the next day, I continued trying to understand how the site resets the password because I felt that I missed something and I observed some weird behavior on the site. The same request which gave me
200 OK in the first time
when I sent the same request again, I got
400 Bad request , it’s the same response if tried to put the victim's email !!
So,mmmmmmmmmmm at this point I think I got the site logic
Since the site doesn’t require any token while resetting the password, and at the same time gives me
400 Bad request when I try to put another email or put my email for another time after resetting and getting
I think that the site only checks if the sent email in the reset request has requested to reset his password or not, regardless of the sent token or verified hash. So let’s exploit it!!
- Firstly, we’ll send a password reset link to the attacker and victim's email
- We’ll ignore all the verification of the token because it’s useless as it’s not used to validate the identity. We just need the site to know that the victim will reset his password and we’ll take charge of the other steps
So, now the site knows that
VICTIM-EMAIL@gmail.com will reset his password ok now we’ll continue the regular process to reset the password, and when the site sends the
I went to the login panel and type the victim email and the password I set, and……. I’mmmmmm innn
Actually, I didn’t expect it will be easy like this, but it took time just to understand the site behavior.
How about taking over the Admin account?
When I have a target to test I collect as much I can the employee's emails from Github and LinkedIn and keep it for default credentials and some stuff like that, So I think it’s time to use it now.
I made a request to reset the password, then intercepted it and sent it to the intruder to see which account on my list exists as admin on the site.
And voilaaaaaaa !! I found one exists
Actually, I didn’t go deeper to reset the employee's password, I just informed the security team that I could take over one of the employees and he may have high privilege access to the site.
— — — — — — — —
and now I’m done, Thanks for reading!
For any feedback or questions, just dm me on Twitter