ADVISORY NOTICE ADVISORY NOTICE July 19, 2001 24:00 GMT
| PROBLEM: | The Code Red worm is spreading on the Internet utilizing the .ida (indexing service) vulnerability in the Microsoft Internet Information Server IIS. After infection the worm attacks other systems and does a denial of service attack on www.whitehouse.gov. |
| PLATFORM: | Web servers utilizing the IIS server on Windows NT and Windows 2000 with the index server or indexing service enabled. |
| DAMAGE: | Infected machines will randomly attack other web servers and perform a denial of service attack on www.whitehouse.gov. The home page of infected machines will be defaced. |
| SOLUTION: | Disable the indexing server or apply the patches as recommended in Microsoft Security Bulletin MS01-033 or CIAC Bulletin L-098, Microsoft Index Server ISAPI Extension Buffer Overflow. Reboot the system to eliminate the worm from memory. |
| VULNERABILITY ASSESSMENT: |
The risk is HIGH. The worm is spreading rapidly around the Internet. |
The Code Red Worm has been detected spreading to systems throughout the Internet. From the number of different hosts detected performing attacks, it is apparent that many thousands of systems worldwide are infected by this worm. A disassembly and analysis of this worm was performed by Marc Maiffret of eEye Digital Security and friends. This bulletin is based on that analysis. The complete analysis including an annotated disassembly listing is available at
The worm exploits the Index Server (.ida) buffer overflow vulnerability reported in CIAC Bulletin L-098, Microsoft Index Server ISAPI Extension Buffer Overflow and Microsoft Security Bulletin MS01-033, Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise. The buffer overflow allows the worm to execute code within the IIS server to spread itself, to deface the server's home page, and to run a denial of service attack on www.whitehouse.gov.
The worm arrives at the web server as a Get /default.ida request. That request exploits the .ida vulnerability and starts the worm code executing. The worm code executes only in memory and is not written to disk so no residue of the worm will be found by examining the disk.
The worm first starts 100 worm threads in memory. That is, there are 100 copies of the worm running at the same time. Next, it checks for the existence of c:\notworm. If that file exists, the worm goes dormant. This is apparently to prevent the worm from spreading on the developer's system. Next, the worm gets the current date from the system clock and if the date is before the 20th of the month the worm starts infecting new systems. If the date is between the 20th and 27th of the month the worm starts a denial of service attack on www.whitehouse.gov.
The worm attacks other systems by randomly generating an IP address and then probing that address to see if it can connect to port 80. If it can, it sends a copy of the buffer overflow attack to that machine. The random IP address generator appears to always start with the same random seed so the list of machines attacked by the worm is identical for every copy of the worm. The result is that machines whose IP addresses are low on the list of random IP addresses will be probed over and over again by each thread of the worm in every infected machine, creating an effective denial of service attack. Also, vulnerable systems can be compromised multiple times, resulting in multiple copies of the worm running in them each with 100 separate threads. After each attack, the worm again checks the date and decides to either attack another machine or attack www.whitehouse.gov.
The denial of service attack on www.whitehouse.gov is performed by sending 98,304 (18,000h) packets to the www.whitehouse.gov server. After sending these packets, the worm goes to sleep for 4 1/2 hours and then does it again. All 100 threads of the worm code participate in the denial of service attacks which continue until the system is rebooted. Note that a system can sustain multiple infections so a single system may be responsible for many times the 100 * 98,304 packets every 4 1/2 hours.
The 100th thread of the worm code defaces the web server's home page. It only does this if the operating system's code page is U.S. English. The 100th thread first sleeps for 2 hours, apparently to let the attacking threads to spread the worm before it shows a visible presence by changing the home page. After 2 hours, the worm replaces a link in the executing code in memory that returns data to a web client. That link is then pointed to worm code that produces the web page below, which indicates that the web page was hacked by the Chinese.
The change remains in effect for ten hours and then the web server is returned to normal operation. Note that the change in the home page is not done by changing the home page disk files, but is done by hacking the code in memory that returns data to a user to return the html codes for the defaced web page instead. The result is that the defaced web page is returned to anyone who makes any request to the web server.
As the worm runs only in memory, you will not be able to find a file or other tell-tale evidence on the disk that indicates the worms presence. If the worm is active in a server, the server will show a heavy load and will show a lot of external connections to port 80 on other machines. Execute the following command in a command window to see what external connections a system currently has open.
netstat -a
If you are using an intrusion detection system, it should be able to detect the worm's attacks. The beginning of the worm's attack packet looks like the following:
GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3
This worm is only in memory on a system and is not written to disk, so simply rebooting a system removes the worm and restores the system. However, due to the large number of infected systems and the fact that they attack the same list of IP addresses, the odds are that a system will be reinfected as soon as it reboots. To protect a system you have two options: 1) disable .ida processing or 2) patch the .ida processor. If you are not using the index server, you should disable .ida processing otherwise you must patch your system. After disabling .ida processing or patching a system, be sure to reboot the system to insure that the worm is removed from memory.
See the following bulletins for information on disabling and patching systems for this vulnerability.
Note: You can remotely test a server to see if .ida processing is enabled or not by making a request to the server for an ida file that does not exist. Type the following request in a web browser with your server replacing the one in the request.
if it returns the following text, .ida processing is enabled.
On the other hand, if .ida processing has been disabled, the server will return a 404 file not found error.
Realize that this does not tell you if you have the patched version of the .ida processor only if .ida processing is disabled or not.
CIAC wishes to thank Marc Maiffret of eEye Digital Security and his friends for the hours they spent disassembling and analyzing this worm which provided the information contained in this bulletin.
CIAC services are available to DOE, DOE Contractors, and the NIH. CIAC can be contacted at:
Voice: +1 925-422-8193 (7 x 24)
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@ciac.org
World Wide Web: http://www.ciac.org/
Anonymous FTP: ftp.ciac.org