experiment supports concept of using host header names as securit y layer
From: Chris Davis (chris.davis@computerjobs.com)
Date: 03/04/03
- Previous message: Dill, Stephen: "RE: code red---- on system that is already (and has been) patched"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Chris Davis <chris.davis@computerjobs.com> To: "'focus-ms@securityfocus.com'" <focus-ms@securityfocus.com> Date: Tue, 4 Mar 2003 10:22:38 -0500
Upon considering this concept further, I have decided that the IIS host
header name information has to be evaluated before any ISAPI filters because
any particular website instance may have different ISAPI filters running on
it. ISAPI filters can't evaluate a request until a virtual site has been
selected and its set of running ISAPI filters has become known to the IIS
process.
As a quick experiment in using a host header name as a security device, I
built out a new Windows 2000 server with IIS. No service packs and no
security patches were installed. I took a Code Red HTTP request
(default.ida.... You know the one) and pulled it up from the IIS server by
IP address. IIS immediately crashed. (Do not do this outside a lab
environment.)
I then shut down & restarted the IIS Server (as Code Red is memory resident
only and clears with a reboot). I created a new website and set up a host
header name for it and disabled the default website. I tried the Code Red
request again by IP. This time, all I got was "There is no web site
configured at this address." IIS did not crash.
This simple configuration step appeared to render my unpatched, unlocked IIS
impervious to Code Red because the request came in to an IP address rather
than hostname and was discarded before it got passed to default.ida for the
overflow exploit.
Then I tried the Code Red request using the hostname I put in as the "host
header name." IIS crashed once again, as expected. The host name was
evaluated and my Code Red request was passed to default.ida on my virtual
site.
It appears to me that this use of the "host header name" field while
disabling the default web server instance will render IIS impervious not
only to IP block scanners that attempt known exploits, but also to worms
that spread by infecting random IP addresses!
A host header name (and a disabled default website) eliminated the
possibility for Code Red to overflow my default.ida when requesting by IP
address. This seems to reduce the set of attackers to people or processes
who request my server _by name_, which eliminates all existing scanners and
IIS worms.
Can anybody else with more resources run experiments in an isolated lab
environment to validate my result?
Thanks,
Chris Davis, Senior CS Major
Computer Science
Southern Polytechnic State University
http://www.WinSnmpWalk.org
-----Original Message-----
From: Chris Davis [mailto:chris.davis@computerjobs.com]
Sent: Monday, March 03, 2003 11:24 AM
To: 'focus-ms@securityfocus.com'
Subject: host header names as security devices
The IIS "host header name" setting provides virtual naming capability for a
single IP/port assignment. I am curious if the use of a host header name
adds any security against IP address range port 80 scanners that attempt to
exploit target hosts.
In the event of an HTTP request sent to the IP address (rather than to the
hostname) of an IIS server running a web site configured with an IIS host
header name, in absence of a default site, the IIS server will return "No
web site is configured at this address" because the HTTP request did not
match a configured host header name and there was no default site to return.
Does IIS short circuit all the ISAPI filtering and such in this case where
the request does not match a configured host header name and no default site
exists? If so, then are unpatched/unknown vulnerabilities not exploitable
when a request is made by IP address rather than host name since the request
may not make it to the ISAPI filters that have buffer overflows (or
encoding%20issues or other vulnerabilities)?
If IIS does short circuit the ISAPI filtering of the request, it seems that
use of host header names (while disabling the default site) can act as an
impediment to automated scanners that scan IP ranges trying exploits without
knowing hostnames.
(The IIS lockdown tool will filter requests with cmd.exe and root.exe and
*.dll and *.ida and such, which you would still want to use to prevent
attacks that do use your configured host header name. In addition to the
IIS lockdown tool's features, the possible host header name ISAPI
short-circuit might add a security layer that excludes all IP block scanner
requests that attempt exploits from the possibility of success.)
Does anybody have inside knowledge of how far an HTTP request to an IIS
server without a default site will be processed before "No web site is
configured at this address" is returned when the HTTP request does not match
a configured host header name? Is there a true security gain in
implementing this concept?
Thanks
Chris Davis, Senior CS Major
Computer Science
Southern Polytechnic State University
http://www.WinSnmpWalk.org
- Previous message: Dill, Stephen: "RE: code red---- on system that is already (and has been) patched"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|