How to find a vulnerability in the password reset function

Father

Professional
Messages
2,605
Reputation
4
Reaction score
569
Points
113
In this article, I will walk you through finding errors related to resetting a user's password. So, before explaining the possible attacks, let's take a look at the general ways to implement password reset functions.

Password reset function implementations:
For every developer, implementing the password reset function is an interesting part. Here he designs the logic and then implements it in code. There is no well-defined industry standard on how to implement a secure password reset feature in your application. Thus, each application has its own way of doing this, for example, via email, unique URLs, temporary passwords, security questions, one-time passwords, etc.

Here is a list of the most commonly used methods:
  • Email with unique URL to reset your password
  • Email sent with temporary password or current password
  • Using security questions and then providing a password reset option
  • Using OTP (One Time Passwords) or Multi-Factor Authentication

Using the password reset function
The exploitation of the password reset feature can be quite interesting. This can lead to high severity errors, such as account hijacking, as well as less serious ones, such as a weak token implementation. Let's take a look at some of them:

1. Leaked token due to host header poisoning.
The attacker modifies the host header in the request to reset the target's password to his own domain.
Code:
GET https://redacted.com/[email protected] HTTP / 1.1
Host: evil.com

Trusting the company, the victim clicks on the reset link. Since the link is generated using the host header, instead of a legitimate site, it leads to the attacker's website. When a target visits this site, their password reset token is sent to the attacker. The attacker now resets the target's password using its token.

SvaXH24wDGY.jpg


Examples of similar vulnerabilities:

2. Sending an array of email addresses instead of a single email address.
In this attack, an attacker can send a password reset link to an arbitrary email address using multiple email addresses instead of one address, which could lead to a complete hijacking of the account.
Code:
POST https://example.com/api/v1/password_reset HTTP / 1.1

Original request body:
Code:
{"email_address": "[email protected]"}

changes to:
Code:
{"email_address": ["[email protected]", "[email protected]"]}

This way, the password reset link will be sent to both the victim and the attacker. And an attacker can use it to completely hijack the account.

Additional Information:

3. Selection of a one-time password for reset.
Now, for the case where the app password reset feature is based on OTP verification. Many programs consider the absence of a speed limit for entering a password acceptable. Thus, we can try OTP brute-force.
We can reset the account password by intercepting the OTP check request and looping through the 6 digit number. Using this, it is possible to change and reset the password of any account by changing the user data and iterating over the password to reset.

jh1Dm5gYI9s.jpg


Examples of such vulnerabilities:

4. Leaked password reset token via Referrer header.
The HTTP Referrer is an optional HTTP header that contains the address of the previous web page from which the current requested page was linked.

5Hc2KSUhasY.jpg


Exploitation:
• Request a password reset to your email address
• Click on the link to reset your password
• Do not change your password
• Go to any third party website (ex: Facebook, Twitter)
• Intercept the request in the Burp Suite proxy
• Check if the password reset token is leaking in the Referrer header.

Examples of such vulnerabilities:

5. Manipulation of answers: replace a bad answer with a good one.
Manipulating responses can lead to minor vulnerabilities. You can use normal password first and record the server response when you entered the correct OTP / token. Then try again with the wrong OTP / token and replace the unauthorized response with a successful one.

We are looking for an answer to a request like this:
Code:
HTTP / 1.1 401 Unauthorized ("message": "unsuccessful", "statusCode": "403", "errorDescription": "Unsuccessful")

And change it to the correct one:
Code:
HTTP / 1.1 200 OK
("message": "success", "statusCode": "200", "errorDescription": "Success")

Thereby bypassing the reset function.

RR4IxTh_Glc.jpg


For more details about this example, see here:
 
Top