• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Preventing host header attack

Explorer ,
Feb 18, 2020 Feb 18, 2020

Copy link to clipboard

Copied

Hi,

 

Is there way to prevent host header attack on CF2016 (Win Server 2008 IIS7.5)? 

We had server scan and identified this vulnerability where X-Forwarded-Host was modified to trigger redirect to potentially malicious site.

I have seen some references to adding dummy virtual hosts to apache server but, I am not skilled in server administration and not sure how to do that in CF2016.

 

Thank you,

Gena

TOPICS
Connector , Server administration

Views

5.5K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 18, 2020 Feb 18, 2020

Copy link to clipboard

Copied

We're using CF2016 & IIS10.  I haven't been able to manually perform a host header attack on our web applications.

 

Is there any reason that you haven't upgraded IIS to 8, 8.5 or 10?  (IIS 7.5 was released back on 10/22/2009.)

 

If your scan is PCI-related, it should automatically fail because the application is hosted using vendor-unsupported software. (Microsoft has announced Jan. 14, 2020, as the end-of-life date for Windows Server 2008 and 2008 R2.)

 

If you want to add a better layer of protection, consider using StackPath or CloudFlare.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Feb 19, 2020 Feb 19, 2020

Copy link to clipboard

Copied

Thank you, Jamo.

We will be upgrading to the latest MS Windows in the coming weeks. I am just looking into a solution. If there is an additional level of protection in the latest MS Windows Server version then, I will hold off. If there is a some sort of universal solution that will work on both, current Windows 2008 R2 and the Windows Server 2016 (I think this the version we currently support in our organization) then, I will try to implement it.

And, the scan is by the vendor but, not PCI related.

 

Gena

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 19, 2020 Feb 19, 2020

Copy link to clipboard

Copied

We running a newer version of IIS and use many rewrite rules, but you can only do this with the IIS Rewrite module from Microsoft available in newer versions.  We set our default website to not respond (ie, abort) if the remote IP of the user is not a trusted IP.  On any websites that answers to an IP (versus only responding by hostname which requires a newer version of IIS), we use a rewrite condition to detect and block (<add input="{HTTP_HOST}" pattern="^\d+\.\d+\.\d+\.\d+"  />).  You'll also want to suppress the "server" response header so that you aren't advertising that fact that you are using IIS.

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Feb 24, 2020 Feb 24, 2020

Copy link to clipboard

Copied

Thank you, Jamo

We are updating to newer version of windows os soon so, this might be easier. Unfortunately, with this we have to deal as it is now, having IIS 7.5. It does have URL rewrite module.

I am not sure how configuring server to respond to host name only and, not to IP would address the issue (but i did restricted in binding to the local ip address 192.168....) because the test for this vulnerability was done using host name something like this

https://www.mysite.com/help/?host_header=host.whitehatsec.com with following redirect to whitehatsec. I tried it in Burp Suite and indeed there was a redirect with 302 response code.

As you recommended, I set up default default web site and restricted not to use headers in the http response headers section and, I created a custom 404 page.

As for the URL rewrite recommendation, is it for default web site?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 24, 2020 Feb 24, 2020

Copy link to clipboard

Copied

Yes. You'll want to add some logic for the default website.  If you aren't using it, you can just write a rule to return a generic 404 for everything block everything

 

<rule name="Redirect Default Document to 404" stopProcessing="true">
    <match url="(.*)" />
    <action type="Rewrite" url="/doesnotexist.htm" />

    <!-- or consider using one of these actions.

        <action type="CustomResponse" statusCode="403" statusReason="Unauthorized Access" statusDescription="Unauthorized Access" />

        <action type="AbortRequest" />

    -->
</rule>

 

We always use a dedicated IP for the default website and use an abort rule that looks like this. (Add this rule only to the default website and remember to substitiute the non-local IP address.)


<rule name="Block Default IP" patternSyntax="ECMAScript" stopProcessing="true">
    <match url="(.*|^$)" />
    <conditions logicalGrouping="MatchAny" trackAllCaptures="false">
        <add input="{LOCAL_ADDR}" pattern="172.217.6.68" />

        <!-- or use this:

            <add input="{HTTP_HOST}" pattern="^172.217.6.68$" />

        -->
    </conditions>
    <action type="AbortRequest" />
</rule>

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Feb 18, 2020 Feb 18, 2020

