COMMAND
CodeRed worm
SYSTEMS AFFECTED
Those with IIS unpatched
PROBLEM
There are many reports of a new worm going around which purports
to abuse the vulnerability discussed in MS01-033, a buffer
overflow in Microsoft Index Server. Some reports have it causing
web services (http/ftp/smtp) to stop and restart, while others
state there's a defacement and then the "worm" launches from the
afflicted IIS machine and out in search of other vulnerable IIS
boxes.
The signature:
/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a
is likely to be found in your IIS logs or IDS systems. You can
also run a NETSTAT on the box and look for:
216.99.52.100
in the list of sites connected to by your system.
Remember, this worm cares not whether the box its attacking is an
IIS box or a router. Reports on SecurityFocus' Bugtraq mailing
list indicate that some routers are experiencing problems when
sent the worm attack string.
Further, reports Russ Cooper have received as well as some
personal experience with infected machines (not mine) suggests
that the worm may not be effective against IIS 4.0 boxes.
Instead, when the URL is received the web services stop. Its
reasonable to assume that the very small shellcode it uses might
not work properly across all vulnerable platforms. So if you are
experiencing web services stopping repeatedly, its likely because
of the worm.
The following Cisco products are vulnerable because they run
affected versions of Microsoft IIS:
* Cisco CallManager
* Cisco Unity Server
* Cisco uOne
* Cisco ICS7750
* Cisco Building Broadband Service Manager
Other Cisco products may also be adversely affected by the "Code
Red" worm.
Other Cisco products may be indirectly affected by the IIS
vulnerability (this is not an exhaustive list):
* Cisco 600 series of DSL routers that have not been patched per
the Cisco Security Advisory,
http://www.cisco.com/warp/public/707/CBOS-multiple.shtml
will stop forwarding traffic when scanned by a system infected
by the "Code Red" worm. The power must be cycled to restore
normal service.
* Cisco Network Management products are not directly affected but
might be installed on a Microsoft platform running a vulnerable
version of IIS.
The "Code Red" worm exploits a known vulnerability in Microsoft
IIS by passing a specially crafted URI to the default HTTP
service, port 80, on a susceptible system. The URI consists of
binary instructions which cause the infected host to either begin
scanning other random IP addresses and pass the infection on to
any other vulnerable systems it finds, or launch a denial of
service attack targeted at the IP address 198.137.240.91 which
until very recently was assigned to www.whitehouse.gov. In both
cases the worm replaces the web server's default web page with a
defaced page at the time of initial infection.
The worm does not check for pre-existing infection, so that any
given system may be executing as many copies of the worm as have
scanned it, with a compounding effect on system and network
demand.
As a side-effect, the URI used by the worm to infect other hosts
causes Cisco 600 series DSL routers to stop forwarding traffic by
triggering a previously-published vulnerability. Any 600 series
routers scanned by the "Code Red" worm will not resume normal
service until the power to the router has been cycled.
The nature of the "Code Red" worm's scan of random IP addresses
and the resulting sharp increase in network traffic can noticeably
affect Cisco Content Service Switches and Cisco routers running
IOS, depending on the device and its configuration. Unusually
high CPU utilization and memory starvation may occur.
Marc Maiffret from eEye provided following is a detailed analysis
of the "Code Red" .ida worm that was reported on July 17th 2001.
This analysis was performed by Ryan Permeh and Marc Maiffret. The
disassembly (complete with comments) was done by Ryan "Shellcode
Ninja" Permeh.
On Friday July 13th eEye received packet logs and information from
2 network administrators that were experiencing large amounts of
attacks targeting the recent .ida vulnerability that eEye Digital
Security discovered on June 18, 2001. After reviewing the logs
sent to them they determined that in fact someone had released a
worm into the Internet that was spreading rapidly through IIS web
servers.
The full analysis of the .ida "Code Red" worm has provided
numerous new details as to the functionality and method of
propagation of this worm. For instance this worms purpose
ultimately seems to be to perform a denial of service attack
against www.whitehouse.gov. Also it has been found that only US
English Windows NT/2000 systems will show the defaced ("Hacked by
Chinese !") web page.
As stated earlier the .ida "Code Red" worm is spreading throughout
IIS web servers on the Internet via the .ida buffer overflow
attack that was published weeks ago. The following are the steps
that the worm takes once it has infected a vulnerable web server.
1. Setup initial worm environment on infected system.
2. Setup a 100 threads of the worm
3. The first 99 threads are used to spread the worm (infect other
web servers).
The worm spreads itself by creating a sequence of random IP
addresses. However, the worm's randomization of IP addresses
to attack is not all together random. In fact there seems to
be a static seed that the worm uses when generating new IP
addresses to try to attack. Therefore every computer infected
by this worm is going to go through the same list of random IP
addresses to try to infect. The "problem" with that is that
the worm is going to end up reinfecting systems and also end
up crossing traffic back and forth between hosts to end up
creating a denial of service type affect because of the amount
of data that will be transferred between all the IP addresses
in the sequence of random IP addresses. The worm could have
done truly random IP generation and that would have allowed it
to infect a lot more systems a lot faster. We are not sure
why that was not done but a friend of ours did pose an
interesting idea... If the person who wrote this worm owned an
IP address that was one of the first hundred or thousand etc...
to be scanned then they could setup a sniffer and anytime and
IP address tried to connect to port 80 on their IP address
they would know that the IP address that connected to them was
infected with the worm and they would therefore be able to
create a list of the majority of systems that were infected by
this worm.
4. The 100th thread checks to see if it is running on a English
(US) Windows NT/2000 system.
If the infected system is found to be a English (US) system
then the worm will proceed to deface the infected systems
website. That means... the local web servers web page will be
changed to a message that says Welcome to http://www.worm.com!,
Hacked By Chinese!. This hacked web page message will stay
"live" on the web server for 10 hours and then disappear and
never appear again unless the infected system is re-infected
by another host.
If the system is not a English (US) Windows NT/2000 system then
the 100th worm thread is also used to infect other systems.
5. Each worm thread checks for c:\notworm
-If the file c:\notworm is found, the worm goes dormant.
-If the file is not found then each thread will continue to
attempt to infect more systems.
6. Each worm thread will now check the infected computers time.
If the time is between 20:00 UTC and 23:59 UTC then the worm
will proceed to use this thread to attack www.whitehouse.gov.
The attack consists of the infected system sending 100k bytes
of data to port 80 of www.whitehouse.gov therefore potentially
performing a denial of service attack against
www.whitehouse.gov.
If the time is below 20:00 UTC then this worm thread will try
to find and infect new web servers.
In testing eEye have calculated that the worm can attempt to
infect roughly half a million IP addresses a day and that was a
ruff estimate made from using a very slow network.
As of writing this document (July 18 6:49pm) eEye have had reports
from administrators that have been probed by over 12 thousand
unique hosts. That basically means at least 12 thousand hosts
have been infected by this worm.
In testing eEye have seen that sometimes the worm does not
execute correctly and will continue to spawn new threads until
the infected machine crashes and has to be rebooted.
The following is a very detailed analysis of what the worm is
doing at each step of its infection. Full disassembled and
commented worm code is available at eEye website at:
http://www.eeye.com/html/advisories/codered.zip
1. Initial infection vector (i.e. host is vulnerable to the .ida
attack and gets hit with this worm).
The initial infection starts to take place when a web server,
vulnerable to the .ida attack, is hit with a HTTP get request
that contains the necessary code to exploit the .ida attack
and uses this worm as its payload.
At the time of the .ida overflow a systems stack memory will
look like the following:
<MORE 4E 00>
4E 00 4E 00 4E 00 4E 00
4E 00 4E 00 4E 00 4E 00
4E 00 4E 00 4E 00 4E 00
92 90 58 68 4E 00 4E 00
4E 00 4E 00 4E 00 4E 00
FA 00 00 00 90 90 58 68
D3 CB 01 78 90 90 58 68
D3 CB 01 78 90 90 58 68
D3 CB 01 78 90 90 90 90
90 81 C3 00 03 00 00 8B
1B 53 FF 53 78
EIP is overwritten with 0x7801CBD3 which an address within
msvcrt.dll. The code at 0x7801CBD3 disassembles to:
call ebx
When EIP is overwritten with call ebx it then causes program
flow to divert back to the stack. The code on the stack jumps
into the worm code that's held in the body of the initial HTTP
request.
2. Sets up some initial stack variables
CODEREF: seg000:000001D6 WORM
At this point we are executing the initial code of the worm.
The first thing to happen is that the worm sets up a new stack
for its own use. The new stack is 218h bytes, filled with CCh.
The worm code then moves on to initialize its function jump
table.
The entire worm heavily uses an EBP stack based memory offset
system. This means that all variables are referenced as EBP-X
values. On our website we have a document called worm-ebp.txt
that attempts to track stack usage throughout the course of
the worm code.
3. Load functions (create the "jump table")
CODEREF: seg000:00000203 DataSetup
The first thing the worm code does is reference the data
portion of the exploit code at EBP-198h. The worm then needs
to setup its internal function jump table. A function jump
table is a stack based table used to store function addresses.
It allows the worm to generate the function addresses at run
time (This makes the worm have a better chance of executing
cleanly on more systems).
The technique used by this worm is what is called an RVA
(Relative Virtual Addresses) lookup. Basically this means
that all functions, or specifically GetProcAddress, are found
within IIS itself. For more details on RVA please consult any
good PE (Portable Executable, the executable file format for
Microsoft platforms) documentation, or read through the
assembly code of this worm.
In a nutshell, RVA techniques are used to get the address of
GetProcAddress. GetProcAddress is then used to get the
address of LoadLibraryA. Between these two functions all
other functions that the worm may need can be easily found.
The worm uses these two functions to load the following
functions:
>From kernel32.dll:
GetSystemTime
CreateThread
CreateFileA
Sleep
GetSystemDefaultLangID
VirtualProtect
>From infocomm.dll:
TcpSockSend
>From WS2_32.dll:
socket
connect
send
recv
closesocket
Finally the worm stores the base address of w3svc.dll which it
will later use to potentially deface the infected website.
4. Check the number of threads the worm has created.
CODEREF: seg000:00000512 FUNC_LOAD_DONE
Here the worm seems to perform a WriteClient (Part of the
ISAPI Extension API), sending "GET" back to the attacking worm.
This possibly could be a way of telling attacking worms that
they have successfully infected a new host.
Next the worm code will count the number of worm threads
already in action. If the number of threads is 100 then
control is shifted to the Worm hack web page functionality.
If the number of threads is below 100 then the worm creates a
new thread. Each new thread is an exact replica of the worm
(Using the same code base).
The worm now continues its path of execution.
6. Checks for the existence of c:\notworm
CODEREF: seg000:0000079D DO_THE_WORK
There seems to be a to be built in "lysine deficiency" (See
Jurassic Park, or Caesar's paper on this at www.rootkit.com).
A "lysine deficiency" is a built in check to keep malicious
code from spreading further.
In this case the "lysine deficiency" is a check for the
existence of the file c:\notworm. If this file exists then
the worm will become dormant. This means it will not attempt
to make connections out to other IP addresses to try to infect.
If this file does not exist then the worm continues onto the
next step.
7. Check the infected systems time (computer clock)
CODEREF: seg000:00000803 NOTWORM_NO
The worm will now check the infected systems local time (in
UTC). If the hour is greater then 20:00 UTC then the worm
will proceed to goto the first step of the attack
www.whitehouse.gov functionality.
If the time is less than 20:00 UTC then the worm will attempt
to continue to try to infect new systems.
8. Infect a new host (send .ida worm to a "random" IP address on
port 80).
At this point the worm will resend itself to any IP addresses
which it can connect to port 80 on. It uses multiple send()'s
so packet traffic may be broken up. On a successful
completion of send, it closes the socket and goes to step 6...
therefore repeating this loop infinitely.
Worm hack webpage functionality is called after a hundred threads
are spawned within the worm.
1. Check if local system default language is English us then goto
step 6 of core worm functionality.
CODEREF: seg000:000005FE TOO_MANY_THREADS
The first thing the worm does is get the local codepage. A
codepage specifies the local operating system language (I.E.
English (US), Chinese, German etc...). It then compares the
local codepage against 0x409. 0x409 is the codepage for
English (US) systems. If the infected system is an English
(US) system then the worm will proceed to deface the local
systems webpage. If the local codepage is not English (US)
then this worm thread will goto step 6 of core worm
functionality.
2. Sleep for 2 hours.
CODEREF: seg000:00000636 IS_AMERICAN
This worm thread now sleeps for 2 hours. We anticipate that
this is to allow the other worm threads to attempt to spread
the infection before making a presence known via defacing the
infected systems webpage.
3. Attempt to modify infected systems webpages in memory.
CODEREF: seg000:0000064F HACK_PAGE
This worm uses an interesting technique called "hooking" to
effectively deface (alter) an infected systems webpages.
Hooking is modifying code in memory to point to code that the
worm provides. In this case the worm is modifying w3svc.dll
to change the normal operation of a function called
TcpSockSend. TcpSockSend is what w3svc.dll (IIS core engine)
uses to send information back to the client. By modifying
this, the worm is able to change data being written back to
clients who request web pages of an infected server.
To perform hooking, first the worm makes the first 4000h bytes
of w3svc.dll's memory writable. In a normal situation the
memory for w3svc.dll (and basically all mapped dll's) is
read-only. It uses the function VirtualProtect to change the
memory of w3svc.dll to be writable, saving the old state to a
stack variable.
It then uses the saved codebase of w3svc.dll (from step 3 of
core worm functionality) as a start point to search the import
table (again see PE header documentation) for the address of
TcpSockSend. Once the address for TcpSockSend is located the
worm then replaces TcpSockSend's actual address with an
address within the worm.
The address that TcpSockSend now points to is a function within
the worm that will return the "Hacked by Chinese !" webpage.
The CODEREF for this function is seg000:00000C9A
FAKE_TCPSOCKSEND.
This thread of the worm now sleeps for 10 hours. During this 10
hours all web requests to the infected server will return the
"Hacked by chinese !" webpage.
After the 10 hours is up this thread will return w3svc.dll to
its original state, including re-protecting memory.
Execution after this proceeds to step 6 of the core worm
functionality.
Sooner or later every thread within the worm seems to shift its
attacking focus to www.whitehouse.gov.
1. create socket and connect to www.whitehouse.gov on port 80 and
send 100k byes of data
CODEREF: seg000:000008AD WHITEHOUSE_SOCKET_SETUP
Initially the worm will create a socket and connect to
198.137.240.91 (www.whitehouse.gov/www1.whitehouse.gov) on
port 80.
CODEREF: seg000:0000092F WHITEHOUSE_SOCKET_SEND
If this connection is made then the worm will create a loop that
performs 18000h single byte send()'s to www.whitehouse.gov.
CODEREF: seg000:00000972 WHITEHOUSE_SLEEP_LOOP
After 18000h send()'s the worm will sleep for about 4 and a half
hours. It will then repeat the attack against www.whitehouse.gov
(goto step one of Attack www.whitehouse.gov functionality).
It looks like there's two sets of worms out there. One is
scanning large contiguous netblocks in an obvious fashion, the
other is hunting and pecking about random IP addresses.
In following text, we will be refering to the original "Code Red"
worm as CRv1 and the second generation "Code Red" worm as CRv2.
This does not preclude further generations/varioations still in
the wild, it is just an analysis of the worms we have access to.
This information is not currently public. Well, sort of is (eEye
published the disassembly of CRv1, so CRv1 targeting info may be
known), but the existance of CRv2 with different targeting has
not been verified until now as far as we know.
The CRv2 worm has the following charecteristics: second:milisecond
randomness added to ip selection process removal of web page hack
display (no notice to the end users via a defaced page).
All other parts of the worm are the same. (still attacks
whitehouse.gov (but the IP address has been blackholed), has time
limits/definitions of attack, notworm lysine).
The worst part about this means that our original tracking
methodology (sensors early in the sequence) is no longer
accurate, since CRv2 infected hosts do not contact early hosts,
nor reliably contact any point (other than the blackholed IP
address that use to point to whitehouse.gov). This means that
potentially ALL(ie: global, coprehensive) ids/logs data must be
organized and sorted to find infected hosts.
It has 13 or so pertient bytes changed, adding a time based
randomness factor and disabling page defacement. The code had
been there all along. It had intentially (we must assume) been
disabled in CRv1, then reenabled near the end of the cycle.
There has been discussion that this was a natural progression of
the worm code, however, we do not beleive this is the case. From
analsysis of CRv1, there seems to be no distinct way to shift the
nessecary bytes to generate CRv2. Hence, it is guess that this is
a modified worm, rereleased. It has been posited that the CRv1
was a target aqusition mechanism, gathering data on infectable
hosts to gain a high initital base for the following CRv2
infection.
The second difference between CRv1 and CRv2 is that CRv2 does not
deface the webpage of an infected system. It does this by having
12 bytes different from CRv1.
When TcpSockSend is hooked(this still happens), CRv2 points this
to a basic redirect that performs harmless actions and returns
without actually changing any content. Crv1 pointed to a
replacement, CRv2 points to basically a donothing function.
What is happeinging is that the label "PADDING_BYTES" actually is
padding bytes in CRv1(the code does not disassemble to any sane
code).
CRv2 fufills numerous questions that we had noticed in early
analysis of CRv1, such as the nessecity of the self modifying
code in CRv1. Although CRv1 did modify it's own code, it didn't
ever really touch the modified code, CRv2 makes use of this
feature to implement the bypass.
Both worm have a timeline like this (day of the month):
1-19: infect other hosts using the worm
20-27: attack whitehouse.gov forever
28-end of month: eternal sleep
To download CodeRed Scanner go to:
http://www.eeye.com/html/Research/Tools/codered.html
This worm is killing JetDirect cards. The HP JetDirect Card on
HP LaserJet 4000N will steadily crash as infection attempts hit
it; the result is that, every ten to thirty minutes or so, the
printer itself crashes, dumping a page of exception data from the
card and freezing with an "EIO 2 ERROR" message. A hard reset of
the printer is required to make it operational again.
Similar printer problems are seen with Xerox Docuprint N32
printers. It appears to be yet another example of a badly-written
embedded web server.
3Com lanmodems, single channel are affected by this as well.
Remember, each host can be infected multiple times, meaning that
a single host can send 410MB * # of infections.
The CAIDA folks have posted an extensive analysis of the spread
of the code.red worm. These are the same folks that brought you
the "backscatter" analysis of world-wide DOS attacks. The
infection rate was astounding, they have IP addresses for 375,000
infected hosts, which is a *lower* bound on the infection. There
are graphs that show the change in infection rate when CRv2 was
released, as well some amazing animations. At one point the
infection rate was at least 2000 hosts per minute.
http://www.caida.org/analysis/security/code-red/
SOLUTION
Do make sure you have patched your systems:
iis103.htm
iis104.htm
Cisco is providing the same patch at
http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=cisco/voice/callmgr/win-IIS-SecurityUpdate-2.exe&swtype=FCS&code=&size=246296
with documentation at
http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=cisco/voice/callmgr/win-IIS-SecurityUpdate-Readme-2.htm&swtype=FCS&code=&size=4541
Cisco Building Broadband Service Manager is documented separately
at
http://www.cisco.com/univercd/cc/td/doc/product/aggr/bbsm/bbsm50/urgent.htm
The most effective way of stopping the worm instantly is to remove
the mappings for .ida and rebooting the box. I'm working on a
scriptable way to remove the mappings (help would be appreciated).
MetaEdit isn't runnable from a command line, so some other method
is required to modify the Metabase.
Placing the C:\NOTWORM file (any file called NOTWORM should do)
will stop the worm processing, but this won't prevent your
machine from stopping the web services or being infected by other
worm attacks.
Applying the MS01-033 patch is equally important because the .ida
and .idq mappings may be re-instated if you add or remove
programs associated with IIS.
If you think you have the patch applied, re-apply it and reboot at
the first opportunity, just to be sure. You can also double-check
the details of IDQ.DLL to ensure its 5.0.2195.3645 or above on
W2K, 5.0.1781.3 on NT 4.0. Whatever you do don't rely on anything
that simply looks in the \WINNT directory for an uninstall
directory or the registry, neither of these methods provide
complete assurance the right version is in place.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2025 AOH
