Password Reset Poisoning

The first step of exploiting host header attacks is to determine if and how a web application uses the host header. To do that, we can manipulate the host header in a request and check for changes in the response. Do changes in the host header influence the response? If yes, how? Is there a way to exploit these changes by manipulating the host header in a certain way? If a web application uses absolute links anywhere, you should test for host header vulnerabilities.

Password reset poisoning is a fairly common vulnerability that is the result of improper use of the host header to construct password reset links.

---

Identification

After starting the exercise below, we see a simple web application that greets us with a login screen. After logging in with the provided credentials, the page displays some basic user information:

There does not seem to be anything interesting here, so let's move on. When investigating the network traffic, we can see that the web application uses absolute links to load stylesheets and script files. We can test for a potential host header injection by sending a request with a manipulated host header and check whether the web application uses this manipulated host header to construct absolute links:

In the above screenshot, we can see that a manipulated host header with the value evil.htb results in the website reflecting the value in the URLs for the stylesheets. This is because the web application uses the host header to determine the domain for absolute links. This by itself is not an exploitable vulnerability though. We cannot send special characters in the host header to escalate this to an XSS because the web server rejects requests with such invalid host headers. Besides, without an additional vulnerability such as web cache poisoning, we cannot force a victim's browser to send a request with a manipulated host header. Therefore, a reflected XSS via the host header by itself is not exploitable.

Let's investigate the password reset functionality. When we reset our password, we get the following message:

So the web application most likely sends a password reset link via email. In this lab we do not have access to an email account, however, a quick look behind the scenes reveals that the web application does indeed send an email looking like this:

So we successfully identified that the web application uses the host header to construct absolute links. Additionally, we know that the application sends password reset links with a password reset token via email. How could we exploit this?

---

Exploitation

To successfully exploit password reset poisoning, we need to send a password reset request with the email of the victim and a manipulated host header that points to a domain under our control. The web application uses the manipulated host header to construct the password reset link such that the link points to our domain. When the victim now clicks the password reset link, we will be able to see the request on our domain. Most importantly, the request contains the victim's password reset token in the URL. This allows us to steal the reset token, reset the victim's password, and then take over their account.

Let's execute a password reset poisoning attack against the admin user with the email address [email protected] on our vulnerable web application. To exfiltrate the data, we can use a tool like Interactsh. In particular, we can use the browser version which is available here: https://app.interactsh.com/. After a couple of seconds, we obtain a domain name that we can then use in the host header in the password reset request for the admin user:

The web application sends a password reset link to the admin user using an absolute link that it constructed from the manipulated host header we provided. When the admin user clicks the link, we can see the request on the Interactsh website:

We can now use the admin user's password reset token to reset the password and log in with the admin account.

Password reset poisoning is a vulnerability that requires user interaction, as the victim needs to click the poisoned link to enable the attacker to steal the password reset token. Most web applications use HTML to format emails and particularly links. This obfuscates the domain name of the link, such that victims might not notice that the domain name is poisoned until after they have already clicked the link. However, at that point, it is too late as the attacker has already obtained the password reset token.

---

Solving the lab

Due to technical limitations, the lab does not have access to the public internet, thus we cannot use https://app.interactsh.com/ to exfiltrate data since it cannot be reached from the lab instance. Instead, the lab contains a custom implementation on the virtual host interactsh.local. All requests to interactsh.local are logged, just like https://app.interactsh.com/ logs all requests to the generated subdomain. To retrieve the logged requests, we have to access the URL /log on the virtual host interactsh.local.