Author: Robert Boyce

Vulnerability Overview

Name:Microsoft Internet Information Server (IIS) IDA/IDQ ISAPI Extension Buffer Overflow
CVE (Common Vulnerability and Exposure): CAN-2001-0500
Variants:Code Red II, Code Blue, Code Green
Systems Affected:Microsoft Windows NT 4.0 Internet Information Services 4.0, Microsoft Windows 2000 Internet Information Services 5.0, Microsoft Windows XP beta Internet Information Services 6.0 beta
Protcols Used:This vulnerability is accessible through the HyperText Transport Protocol (HTTP) protocol running over TCP/IP.
Services Used:This vulnerability is found in all versions of the Microsoft Internet Information Server (IIS) Web server running the Indexing service.
Description:

This vulnerability could allow an attacker, from a remote location, to gain full system level access to any server that is running a default installation of Windows NT 4.0, Windows 2000, or Windows XP and using the Microsoft Internet Information Services (IIS) Web server software.

The vulnerability lies within the code that allows a Web server to interact with Microsoft Indexing Service functionality, which is installed by default on all versions of IIS. The problem lies in the fact that the .ida (Indexing Service) ISAPI filter does not perform proper "bounds checking" on user inputted buffers and therefore is susceptible to a buffer overflow attack.

Attackers that leverage this vulnerability can perform any desired system level action, including but not limited to, installing and running programs, manipulating web server content, adding, changing or deleting files and even possibly using the compromised system to launch additional attacks directed against other systems.

