During a recent assessment, our team came upon a vulnerability that felt like finding a hidden door in a seemingly secure fortress. The discovery involved the password-reset mechanism of an application, allowing us to reset any user’s password with just their email address. This flaw circumvents authentication, giving unauthorized access to user accounts. Here’s how we uncovered it and what it means for application security.
Close by not quite
Recently we were tasked with testing an API, a simple, straight-forward assessment with only a handful endpoints. We were supplied the source code in order to validate findings and offer better recommendations on fixes. As part of our approach we focus primarily on Authentication and Authorization issues. In our view these are some of the most prevalent failings of modern applications and can lead to the greatest amount of disruption to an application. During the assessment, we were validating the forgot-password mechanism. Generally the issue we find when we look at this application function is username enumeration, which was present here. However, as we looked closer we found there was also the ability to leverage a forgot-password vulnerability into an account takeover which is what we want to discuss in this post.
Forgot Password
The forgot-password process is a straight forward process, a user gives the application their email address and the server will send them a link in the email provided with a way to reset their password. The link will contain a token or some value that is associated with reseting your password. The below image shows the link from the email which contains the password reset token and the user’s email address.
When the user clicks the link it will take them to a page to enter a new password and submit the form. Behind the scenes the PUT request for resetting the password takes the forgot password token, the new password, and user’s email address from the link.
Here is where the vulnerability enters the process. If you notice in the above screenshot the email address has changed from user.test@rdpt.io to admin.test@rdpt.io but the password-reset token is the same. The request was accepted by the server which returned a 204 response. After submitting the password reset for the admin user we then validated that it worked and the below screenshot shows that indeed did.
So what happened here? The code creating the password-reset token was properly implemented. It created a new password reset token, added the user’s email that was requesting the password reset, and set it in a Redis cache with a 24-hour time to live.
The problem: the validation check misses a detail
The problem occurred when validating the password token. The code only validated that the password reset token existed in the Redis cache. It did not validate the email address supplied was correlated to the password reset token. The code below shows only the password reset token being validated.
A missing verification that the password reset token was correlated to a specific user allowed an attacker to reset any user’s password. There were also multiple instances of username enumeration throughout the application so the likelihood of a successful account take over increased greatly. We would love to say that is the only time we have seen this, but unfortunately it is not.
And we have seen it worse.
In one instance during a test we noticed that we were given a password reset token that both didn’t expire and could be used an unlimited amount of times. In order to reset the password you had to know the the users 8-digit ID, but that was trivially easy to iterate through in order to reset ALL the users’ passwords in just a few minutes. So this ATO we discuss above actually could have been more damaging. The fix we suggested was to validate that the email supplied in the forgot password was the same email that was being reset. Our client had this fixed in no time.
If you’re curious about the way your company is implementing its password-reset token in your applications, read up more on our assessment offerings and consider reaching out to us here and ask us to come take a look.