A lot of Intrusion Detection Systems are only look for Host: strings when dealing with web server attacks that do "bad things" with the Host: field. An example of that would be the .printer ISAPI overflow that eEye released a few weeks or so ago. We have seen three distinct patterns in signatures attempting to detect this attack. 1. Block/alert all .printer attacks: this causes all .printer attacks to be signaled as attacks, potentially causing many false positives in environments where it is used. However, I would agree that .printer is not recommended at all for public web servers. 2. Blocking shell code signatures: This is only as effective as the sigs are. Writing shell code to avoid these sigs completely can typically be done in a matter of a few minutes. 3. Those that deal with Host: headers. This seems to be the best targeting for this attack sig, but all that we have seen are flawed in their implementation, and here's how to walk past them: The overflow, when released, would have a client request that looked like the following: GET /anything.printer HTTP/1.1 Host: overflow Some IDS's looking for Host: overflows were basically only looking for Host: [overflow]. However, the above attack can also be represented as: GET http://overflow/anything.printer HTTP/1.0 To IIS (and a lot of other web servers) both requests are valid and both requests contain valid host header information. IIS will process both of them in the same manner. So if an attacker changes any of the various exploit programs on the net to place the overflow buffer in http://%s/ instead of Host: %s then that exploit will basically sneak past certain IDS's that are only focusing on Host: data instead of doing proper host header checking. just a heads up Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Like Intrusion Detection, except it stops the attackers of today, yesterday. http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS web server attacks