__________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Center
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________
ADVISORY NOTICE
The Code Red Worm
July 19, 2001 24:00 GMT Number L-117
______________________________________________________________________________
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 The risk is HIGH. The worm is spreading rapidly around the
ASSESSMENT: Internet.
______________________________________________________________________________
[Update to L-120 on July 29, 2001 with additional tool information]
A tool has been released for the detection of the Code Red Worm.
You may download this tool from the following location:
http://www.eeye.com/html/Research/Tools/codered.html
The Code Red Worm
=================
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
http://www.eeye.com/html/advisories/codered.zip
Worm Operation
==============
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.
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=english">
<title>HELLO!</title>
</head>
<bady><hr size=5><font color="red">
<p align="center">Welcome to http://www.worm.com !<br>
<br>
Hacked By Chinese!</font></hr>
</bady>
</html>
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.
Detecting the Worm
==================
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
Removing the Worm and Patching a System
=======================================
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.
CIAC Bulletin L-098, Microsoft Index Server ISAPI Extension Buffer
Overflow
Microsoft Security Bulletin MS01-033, Unchecked Buffer in Index
Server ISAPI Extension Could Enable Web Server Compromise
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.
http://www.yourwebserver.gov/default.ida
if it returns the following text, .ida processing is enabled.
The IDQ file default.ida could not be found.
On the other hand, if .ida processing has been disabled, the server
will return a 404 file not found error.
HTTP Error 404
404 Not Found
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, the Computer Incident Advisory Center, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.
CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
Voice: +1 925-422-8193 (7x24)
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@ciac.org
Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.
World Wide Web: http://www.ciac.org/
Anonymous FTP: ftp.ciac.org
PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins. If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.
This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.
LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)
L-108: Oracle 8i TNS Listener Vulnerability
L-110: HP Open View Event Correlation Services Vulnerability
L-111: FreeBSD Signal Handling Flaw
l-109: VPN-1/FireWall-1 RDP Communication Vulnerability
L-112: Cisco SN 5420 Storage Routers Vulnerabilities
L-113: Microsoft Outlook View Control Exposes Unsafe Functionality
L-115: Hewlett-Packard login Vulnerability
L-116: Lightweight Directory Access Protocol (LDAP) Vulnerabilities
L-118: Hewlett-Packard ftpd and ftp Vulnerability
L-119: Hewlett-Packard mkacct Program Vulnerability
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
