Host Header Vulnerability

[Nedim]

Browsers send Host Header to inform about the URL client wants to visit. Attackers can temper Host Header to manipulate how the application works. Here is how this attack occurs:

1. Attacker makes a request with edited Host Header (Example: malicious-site.com)
2. Web server receives this Host Header (malicious-site.com)
3. If the application is using this Host Header in a link, the malicious site will be displayed. For example, the application may be calling a JS file with Host Header string. In this case, the website will call an address like the one below which points to attacker’s site:
   <script src="http://malicious-site.com/script.js">

This type of attack can affect password reset forms and X-Forwarded-Host header as well.

 

Solution

Security scan tools may flag Host Header related findings as a vulnerability. Here are the best practices for preventing attackers using Host Header:

• Do not use Host Header in the code
• If you have to use it, validate it in every page
• Use hostnames in all IIS websites
• Disable support for X-Forwarded-Host

URL Rewrite rules can be used to find malicious host headers:

1. Click on the site in IIS  Manager
2. Go to “URL Rewrite” (it should be installed first)
3. Click “Add Rule(s)”
4. Select “Blank rule”
5. For “Match URL” section, enter (.) into the “Pattern”
6. In “Conditions” section, click “Add”
7. Enter {HTTP_HOST} into “Condition input”
8. Select “Does Not Match the Pattern” from “Check if input string” list
9. Enter ^([a-zA-Z0-9-_]+.)*domain.com$ into “Pattern” field (change domain name with yours)
10. For the “Action” section, select “Redirect” from the “Action type” list
11. Enter your domain address (https://domain.com/) in the “Redirect URL”
12. Select “Permanent (301)” from the “Redirect type” list
13. Click “Apply”

[Hiep_Le]

Nedim,

Thanks for the great article!

However I would like to point out a typo.

At step 9 you're missing an asterisk before the domain.

Instead of "^([a-zA-Z0-9-_]+.)domain.com$", it should be "^([a-zA-Z0-9-_]+.)*domain.com$"

Regards,

Hiep Le

[Nedim]

Thanks for checking out the post and point out the typo, Hiep! I have updated it

[zazajoby]

For “Match URL” section, enter (.) into the “Pattern”

(.) will match only the first character of the input string. 

(.*) will match the whole input string twice because of the grouping parenthesis

.* will match the whole input string in a single pass

Is the intent to match only the first character of an input URL? Just be looking at the rule, I would guess it would cause all requests to the webserver to be redirected.

Enter ^([a-zA-Z0-9-_]+.)*domain.com$ into “Pattern” field (change domain name with yours)

You may want to escape the "." as in ([a-zA-Z0-9-_]+\.) and domain\.com, to ensure that the regex engine interprets the dot as a literal rather than a wildcard for any single character. As the pattern is currently written, an input string containing sv123!domain_com or domain;com would match.

Also, it might make sense to limit repetition of the ([a-zA-Z0-9-_]+\.) pattern. Maybe use {0,2} instead of * right after it. That would allow a match of zero to two subdomain levels max, such as mydomain.com, or server1.mydomain.com, or server1.svgroup0.mydomain.com.

[zazajoby]

You may want to bound the ([a-zA-Z0-9-_]+\.) pattern further by limiting the number of characters before the dot.

The final result would look like this:

^([a-zA-Z0-9-_]{1,32}\.){0,2}domain\.com$

[Laskalex]

Can someone share the web.config section of this configuration. It may look something like this:

<rule name="RedirectNonWwwToWww" stopProcessing="true">

   <match url="(.*)" />

   <conditions>

      <add input="{HTTP_HOST}" pattern="^domain.com$" />

   </conditions>

   <action type="Redirect" url="http://www.domain.com/{R:0}" redirectType="Permanent" />

</rule>

[vinnynguyen]

<rule name="Host Header Validation" stopProcessing="true">
   <match url="(.)" />
   <conditions>
      <add input="{HTTP_HOST}" pattern="^([a-zA-Z0-9-_]+.)*domain.com$" negate="true" />
   </conditions>
   <action type="Redirect" url="https://domain.com" />
</rule>

[Eswaran2045]

Hi, 

I configured the rewrite rule directly in web.config file. It works for me when I test it in local machine. However, it doesn't work for me when I configure it in iis manager in the production server. Could there be any reason for this?

Thanks in advance

[Nedim]

Hi @Eswaran2045, I would recommend collecting Failed Request Tracing logs in the production server to see whether the rule condition is met

[kjstech]

This seems to eliminate the vulnerability from port 443 but my scanner is still showing it on port 80.  While I could disable binding to port 80, we also use rewrite to redirect from 80 to 443.  So I'm guessing the order in which this happens does matter?

[kjstech]

I also notice that in a local LAN environment this requires you to use the FQDN.

On the domain you could typically go to https://servername and it would load.

Now you must use the FQDN like https://servername.domain.com.

Could the 301 permanant redirect handle switching to the FQDN for you?  Instead of taking you to https://domain.com/ (which is nothing)... fill in the field with the server's FQDN so it redirect you to the full proper URL?  ie) https://servername.domain.com/  - Not sure if that mitigates the vulnerability or not.

Also seeing conflicting info, should the initial rule pattern be (.) or (.*).  Your screenshot contradicts your text instructions.

[SrvrAdmin]

Hello,

       I used the instruction above and while is works to remove the vulnerability which I verified via our vulnerability assessment tool, I can no longer access the site. Any ideas on why this might be? My rule looks exactly the same as the photo above except of course, I used our domain name. 

Solution: I found that using the server name instead of the domain or FQDN works. 

However, when it comes to the exchange server, OWA breaks. Any help with this would be greatly appreciated as it seems that I'm not the only one having this issue: https://www.reddit.com/r/exchange/comments/m27hn9/http_host_header_value_reflection_exchange_2016/ 

[VinhQNguyen]

As kjstech mentioned, my external vulnerability scans were still failing (Redirection via Arbitrary Host Header Manipulation) until I changed the Match URL pattern to (.*) which contradicts Step #5 in the procedural documentation. I also moved my "HTTPS Redirect" rule down (lower priority) in the Inbound Rules hierarchy but doing that alone did not pass the EVS, I needed the (.*) Match URL pattern in the "Redirection via Arbitrary Host Header Manipulation" URL Rewrite Inbound Rule.