Automated scanning for certain classes of vulnerabilities is now possible with AcuMonitor, a service available for Acunetix Web Vulnerability Scanner version 9. One of these new classes of vulnerabilities is Host Header attacks.
To display the contents of a website, the browser first resolves the website domain (www.test.com) to an IP address, connects to this IP address and then makes a request like the one listed below:
GET / HTTP/1.1 Host: www.test.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
Very often multiple websites are hosted on the same IP address. This is where the Host Header comes in. This header specifies which website should process the HTTP request. The web server uses the value of this header to dispatch the request to the specified website. Each website hosted on the same IP address is called a virtual host.
But what happens if we specify an invalid Host Header? If Apache receives an unrecognized Host Header, it passes it to the first virtual host defined in httpd.conf. Therefore, it's possible to send requests with arbitrary Host Headers to the first virtual host. [link]
Another way to pass arbitrary Host headers is to use the X-Forwarded-Host Header. In some configurations this header will rewrite the value of the Host header. Therefore it's possible to make a request like:
GET / HTTP/1.1 Host: www.test.com X-Forwarded-Host: www.attacker.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
In this case the web application handling www.test.com will receive this HTTP request but the value of the Host header will be www.attacker.com.
Host Header attacks where first presented by blogger James Kettle in the post “Practical HTTP Host Header attacks”. [link] The blog post contains more tips and tricks on exploiting and securing websites against this type of attack.
Web applications don't usually expect to receive an invalid value for the Host header. Various web applications handle this situation differently:
Some applications trust this value enough to write it to the page without HTML-encoding like
<link href="http://_SERVER['HOST']" (Joomla)
Others append secret keys and tokens to links containing it
<a href="http://_SERVER['HOST']?token=topsecret"> (Django, Gallery, others)
And some even directly import scripts from it:
<script src="http://_SERVER['HOST']/misc/jquery.js?v=1.4.4"> (Various)
There are two ways to exploit this class of problems:
- Web-cache poisoning; manipulating caching systems into storing a page generated with a malicious Host and serving it to others.
- Abuse alternative channels like password reset emails where the poisoned content is delivered directly to the target.
Acunetix WVS v9 can detect Host Header Attacks
Some cases (where the Host Header is directly reflected on the response) are relatively easy to detect. Here is a screenshot from the Host Header attack alert generated for one of our test websites (http://testhtml5.vulnweb.com) vulnerable to this type of attack.
Other cases however, are much harder to detect.
Password reset poisoning
A common way to implement the password reset/forgotten password functionality is to generate a secret token and send an email with a link containing this token. However, what happens if you request a password reset with an attacker controlled Host Header?
If the web application doesn't protect against this type of attack, it will use the attacker-controlled Host value when composing the reset link. When the user receives this email, and clicks on the reset link, the password reset link containing the token will be sent to the attacker.
As an example, we will use an older version of Piwik that was vulnerable to this type of attacks. When this application is scanned, Acunetix WVS will locate the password reset page and inject a custom Host header pointing to the AcuMonitor domain. Piwik will generate the password reset link using this value and send an email like:
As you can see, the password reset link points to a different domain (the original scanned URL was http://bld02/piwik-0.4.5/ and the password link should normally point to the bld02 domain).
If the user clicks on this link, AcuMonitor will capture this request and send an email with a Host Header Attack alert containing the full URL.