This is my second write-up in Bug Hunting community and I hope you like this one ;)
I’m going to talk about a common and strange password reset system that I have seen many times in Bug Hunting, PenTesting, etc. and in many cases this system opens the door to attacker to hack user’s accounts.
The story started when I was going to reset my password on a private HackerOne program, and I found something interesting. After I changed my password successfully via password reset URL, I noticed the following request:
From the first glance, you thought that this request is vulnerable to IDOR vulnerability, But I tried to change (“Email”) parameter to another email address, and I got 403 response, so I asked myself why this was not working even there is no any password reset token on the request or authorization token.
Hmmm, maybe server checking the permission through cookies? I tried to change the cookie and I got the same response 403.
After deep thinking I knew how this system works, This system works as follows.
1. User A starts resetting password of User B.
2. User B receives the reset link and clicks on it.
3. The server now will allow the A user to change the password of User B through this endpoint because the resting URL verification is done. When the user clicks on the password reset. This means to the server that the user has clicked on the reset URL that he requested for but in fact he didn’t, the attacker who is requested the password reset. And after this happens user B can change his password through this endpoint without the need for any authorization tokens.
So then we can takeover the user account in the following cases
1. The case of a user started the reset password via email process but he opened the link of reset token and didn’t complete it , maybe he remembered the password during the process of resetting it now we change his password in that case.
2. The attacker starting reset the password of user via his email address and when the user opens the forget password link he received. The server will give the attacker valid permission to change the password of the user through this endpoint using his email address.
13–2–2018 : Vulnerability reported
15–2–2018 : Vulnerability Confirmed
23–2–2018 : Vulnerability Fixed
23–2–2018 : Bounty reward of $1250 issued