The Malicious Maneuvers of Host Header Injection: Exploiting Vulnerabilities and Bypassing Security
As discussed in the previous blog I am writing about the impacts of Host Header Injection (HHI) attacks.
For this blog I have referred to Portswigger Web Security Academy.
Some of the vulnerabilities which can arise through Host Header Injection are following:
- Password Reset Poisoning
- Web Cache Poisoning
- Exploiting classic server-side vulnerabilities
- Bypassing authentication
- Virtual host brute-forcing
- Routing-based Server-Side Request Forgery (SSRF)
Password Reset Poisoning:
Password reset poisoning is a technique whereby an attacker manipulates a vulnerable website into generating a password reset link pointing to a domain under their control. This behavior can be leveraged to steal the secret tokens required to reset arbitrary users’ passwords and, ultimately, compromise their accounts.
How does a password reset work?
Virtually all websites that require a login also implement functionality that allows users to reset their password if they forget it. There are several ways of doing this, with varying degrees of security and practicality. One of the most common approaches goes something like this:
The user enters their username or email address and submits a password reset request. The website checks that this user exists and then generates a temporary, unique, high-entropy token, which it associates with the user’s account on the back-end. The website sends an email to the user that contains a link for resetting their password. The user’s unique reset token is included as a query parameter in the corresponding URL:
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
When the user visits this URL, the website checks whether the provided token is valid and uses it to determine which account is being reset. If everything is as expected, the user is given the option to enter a new password. Finally, the token is destroyed.
This process is simple enough and relatively secure in comparison to some other approaches. However, its security relies on the principle that only the intended user has access to their email inbox and, therefore, to their unique token. Password reset poisoning is a method of stealing this token in order to change another user’s password.
How to construct a password reset poisoning attack
If the URL that is sent to the user is dynamically generated based on controllable input, such as the Host header, it may be possible to construct a password reset poisoning attack as follows:
The attacker obtains the victim’s email address or username, as required, and submits a password reset request on their behalf. When submitting the form, they intercept the resulting HTTP request and modify the Host header so that it points to a domain that they control. For this example, we’ll use evil-user.net.
The victim receives a genuine password reset email directly from the website. This seems to contain an ordinary link to reset their password and, crucially, contains a valid password reset token that is associated with their account. However, the domain name in the URL points to the attacker’s server:
https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j
If the victim clicks this link (or it is fetched in some other way, for example, by an antivirus scanner) the password reset token will be delivered to the attacker’s server.
The attacker can now visit the real URL for the vulnerable website and supply the victim’s stolen token via the corresponding parameter. They will then be able to reset the user’s password to whatever they like and subsequently log in to their account.
In a real attack, the attacker may seek to increase the probability of the victim clicking the link by first warming them up with a fake breach notification.
Web Cache Poisoning via the Host header
When probing for potential Host header attacks, you will often come across seemingly vulnerable behavior that isn’t directly exploitable. For example, you may find that the Host header is reflected in the response markup without HTML-encoding, or even used directly in script imports. Reflected, client-side vulnerabilities, such as XSS, are typically not exploitable when they’re caused by the Host header. There is no way for an attacker to force a victim’s browser to issue an incorrect host in a useful manner.
However, if the target uses a web cache, it may be possible to turn this useless, reflected vulnerability into a dangerous, stored one by persuading the cache to serve a poisoned response to other users.
To construct a web cache poisoning attack, you need to elicit a response from the server that reflects an injected payload. The challenge is to do this while preserving a cache key that will still be mapped to other users’ requests. If successful, the next step is to get this malicious response cached. It will then be served to any users who attempt to visit the affected page.
Standalone caches typically include the Host header in the cache key, so this approach usually works best on integrated, application-level caches. That said, the techniques discussed earlier can sometimes enable you to poison even standalone web caches.
Exploiting classic server-side vulnerabilities
Every HTTP header is a potential vector for exploiting classic server-side vulnerabilities, and the Host header is no exception. For example, you should try the usual SQL injection probing techniques via the Host header. If the value of the header is passed into a SQL statement, this could be exploitable.
Accessing restricted functionality
For fairly obvious reasons, it is common for websites to restrict access to certain functionality to internal users only. However, some websites’ access control features make flawed assumptions that allow you to bypass these restrictions by making simple modifications to the Host header. This can expose an increased attack surface for other exploits.
Accessing internal websites with virtual host brute-forcing
Companies sometimes make the mistake of hosting publicly accessible websites and private, internal sites on the same server. Servers typically have both a public and a private IP address. As the internal hostname may resolve to the private IP address, this scenario can’t always be detected simply by looking at DNS records:
www.example.com: 12.34.56.78 intranet.example.com: 10.0.0.132
In some cases, the internal site might not even have a public DNS record associated with it. Nonetheless, an attacker can typically access any virtual host on any server that they have access to, provided they can guess the host names. If they have discovered a hidden domain name through other means, such as information disclosure, they could simply request this directly. Otherwise, they can use tools like Burp Intruder to brute-force virtual hosts using a simple wordlist of candidate subdomains.
Routing-based SSRF
It is sometimes also possible to use the Host header to launch high-impact, routing-based SSRF attacks. These are sometimes known as “Host header SSRF attacks”.
Classic SSRF vulnerabilities are usually based on XXE or exploitable business logic that sends HTTP requests to a URL derived from user-controllable input. Routing-based SSRF, on the other hand, relies on exploiting the intermediary components that are prevalent in many cloud-based architectures. This includes in-house load balancers and reverse proxies.
Although these components are deployed for different purposes, fundamentally, they receive requests and forward them to the appropriate back-end. If they are insecurely configured to forward requests based on an unvalidated Host header, they can be manipulated into misrouting requests to an arbitrary system of the attacker’s choice.
These systems make fantastic targets. They sit in a privileged network position that allows them to receive requests directly from the public web, while also having access to much, if not all, of the internal network. This makes the Host header a powerful vector for SSRF attacks, potentially transforming a simple load balancer into a gateway to the entire internal network.
You can use Burp Collaborator to help identify these vulnerabilities. If you supply the domain of your Collaborator server in the Host header, and subsequently receive a DNS lookup from the target server or another in-path system, this indicates that you may be able to route requests to arbitrary domains.
Having confirmed that you can successfully manipulate an intermediary system to route your requests to an arbitrary public server, the next step is to see if you can exploit this behavior to access internal-only systems. To do this, you’ll need to identify private IP addresses that are in use on the target’s internal network. In addition to any IP addresses that are leaked by the application, you can also scan hostnames belonging to the company to see if any resolve to a private IP address. If all else fails, you can still identify valid IP addresses by simply brute-forcing standard private IP ranges, such as 192.168.0.0/16.
Shielding Yourself from HHI: How to Stay Safe
Thankfully, several measures can help mitigate the risks of HHI:
- Embrace HTTPS: Encrypting communication between your browser and the server makes it much harder for attackers to intercept and manipulate the Host header.
- Keep Software Updated: Outdated software often contains vulnerabilities that attackers can exploit through HHI. Regularly update your operating system, web browser, and other software.
- Be Wary of Unfamiliar Links: Don’t click on suspicious links, especially in emails or messages. Phishing attempts often leverage HHI to redirect you to fake websites.
- Choose Reputable Websites: When entering sensitive information, ensure you’re on the legitimate website. Look for the padlock symbol in the address bar and a valid SSL/TLS certificate.
For any queries contact on my Twitter and LinkedIn profiles -