This vulnerability was discovered by Riley Hassell of eEye Digital Security (http://www.eeye.com).

Protocol and Service Description

IP - Internet Protocol

IP is the basis by which data is sent from one computer to another across the Internet.

IP is a connectionless protocol that does not assume reliability from the lower layers of the TCP/IP protocol stack. IP does not provide reliability, flow control or error recovery, these functions must be supplied by protocols at a higher layer. This means that packets sent by IP may become lost, or even arrive out of ordered.

For more information on IP refer to:
RFC 791 http://www.ietf.org/rfc/rfc791.txt
RFC 919 http://www.ietf.org/rfc/rfc919.txt
RFC 922 http://www.ietf.org/rfc/rfc922.txt
RFC 950 http://www.ietf.org/rfc/rfc950.txt
RFC 1349 http://www.ietf.org/rfc/rfc1349.txt

TCP - Transmission Control Protocol

While IP is concerned with the actual delivery of the data TCP is concerned keeping track of the individual units of data that comprise a complete message.

TCP is a connection-oriented protocol complete with error recovery, flow control and reliability. This ensures that a persistent connection will be established between the client and server until all data has been successfully sent and received.

For more information on TCP refer to:
RFC 793 http://www.ietf.org/rfc/rfc793.txt

HTTP - Hypertext Transfer Protocol

HTTP (HyperText Transfer Protocol) is one of the most widely used protocols currently in use throughout the World Wide Web and is based on request-response activity. In the case of the Internet a client application, usually a browser, establishes a connection to a server and sends a request in the form of a request method. The server responds with a status line including the message's protocol version and a success or error code, followed by a message containing server information, entity information and possibly body content.

The HTTP request-response transaction is simply divided into four steps:

1. The client opens a connection.
2. The client sends a request to the server.
3. The server sends a response back to the client.
4. The connection is closed.

In most circumstances, including that of the Internet, HTTP travels over TCP connections. The default is TCP port 80 but any port (as long as it is not already in use) can be used. It is possible for HTTP to be transported over other underling protocols, but it does require a reliable connection to be established.

For more information on HTTP refer to:
RFC 1945 HTTP/1.0 (May 1996) http://www.ietf.org/rfc/rfc1945.txt
RFC 2068 HTTP/1.1 (January 1997) http://www.ietf.org/rfc/rfc2068.txt
RFC 2616 HTTP/1.1 (June 1999) http://www.ietf.org/rfc/rfc2616.txt

Indexing Service

The Indexing service in Internet Information Services (IIS) provides search capabilities across both Intranet and Internet web sites. It can extract content from files and construct an indexed catalog to facilitate efficient and rapid searching. Users are able to enter search criteria into a prepared web page and have the results displayed back to them.

Description of Variants

While there is no variant in the vulnerability itself there have been a few unique exploits that take advantage of this security hole.

Code Red II

Code Red II used the same buffer overflow to compromise systems but had a much different payload. This variant was more deadly, it required more than a reboot to clean the system, and instead of defacing web sites and launching denial of service attacks it installed a remote backdoor program. There was also greater care taken with the random subnet generation routine which increase the spread of infection.

Code Blue

The Code Blue worm behaves slightly different. It uploads the worm file from another infected machine, whereas Code Red would download and impose itself on the machine. The worm is spread through a single .dll and is execute via a .exe program. Code Blue also patches the IIS buffer overflow vulnerability to prevent re-infection.

Code Green

Code Green is like a vigilantly variant of Code Red. This worm will actively seek out systems infected with Code Red, clean the infection, and patch the system to prevent re-infection. This is a very interesting idea, although it would probably cause more havoc then good.

Detailed Vulnerability Description

Microsoft's IIS web server installs several Internet Services Application Programming Interface (ISAPI) extensions by default. These extensions consist of dynamically linked libraries (dll) which enable developers to extend the functionality beyond what is natively provided by IIS. It is one of the ISAPI extensions, idq.dll, which is responsible for this vulnerability. The idq.dll extension has two functions:

• It provides support for Internet Data Administration (.ida) files, which are scripts that can be used to manage the indexing service.
• It processes Internet Data Query (.idq) files, which are used to implement custom searches.

The exploit occurs because the idq.dll contains an unchecked buffer in a section of code that handles the input of the URLs. This means that the idq.dll does not perform proper input validation and blindly write all data sent by the user to the buffer that was created by the program. If the data sent by the user is greater than that expected by the program (that which can be stored in the buffer) then the data can overflow into adjacent buffers and overwrite or corrupt the data held within them. This additional data usually contains code designed by the attacker to trigger specific actions, in effect sending new instructions to the target computer. Using this technique it is possible for an attacker to establish a HTTP session with a server and send an abnormally large request (with additionally designed code) that would result in a buffer overflow, executing the code of the attackers choice.

It is important to note that the buffer overflow occurs before any indexing functionality is actually requested. This means that even though idq.dll is a component of Indexing Service, the service would not need to be running in order for an attacker to exploit this vulnerability. As long as the script mapping for .idq or .ida files were present, and the attacker could establish a web session, it would be possible for the attacker to exploit this vulnerability.

Since the idq.dll runs in the local system context, exploiting this vulnerability would give the attacker complete control of the server, allowing the attacker to execute any code/commands at the operating system level.

How to Exploit this Vulnerability

This vulnerability has been associated with one of, if not the most devastating Internet worms ever released into the wild. The now infamous 'Code Red' worm made headlines when it began to wreak havoc throughout the Internet in such a short period of time starting on July 12, 2001. There have been a few variants of this worm since the release of the original. Although each use the same vulnerability described previously to exploit systems some differences have been discovered in the code. Each variant is briefly discussed below.

Code Red version 1 (CRv1)

CRv1 was first discovered in the wild on July 12, 2001. After successful infection the worm would check the date of the system. If the date were between the 1st and the 20th the worm would generate a random list of IP addresses and try to infect other systems on that list. If the date were between the 20th and the 28th the worm would launch a Denial of Service attack against www.whitehouse.gov. This worm however had one small imperfection, it used a static seed when generating the random list of IP addresses. This inhibited the worm from spreading very quickly because each infected machine would only probe machines that were either already infected or that were not vulnerable.

Code Red version 2 (CRv2)

CRv2 was first discovered on July 20, 2001. It has almost identical code to that of CRv1 with one slight difference, the static seed was replaced with a random seed. So now the list of randomly generated IP addresses were truly random and the propagation of the worm was much quicker. It was reported that over 359,000 systems were infected within the first 14 hours.

CRv2 was also found to effect additional devices with web interfaces, such as routers, switches, and printers. Although these devices were not infected with the worm they were caused to crash or reboot.

CRv1 and CRv2 are both memory resident and can be removed by simply rebooted the infected system. There is however a good chance the system would be re-infected if the appropriate patches were not applied.

Code Red II

Code Red II was first discovered on August 4, 2001. This worm was written with entirely new code and has no association with the original worm. When Code Red II infects a system it first determines if that system had previously been infected. If not the worm sets up a trojan backdoor into the system, then after 1 day reboots the system. Code Red II is not memory resident like the CRv1 and CRv2, so a reboot will not remove the worm. After the reboot the worm begins to spread. It generates a list of random IP addresses to target, using a slightly different technique then either CRv1 or Crv2.

The Payload of the worm is also different. It does not deface web pages or launch attacks it does something which is much more serious. It installs a mechanism for remote administrator level access to the system. This would allow any code to be executed on the target machine.

***Note that the remainder of the paper will deal with Code Red Version 1.

Manual Explitationi

To perform this exploit manually an attacker could make a TCP/IP connection to the server on port 80 via a Telnet or NetCat session, or even by using an Internet Browser. The attacker could then enter the HTTP GET request using the same overflow string seen in the Code Red worm itself. The following example show how this could be accomplished using a Telent session.

C:\ telnet www.targetsystem.com 80
GET/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucb
d3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u
9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0

This string could also be used as a URL inside the browser, just remove the GET and the HTTP/1.0. Those are taken care of by the browser

Step by Step Analysis

An extremely detailed step-by-step analysis of the original Code Red worm has previously been conducted by Ryan Permeh and Marc Maiffret of eEye Digital Security. Instead of recreating their great work much of the following information will be taken from their analysis. Full details of the eEye analysis can be found at http://www.eeye.com/.

Since the worm seems to contain three distinct actions (system infection, web page hack, and denial of service attack against www.whitehouse.gov) this analysis will be broken into three sections, each offering a detailed explanation of the worm's activities.

System Infection

1. System infection begins when an IIS web server, which is vulnerable to the indexing buffer overflow, receives a HTTP get request that contains the Code Red exploit.
   The instruction pointer (EIP), which holds the address of the next instruction to be executed, is overwritten with an address that to points to an instruction within msvcrt.dll. This causes the program flow to divert back to the stack and jump into the worm code that is held in the body of the initial HTTP request.
2. The initial code of the worm begins to execute.
   The worm sets up a new stack for its own use and then moves on to initialize its function jump table.
3. The worm begins to execute the data portion of the exploit.
   The worm then needs to set up a stack based internal function jump table to store function addresses (this give the worm a better chance of executing cleanly on more systems).
   The worm loads the following functions:

   From kernel32.dll	From infocomm.dll	from WS2_32.dll
   GetSystemTime CreateThread CreateFileA Sleep GetSystemDefaultLangID VirtualProtect	TcpSockSend	socket connect send recv closesocket

   The worm stores the base address of w3svc.dll which it will later use to potentially deface the infected website.

4. The worm performs a WriteClient (Part of the ISAPI extension API), sending "GET" back to the attacking worm possibly sending the message of a new infection.
5. The worm will count the number of threads currently in action. If the number of threads is 100 then control is passed to the web page hack functionality. If the number of threads is less than 100 the worm will create a new thread that is an exact replica of the worm.
6. The worm has a built in "lysine deficiency", a check to prevent the malicious code from spreading further.
   The worm performs a check for the file c:\notworm to determine if the worm has previously infected the system. If the file exists then the worm will become dormant. If the file does not exist then the worm will continue its infection.
7. The worm now determines the local time of system (in UTC).
   If the time is greater then 20:00 UTC the worm will proceed to launch the denial of service attack against www.whitehouse.gov. If the time is less then 20:00 UTC the worm will continue to try and infect additional systems.
8. The worm will attempt to infect new hosts by sending the malicious code to any IP that it can connect to port 80 on.
   It uses multiple send()'s so packet traffic will be broken up. After a successful send it closes the socket and goes to step 6, repeating the loop infinitely.

Web Page Hack

1. The worm will first attempt to determine if the local operating system language is English (US). If the infected host is an English (US) system then the worm will proceed to deface the local website with "Hacked by chinese !". If the system is not English (US) this worm thread will go to step 6 of the 'System Infection' functionality.
2. This worm thread now sleeps for two hours. The reason for this is not completely understood, although it is speculated that it gives the other threads time to spread the infection before making its presence known via the web page hack.
3. The worm now alters the systems web page by modifying code in memory, a technique known as 'hooking'. Modifications are made to w3svc.dll to allow the worm to change the data being written back to clients who request web pages of an infected server.
4. The worm then sleeps for ten hours after which this thread will return w3svc.dll to its original state.
5. Execution after this proceeds to step 6 of the 'System Infection' functionality.

Denial of Service Attack

1. Each thread will attempt to target www.whitehouse.gov on port 80 by establishing a connection and sending 100k of data. If this connection is successful then the worm will create a loop that performs 18000h single byte send()'s to www.whitehouse.gov.
2. After this activity the worm will sleep for about four hours, it will then repeat this attack procedure.

The infected systems will scan the Internet looking for vulnerable systems.

The diagram above illustrates, from a very high level, how a typical company would have their web server connected to the Internet (in this case an IIS web server). People from all over the world would then be able to connect to this web server using a standard Internet browser. To allow for these connections the company would have to open TCP port 80 (HTTP default port) on their corporate firewall. Simple yet secure right. Not quite, there is one huge problem. The Code Red exploit also travels over TCP port 80. The corporate firewall in this case offers absolutely no protection from the Code Red worm.

The worm can also be introduced internally, perhaps through a unprotected mobile user.

It is very common to see an organization focus less of their security efforts on their internal networks, this can prove to be a huge oversight. In the case illustrated above a default Windows 2000 server (residing on a mobile laptop) was attached to the internal network. This laptop could have been infected with Code Red through a home connection and later connected to the corporate WAN. At this point the worm can begin to wreak its havoc infecting all vulnerable machines in sight, internal and external.

Attack Signature

A full packet capture of the Code Red worm can be found in Appendix A. This capture illustrates the complete session of TCP/IP packets that a single infected system would send when trying to replicate and infect other systems.

Identifying The Worm Through Signature Based IDS

Signature based IDS look for patterns within the packets to identify possible malicious activity. The following signature can be used, and is used by many IDS systems, to identify Code Red activity. This signature is specific to CRv1 and CRv2, the signature for Code Red II is slightly different.

/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801
%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0

Identifying The Worm Through IIS Web Server Logs

The following entry could be found in an IIS Web Server log if the system was probed by the Code Red worm (CRv1 and/or CRv2). It is important to note that this entry would be the same whether the system was infected or not. Therefore it is impossible to tell strictly of the basis of IIS logs if Code Red has infected the system. However, if entries like this are found and it is known that the system has not been patched for this vulnerability there is a very good chance that the system has been infected.

"GET default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u909
0%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 404 10100 "-" "-"

Other Possible Ways to Detect Code Red

There are other possible means by which to detect the presence of Code Red on a network.

The system administrator may notice that the server is not performing as usual. Code Red may be using enough CPU cycles to impact the server's normal routine prompting the system administrator to investigate further.

A few techniques the administrator could employ are:

1. Using a 3rd party application (the process may be hidden from native tools) to determine exactly what processes are running. This would show if any unexpected processes were running.
2. Using the netstat command (netstat -an) to get a quick listing of all active TCP and UDP connections. This would show if there were an abnormal number of outbound connections originating from the server.

It may also be possible to use the auditing features of the corporate proxy server, the Internet firewall, or the boarder router to determine if any abnormal activity is taking place. These logs contain a wealth of information but are seldom reviewed.

How to Protect Against the Worm

Now that the potential destructive capabilities of this worm have become evident, it is important to recognize some of the ways in which to protect against them. Many of the common security components or devices are not adequate to deal with this threat. Take a firewall for example. Since the worm travels over TCP port 80 traditional firewalls are not able to filter the traffic from reaching the web servers, lest the administrator wants to stop all valid web traffic as well.

IDS sensors are able to detect the signature of the worm but the actions they can take are limited. In the most extreme cases some IDS network sensors have the capability to reset connections. This will still not prevent the infection of a vulnerable system due to the fact that exploit only needs to send one HTTP session for the worm to spread, this eliminates the possibility of the IDS resetting the connection before the server receives the malicious payload.

One of the only ways to truly prevent this worm from infecting a system is to make sure all applicable security patches are applied, a practice all to uncommon in the industry.

These patches can be found at the following locations.
Windows NT 4.0:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30833

Windows 2000 Professional, Server and Advanced Server:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30800

Another good means by which to proactively protect your systems is through OS and application hardening. Operating System (OS) hardening simply pertains to disabling services that are not needed for the system to perform its basic functions. As an example take a default installation of Windows 2000 Server. Some services, such as SNMP will be enabled and started automatically during boot up. Most times these services are not needed and should be disabled. Otherwise your system can be unnecessarily exposed. The same actions can be taken with applications. In this case the IIS web server has many additional features installed and enabled by default, one of which is the Indexing service. With minimal configuration changes one can make their web server, or other application much more secure. Detailed hardening guidelines for both IIS and Windows 2000 (among other things) can be purchased from SANS.

It is also good security practice to routinely conduct vulnerability assessments against ones own systems. Vulnerability assessments are a proactive process in which the system administrator or local security officer will simulate real attacks against a system to determine where that system's exposures are. This offers a means to keep current with patches and helps ensure that the overall risks are minimized. There are many good tools freely available to conduct such assessments, some of which exclusively look for Code Red vulnerabilities.

References

1. "Hypertext Transfer Protocol - HTTP/1.1." June 1999. URL:http://www.ietf.org/rfc/rfc2616.txt (Oct. 2001)

2. "Hypertext Transfer Protocol - HTTP/1.0." May 1996. URL:http://www.ietf.org/rfc/rfc1945.txt (Oct. 2001)

3. "Hypertext Transfer Protocol - HTTP/1.1." January 1997. URL:http://www.ietf.org/rfc/rfc2068.txt (Oct. 2001)

4. Ross, Keith. "The Hypertext Transfer Protocol." 1997. URL:http://www.seas.upenn.edu/~tcom500/application/http.htm (Oct 2001)

5. Nielsen, Henrik. "Hypertext Transfer Protocol Version 1.x." September 2001. URL: http://www.w3.org/Protocols/HTTP/ (Oct 2001)

6. Marshall, James. "HTTP Made Real Easy." August 1997. URL:http://jmarshall.com/easy/http/#whatis (Oct 2001)

7. eEye Digital Security. "All versions of Microsoft Internet Information Services Remote buffer overflow (SYSTEM Level Access)" June 18, 2001. URL: http://www.eeye.com/html/Research/Advisories/AD20010618.html (Oct 2001)

8. "Common Vulnerabilities and Exposures CAN-2001-0500" June 2001. URL: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0500(Oct 2001)

9. "CERT® Advisory CA-2001-13 Buffer Overflow In IIS Indexing Service DLL" June 2001. URL: http://www.cert.org/advisories/CA-2001-13.html (Oct 2001)

10. "Unchecked Buffer in Index Server ISAPI Extension Leads to Web Server Compromise." June 2001. URL:http://www.securiteam.com/windowsntfocus/5FP0B2K4KU.html(Oct 2001)

11. "Microsoft Security Bulletin MS01-033." June 2001. URL:http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-033.asp (Oct 2001)

12. "CERT® Advisory CA-2001-19 "Code Red" Worm Exploiting Buffer Overflow In IIS Indexing Service DLL" August 2001. URL:http://www.cert.org/advisories/CA-2001-19.html (Oct 2001)

13. Permeh, Ryan & Maiffret, Marc "Full analysis of the .ida "Code Red" worm." July 2001. URL: http://www.net-security.org/text/articles/code-red.shtml (Oct 2001)

14. "Code Red Worm Analysis Update." August 2001. URL:http://www.incidents.org/archives/intrusions/msg01307.html (Oct 2001)

15. "Code Red Threat FAQ." August 2001. URL:http://www.incidents.org/react/code_red.php (Oct 2001)

16. "CAIDA Analysis of Code-Red." August 2001. URL:http://www.caida.org/analysis/security/code-red/ (Oct 2001)

17. Maiffret, Marc. "Tech Alert: .ida 'Code Red' Worm Targets IIS Servers." July 2001. URL: http://www.8wire.com/articles/?AID=2192&Page=1 (Oct 2001)

18. "Initial Analysis of the .IDA 'Code Red' Worm" July 2001. URL:http://www.securiteam.com/securitynews/5OP0B204UA.html (Oct 2001)

19. Lemos, Rob. "Virulent worm calls into doubt our ability to protect the Net" July 2001. URL: http://news.cnet.com/news/0-1003-201-6658647-0.html?tag=tp_pr (Oct 2001)

20. "Have you been compromised?" August 2001. URL:http://builder.cnet.com/webbuilding/0-7532-8-6958289-3.html (Oct 2001)

21. Scambray, Joel & McClure, Stuart & Kurtz, George. Hacking Exposed, Second Edition.Berkley: Mcgraw-Hill, 2001.

22. Poulsen, Kevin. "Beware 'Brown Orifice'" August 2000. URL:http://online.securityfocus.com/news/70 (Feb 2002)

23. "CERT® Advisory CA-2002-04 Buffer Overflow in Microsoft Internet Explorer" February 2002. URL: http://www.cert.org/advisories/CA-2002-04.html (Feb 2002)

24. "Windows 2000 IIS 5.0 Remote buffer overflow vulnerability" May 2001 URL:http://www.eeye.com/html/Research/Advisories/AD20010501.html (Oct 2001)

25. "Economic Impacts of Malicious Code Attacks" January 2002. URL: http://www.ximeon.com/lib/economic.html (March 2002)

< Previous Question | Back to Malware FAQ Home | Next Question >