Copy link to clipboard

Copied

Gena, I think there's an easy answer for you. Just be sure to define a host name in the bindings for all your IIS sites. That may be easier said than done for some folks, but it should prevent the problem. Let me elaborate.

 

Though first I want to offer a clarification. You refer to this attack as being one "where X-Forwarded-Host was modified to trigger redirect to potentially malicious site." That's not my understanding of what this attack is about. If you read any of various resources about the attack, they discuss how an improperly configured web server could lead to an UNINTENDED site processing the request, not so much a "malicious" one. But the handling of a request by an unexpected site could indeed lead to something malicious (with a request getting to a site that was not as hardened as others were).

 

What many folks do who use IIS (if not most folks, from my experience) is they just leave the IIS "default web site" defined, whose bindings are set to have NO hostname (and to listen to requests for ANY ip address that gets into the server). And they may or may not bother to add other sites, and those may themselves have host header values and IP addresses, which will be matched on an incoming request. 

 

The way things work is that if a request comes into IIS, then whatever host header is sent with it (and whatever IP address it came into the server requesting) is compared to all those sites' bindings, and if any site matches the given host header and/or IP address, then that site will run that request. (And if a given site matches the IP address used but that site was left to have NO host defined in its binding, then again that site WILL process that request, assuming no other site was matched for that host/ip address.)

 

And to be clear, when I refer to the IP address here, this is NOT about the IP address FROM WHICH a request comes. It's only about the IP address used to REQUEST THE SITE. Usually that is determined by a DNS lookup (in the client making the request) where it finds your site and what IP address that domain "lives at", and the request (with that typed in domain and that looked up IP address) is then passed on to the server. Of course, all that can be faked, thus the "attack" problem.

 

As for that "default site" (whether it has that site name, or some other site name), it's especially likely to be the cause of such problems. It's set (by default) to have NO host header and * for its ip address. And what that means is that if a request comes and no sites match that requests's host header and IP address, then this "default" site will handle it.

 

But like I said above, you could have a site that is NOT the default site and DOES list one or more IP addresses that it will answer to, but if it has no host header, then THAT site will respond to a request for THAT ip address and ANY host header.

 

So again, if you make sure to list host headers for all sites you have, then such host header attacks should not be possible. But of course it's a bit of work to make sure all is well. Most people just leave the "Default site" to "handle everything" and can't even reasonably name all the host names that it may be handling.

 

And if you have such a "default" site (with its bindings set for no host header and any ip address), and you don't really "need" it, you could take it out. Now IIS will ONLY respond to requests whose host headers match one of the listed site bindings. Just do be sure that you don't USE that default site for some purpose you're not considering.

 

One other thing: you can tell IIS to LOG the host header, so you can SEE what requests have been coming in asking for perhaps unexpected host names. It doesn't log the host header by default, but if you go to the logging feature in IIS and click "select fields", you will see toward the bottom "hosts" (or as its column will be labelled in the log file, cs-host, which means the client-to-server host requested). You may want to especially look at any default site you have (really any site whose binding has no host defined). You may be surprised to see what sort of odd hostnames come in,

 

I hope that explains things.

 

And you may wonder why you didn't find this explanation elsewhere. As I took a quick look at the top few results for host header attack, it was indeed sad to see that so many only discuss the problem and solutions in terms of Apache or Nginx, particularly the notion that a request having an unrecognized header would go to the "first" virtual host.

 

That's definitely not how IIS works--other in this general sense that for most people, the "first site" listed when they install IIS is the "default site", and it has (by default) these characteristics of the binding having no header and accepting ALL incoming IP addresses. But as I have shown above, this is also an issue for ANY site you have whose binding has NO host name defined.

 

I know that was a lot to take in, and I may have missed something or not explained it as well as I could. Let us know what you think.

 

And I should add that I agree with the concern and suggestion that James (Jamo) made. 🙂


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Feb 19, 2020 Feb 19, 2020

Copy link to clipboard

Copied

Hi Charlie, thank you and, I really appreciate your excellent explanation. 

I looked at our IIS settings and particulary at the Default site. It is not running, so my questions would be:

1. Should I remove it? 

2. Also, I checked the bindings for Default site and, as you said, no host, no IP defined. Nor, http and https set in the binding. Only types net.tcp, net.pipe, net.msmq and msmq.formatname...

