Password reset poisoning via middleware
To access the lab visit the following link:
This lab is vulnerable to password reset poisoning. The user carlos will carelessly click on any links in emails that he receives. To solve the lab, log in to Carlos's account. You can log in to your own account using the following credentials: wiener:peter. Any emails sent to this account can be read via the email client on the exploit server.
Click on the given button to access the lab.
On the Lab’s homepage we can see “My account” option. Let’s click on that to attempt login.
Instead of login we can see Forget password option on the page so let’s click on that to see how password reset functionality is working in this lab.
When we click on Forget password it asks to enter correct username or email. Let’s enter correct username “Wiener” we know and hit submit button.
It then says to check email for a reset password link. We can see a Go to exploit server button on our lab’s page. So let’s go to the exploit server.
On exploit server we can see Email client button on the bottom of page. Let’s click on that to see the email we received.
On Email client we can see we got a link to reset password for Wiener. Let’s click on that to reset password of wiener.
Upon clicking the link we got option to enter the New password for wiener. Let’s enter that and hit submit. In this case I just used password as New password.
Now, Let’s go to Burp’s HTTP history tab and see what requests we have captured.
The first request we have is the forget password POST request which has the username of “wiener” which we submitted on forget password page. Right click and send this request to repeater.
The second request is the GET request that has a temp-forgot-password-token and it asks the user to enter New password for the user. Right click and send this request to repeater as well.
The third request is the forgot password POST request that also contains a temp-forgot-password-token and new password for the user Wiener. Right click and send this request to repeater as well.
Now, we have a total of three requests in the Repeater tab which performs the password reset functionality. Let’s test for header injection to see if this application is vulnerable. Let’s go to the exploit server and copy URL of exploit server.
Let’s add the header X-Forwarded-Host: //link_of_exploit_server to our first POST request that was supposed to send password reset email. This header is commonly used to identify the original host requested by the client in the Host HTTP request header. By adding this header to include the link to our exploit server, we aim to test if the application is vulnerable to header injection attacks. If successful, this could potentially redirect traffic to exploit server or expose the application to further exploits.
When we send the modified request, the rendered response says to check email for a reset password link. Remember we added the link of our Exploit Server so let’s go and check if we have received any password reset email for Wiener.
On Exploit Server we can see that we have received a new Password reset email. This means that the application is vulnerable to Header Injection .
From lab’s description we know that the user Carlos always clicks on any link he receives in his email. So, Let’s change username in the same request and send password reset link email to Carlos.
The response code we received is 200 OK so we hope Carlos has received a password reset link on his email.
Now, Let’s go to our exploit server and check if Carlos has clicked on the password reset link or not. On exploit server we can see Access Log button on the bottom of page. Let’s click on that to see the logs.
On viewing the logs we can see a unique IP that looks like an internal IP and we can see a temp-forgot-password-token as well. This means Carlos has clicked on the password reset link he received through email. Let’s copy that token.
In repeater tab Let’s paste that temp-forgot-password-token of carlos in the GET request and click on send button to send request.
Upon sending the request we received 200 OK status code.
Upon rendering the response we can see that the server is now waiting to receive new password of Carlos.
Let’s go to the third request we have in the repeater tab and change temp-forgot-password-token of wiener to carlos. In this case I didn’t changed the new-password parameter. You can change it according to your choice.
Click on send button to send the altered request and we can see the response code 302 Found. In HTTP, a 302 Found status code indicates that the requested resource has been temporarily moved to a different URL. This means the server is redirecting the client to a different location.
We can see a Follow redirection button in the repeater tab. Let’s click on that to see if we are redirected.
Upon clicking Follow redirection button in repeater tab we are redirected to a status code 200 OK.
Now, Let’s go back to the login page and try logging in with updated password of carlos.
We have successfully changed password of Carlos and we logged in using those credentials. The lab is also marked as solved.
Congratulations! The walkthrough of Eleventh authentication lab finishes here.
You can see walkthrough of Twelfth lab by clicking the following link:
