Hunting for Bugs in Password Reset Feature -2021

Hey Guys!! This is my first post, In this blog post I will explain Hunting for password reset related bugs of an application. So, before explaining the attacks lets understand Common ways of Implementing this.

For every developer, implementing a password reset feature is a very interesting part. This is where he develops a logic and then implements it in the code. There is no well-defined industry standard on how to implement a secure password reset functionality in your application. So, the result is that every application has a different way of doing the same, starting from emails, unique URLs, temporary passwords, security questions, OTP etc.

Here is a list of the most commonly used ways to implement the password reset feature.

Email sent with a unique URL to reset the passwordEmail sent with a temporary password or current passwordSecret questions asked and then given the option to reset the passwordUse of OTP (One-time passwords) or multi-factor authentication

Exploiting Password Reset Feature can be quite interesting as there are many Common ways of exploiting it. It can lead to high severity bugs like Account Takeover as well as low hanging fruit like Weak token Implementation. Lets us look at the few of them:

The attacker modifies the host header of the request to reset the target’s password to their own domain.

GET https://redacted.com/reset.php?email=foo@bar.com HTTP/1.1
host: evil.com

Trusting the company, they click the reset link. As the link is formed with the host header, this instead links to the attacker’s website. When the target visits this site, their password reset token is sent to the attacker. The attacker now resets the target’s password using their password reset token.

Further Reading:

https://hackerone.com/reports/182670
https://hackerone.com/reports/698416
https://hackerone.com/reports/13286

In this attack the The attacker can send a password reset link to an arbitrary email by sending an array of email addresses instead of a single email address and It could lead to full account takeover.

POST https://example.com/api/v1/password_reset HTTP/1.1

Original Request Body:
{“email_address”:”xyz@gmail.com”}

Modified Request Body:
{“email_address”:[“admin@breadcrumb.com”,”attacker@evil.com”]}

In this way, the password reset link get send to both victim as well as attacker. And the attacker can use it to gain Full account Takeover.

Further Reading:
https://hackerone.com/reports/322985
https://twitter.com/HusseiN98D/status/1254888748216655872

Now, In case The password reset functionality of application is based on OTP validation. Many program accepts No rate limit as acceptable risk. So, Bruteforcing OTP is worth trying.

You can reset the password of an account by intercepting the request for OTP validation and bruteforcing the 6 digit number. Using this, it is possible to change and reset the password of any account, by changing the user data and brute-forcing the reset OTP.

Further Reading:
https://hackerone.com/reports/743545
https://hackerone.com/reports/280389

The HTTP referer is an optional HTTP header field that identifies the address of the webpage which is linked to the resource being requested. The Referer request header contains the address of the previous web page from which a link to the currently requested page was followed.

Exploitation:

•Request password reset to your email address
•Click on the password reset link
•Don’t change password
•Click any 3rd party websites(eg: Facebook, twitter)
•Intercept the request in burpsuite proxy
•Check if the referer header is leaking password reset token.

Further Reading:
https://hackerone.com/reports/342693
https://hackerone.com/reports/272379
https://hackerone.com/reports/737042

Response manipulation can give you easy bugs. You can first use the normally and capture the response of reset password when you entered correct OTP/Token. Then try again with wrong OTP/Token and replace the unauthorized response with the success one.

Look for Request and Response like these
HTTP/1.1 401 Unauthorized
(“message”:”unsuccessful”,”statusCode:403,”errorDescription”:”Unsuccessful”)

Change Response
HTTP/1.1 200 OK
(“message”:”success”,”statusCode:200,”errorDescription”:”Success”)

Further Reading:
https://medium.com/@innocenthacker/how-i-found-the-most-critical-bug-in-live-bug-bounty-event-7a88b3aa97b3

Thanks for Reading. Any Suggestions are always welcomed!!

Follow me: https://twitter.com/Sm4rty_