Password reset poisoning via middleware is a part of our authentication vulnerability where an attacker uses the password reset feature. The attacker captures the password reset request and modifies it by inserting their own link. When the attacker sends the link to the victim via email, and the victim resets their password through that link, the attacker also captures their new password. In this way, an attacker can compromise any user’s credentials. If the attacker is successful in logging into the victim’s account, they can perform activities such as identity theft, financial fraud, or privacy violations.
Middleware is used to handle requests and responses in any application or website. Password reset poisoning via middleware, as an attack, is possible through the middleware itself. As I mentioned earlier, an attacker can use the reset or forget password feature to create a link and use social engineering to trick the victim into resetting their password. Then, the attacker captures the victim’s new password. That’s the theory part of this topic, and now we can move on to the practical exploitation, which we will perform in our lab.
Solving the Lab, practical time
Analyzing the requests and responses
As you can see in the lab, we have already been given the credentials: “wiener:peter”. We will use the forget password functionality to perform this attack and gain access to the lab.
As you can see in the screenshot above, I was able to access the lab. After accessing the lab, I went to the forget password feature and used it to reset my password for the “wiener” account. Then I went to a simple exploit server where I opened my email client and analyzed the traffic using Burp. I received an email in my email client which was a forget password request. If you study it carefully, you will notice that it uses a token.
/forgot-password?temp-forgot-password-token=H8gcBL9MWaDo0JGuu9wzRNHgI1IQwrZe
When I click on the complete link, it redirects me to the “enter new password” feature. Now, I am going to change my account’s password. In my case, I have set the same old password again, which was “peter”.
In the proxy lab, when we view traffic, we have two POST-based requests for /forget-password. We will send the POST request to the repeater.
After sending the POST-based request to the repeater, I tried to add an extra header called “X-Forwarded-Host”.
time to solve the lab
Now we will go to our exploit server and copy the provided URL without https:// and /exploit. We will then paste this copied URL into the X-Forwarded-Host header in the repeater tab.
At the end of the request, we added the exploit server’s URL in the x-forwarded-host header and changed the username from “wiener” to “carlos”, which is our target. As you can see in the response, we received a 200 OK response, which means our request has been executed on the server.
Now we will check the logs on our exploit server. In the logs, we will look for the request whose IP is different. We have found a recent request from a different IP which is 10.0.4.101. It contains the GET request /forget-password parameter.
/forgot-password?temp-forgot-password-token=CKAW97gDSy1WrItMGc2dDcLc2hxFAAXB
We have copied this request. Now we will check the first request in our email client when we used the forget password feature on our wiener account. There was also a token used in that email. We will replace that token with the one we obtained from the logs.
After going to the email client, I browsed through the forget password requests and replaced the token with the new token that I extracted from the logs, which was (CKAW97gDSy1WrItMGc2dDcLc2hxFAAXB). The application then redirected me to the new password page.
We have successfully logged in to Carlos’s account and have solved our lab.
Pro tip: If you are confused about which request to modify and where to add your token, you can try browsing through all requests and add your token wherever necessary. It will help you complete your task.
Follow me on Twitter @masaudsec.