Key Links
IISTraining.com
hands-on, fast track,
up-to-date training on IIS 5 and 6
IIS Lists
moderated email
discussions on IIS related topics
IIS Boards
online
IIS bulletin boards
About Brett Hill
Advertising Info
if you're interested in
reaching thousands of IIS administrators.
Privacy Statement
IISAnswers Articles
Code Red! Who's to Blame?
And a surprise way to protect your server.
- by Randy Hinders MCSE
Having worked this issue for more than a week now, I recently started working through a list of vulnerable servers on our network. Using the tool from eEye (http://www.eeye.com/html/Research/Tools/codered.html), I scanned our networks (more than 30 network ranges...ughh) to identify vulnerable servers. Then, I started calling the contacts who managed servers. We're trying to prevent bandwidth saturation on our network when Code Red comes back on line.
What I found is a bit surprising. Most people think that because they are not listed on a search engine, do not tell anyone about their site or it "isn't live yet" means that they are not vulnerable. They do not realize that these tools are using automated IP scans. This means you are a target when you are connected to the network and the default web site is answering to the IP (or port forwarding is enabled on the router). It is not a matter of IF someone hit's your machine, but a matter of WHEN. All it takes is time (and a anonymous AOL account with caller ID blocker).
You can be vulnerable with with a "VPN" server, Exchange
Server or
just a dial up server. Often these servers host IIS (or
PWS) and IIS is installed on so many machines people
forget to either STOP THE SERVICE or fail to patch the system.
<rant>
Who is to blame here? I say the systems administrator's
first line supervisor.
This person should be testing their systems and then
reprimanding the
sysadmin at fault. Should someone be reprimanded more than
a "reasonable"
amount, then they should be moved back down to the help
desk. Most managers
are too nice these days. Granted, no system that is
connected to the
internet is 100% secure, but a
vulnerable server puts others at risk. When a
serious vulnerability is discovered and a patch is released, it is
unacceptable for a for servers to remain unpatched.
</rant>
In this process, I found an very interesting security measure
that can be used as
another "step" in the securing your machine process.
The Code Red worm, and script kiddie tools, scan for servers by IP
address. If all your websites use Host Headers such such that when you
type http://<ipaddress>, no web site responds, then you you cannot be
attacked by script or worms that address your server strictly using
an IP address.
Here I try to connect to the URL
http://205.133.113.7/default.ida?nnnnnnnnn.
This uses an IP address to a server that uses only Host Headers. Note
the HOST field is an IP address. Note the server response. That's what
the Code Red worm would have seen too, patched or not.
started....WWWConnect::Connect("205.133.113.7","80")\nsource port: 1681\r\n
REQUEST: **************\nGET /default.ida?nnnnnnnnnnnnnnnnnnnnnnnn
HTTP/1.1\r\n
Host: 205.133.113.7\r\n
Accept: */*\r\n \r\n
RESPONSE: **************\nHTTP/1.1 404 Object Not Found\r\n
Server: Microsoft-IIS/5.0\r\n
Date: Tue, 24 Jul 2001 12:47:24 GMT\r\n
Connection: close\r\n
Content-Type: text/html\r\n
Content-Length: 111\r\n \r\n
<html><head><title>Site Not Found</title></head>\n<body>No web site is
configured at this address.</body></html>
WWWConnect::Close("205.133.113.7","80")\nclosed
source port: 1681\r\n finished.
Now the same request using a Host Header access with the
URL
http://randy.hinders.org/default.ida?nnnnnnnnnnn. Note the Host Header
has the content "randy.hinders.org" and that the server did respond. If
this was an unpatched server, Code Red would have worked. (The response "default.ida
could not be found" response only occurs since this is just an example and
not a attempt to hack the server with an actual Code Red worm).
- started....WWWConnect::Connect("205.133.113.7","80")\nsource
port:
1691\r\n
REQUEST: **************\nGET /default.ida?nnnnnnnnnnnnnnnnnnnnnnnn
HTTP/1.1\r\n
Host: randy.hinders.org\r\n
Accept: */*\r\n \r\n
RESPONSE: **************\nHTTP/1.1 200 OK\r\n
Server: Microsoft-IIS/5.0\r\n
Date: Tue, 24 Jul 2001 12:53:29 GMT\r\n
MicrosoftOfficeWebServer: 5.0_Collab\r\n
Connection: close\r\n
Content-Type: text/html\r\n \r\n
<HTML>The IDQ file default.ida could not be found.\r\n WWWConnect::Close("205.133.113.7","80")\nclosed
source port: 1691\r\n finished.
Thanks for listening, and THANKS for patching your
systems!!
----------------------------------------------------------------------------------
Randy A. Hinders
MCT, MCSE, MCP+I & A+
NT Systems Administrator
donet, inc
1425 arbor ave
dayton, oh 45420
937-256-7288
randyh@donet.com
www.donet.com
PS: I have my firewall configured and you shouldn't see
the above site
unless we have talked before and I have given you access.
But should you gain
access, please let me know ;)
© 2001 Brett Hill. All Rights
Reserved.
No use with express written permission.
Excerpts and screen shots from Microsoft materials and/or Microsoft
products are copyright Microsoft and used under
the 10% rule