Skip to content

Gaining access to accounts through password recovery poisoning. Part 1

Not long ago, even very large services were vulnerable to this type of attack, now the problem has been fixed, but there are a lot of services that use the password recovery function. For example, all versions of products written in PHP Laravel, up to the latest version, have been proven to be vulnerable. You can imagine what possibilities it opens for you. So catch the exclusive.

What is this?
Password reset feature poisoning is an attack using HTTP header manipulation, where an attacker can spoof the content of the headers so that he can get the password recovery token from the victim’s account to his server. By adding or changing the HTTP request header values during the application password reset process, it is possible to overwrite the domain to which the recovery link is sent. Are your hands itching already? And for good reason. Currently one in three servers is vulnerable.

First of all, in order to intercept and modify requests, we’ll need a proxy like BurpSuite or OWASP-ZAP and the skills to use it. We’ll intercept and modify on our HTTP header “Host:”. To do so, having set up a proxy, we’ll click on the password recovery link and enter the victim’s data, substituting “Host:” for his server. As a result, the victim will get a password recovery link but with our server, which is where we need to catch the requests in order to get the password recovery token. It must be noted that in order for the attack to be successful, the victim must still click on the retrieved link. However, in most cases the host name is masked by something like “click here to recover your password”. But still we need the victim to click on this link.

The scheme of attack looks something like this

Is that all?
Of course not. Even if the usual “Host Switching” attack doesn’t work, don’t despair, there are other options. Let’s take a look at them.

Double Host header
Depending on how the server reacts to duplicate Host headers in an HTTP request, our malicious input may take precedence over the default values:

POST /login/password-reset HTTP/1.1
Host: <our-domen>

Overriding Headers
Overriding headers such as X-Forwarded-Host, X-Forwarded-Server, X-HTTP-Host-Override and X-Host can sometimes override the Host header values, resulting in the result that we get everything:

POST /login/password-reset HTTP/1.1
X-Forwarded-Host: <our-domen>

Why does this happen?

Password reset poisoning can occur when a website uses HTTP header values to direct traffic or link to pages, which happens in about one in three cases.

Think about what possibilities this opens up for you.