3. Should I set our current website set as default site? 

4. As for bindings for our site, we have only https type set to * IP and with blank host name and port 443.

When I click on Edit this binding, in the IP drop down beside All Unassigned, there are two IP addresses, one is the local machine IP 192... and the other is external network server IP 172... so, I can not add IP address from DNS record.

Also, the host name is grayed out so, on your advice to add host name, its not possible.

The only way to enter host name if, I add http type binding.

 

What am I missing here? How to, following your advice, update the binding on our site?

 

Thank you again,

Gena

 

PS. Great point on loggin. I updated to include host headers.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Feb 19, 2020 Feb 19, 2020

Copy link to clipboard

Copied

Hi Charlie, thank you and, I really appreciate your excellent explanation. 

I looked at our IIS settings and particulary at the Default site. It is not running, so my questions would be:

  1. Should I remove it? 
  2. Also, I checked the bindings for Default site and, as you said, no host, no IP defined. Nor, http and https set in the binding. Only types net.tcp, net.pipe, net.msmq and msmq.formatname...
  3. Should I set our current website set as default site? 
  4. As for bindings for our site, we have only https type set to * IP and with blank host name and port 443.

When I click on Edit this binding, in the IP drop down beside All Unassigned, there are two IP addresses, one is the local machine IP 192... and the other is external network server IP 172... so, I can not add IP address from DNS record.

Also, the host name is grayed out so, on your advice to add host name, its not possible.

The only way to enter host name if, I add http type binding.

 

What am I missing here? How to, following your advice, update the binding on our site?

 

Thank you again,

Gena

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 20, 2020 Feb 20, 2020

Copy link to clipboard

Copied

I recommend enabling the default website so it doesn't perform a redirect. Configure it so it doesn't do or reveal anything.  This may be difficult using IIS7.5, but you may could create a custom 404 page. You could also add an IP restriction or enable security so that unauthorized visitors are met with a challenge or non-200OK response.

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Feb 24, 2020 Feb 24, 2020

Copy link to clipboard

Copied

Sorry for the delay in replying to this. So first, I know that you have gone on to have many other messages here with James/Jamo, so I will only respond for now to your direct questions in your reply to me above.

 

As for whether you should remove the default site, I wasn't saying that. I was simply saying to be careful about how it's configured. But since you said that you found it to have NO http or https binding, then that binding itself is not playing a factor in the problems you are trying to solve. But as your other discussions with Jamo have found, you may have other settings in IIS for the default site (especially rewrites or redirects configured for it), and THOSE may be having an impact. Again, I'm not saying REMOVE it, I'm merely saying it's your responsibility to assess how it's configured, and to resolve whatever about it may be contributing to your problem, if it is.

 

And no, I would not just say to "set your current site to the default site", not at all.

 

As for the drop-down of IP Addresses in the IIS bindings page for a site, note that CAN BE OVERWRITTEN with any value. You don't need to select only from the convenience list of IPs offered.

 

Finally, as for the grayed out host name field for an https binding, that is known IIS issue, covered in various places, including one from a CFer. each showing multple "solutions". I will levae you to consider those, if your work with Jamo doesn't get you to a solution.


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
May 12, 2020 May 12, 2020

Copy link to clipboard

Copied

Wrong topic

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Sep 30, 2022 Sep 30, 2022

Copy link to clipboard

Copied

I was guilty of having a default website as Charlie describes. Since it is not used I shut it down. The scan still flagged the vulnerability. This is the solution from Microsoft using URL Rewrite module:

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Feb 03, 2023 Feb 03, 2023

Copy link to clipboard

Copied

Update: My solution above did not work. Our Qualys scan continues to flag this vulnerability.

GET https://my.site.domain.name/
Host: ***.qualysperiscope.com.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15
Accept: */*

My understanding of this is the scan is changing the request header Host value which triggers a DNS lookup of the qualysperiscope.com which is bad.

So in the Application.cfc OnRequestStart() method I added code to compare the request header host value to what it should be (white list).

<cfif getHttpRequestData().headers["host"] NEQ "my.site.domain.name">
<cfthrow message="External Service Interaction via HTTP Header Injection" detail="SSRF ATTACK"><cfabort>
</cfif>

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Feb 08, 2023 Feb 08, 2023

Copy link to clipboard

Copied

LATEST

Thanks for sharing your experience, @berniemiller .

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation