Bugtraq mailing list archives

CodeRed II ARIS Incident Analysis


From: aleph1 () securityfocus com
Date: Sun, 5 Aug 2001 10:00:43 -0600

Please use the incidents mailing list for any future discussion about
the Code Red II worm. You can subscribe by emailing 
incidents-subscribe () securityfocus com. Messages to the list should be
sent to incidents () securityfocus com. The archives are available in
our web site under Mailing Lists -> Incidents -> Archives.

----- Forwarded message from Ryan Russell <ryan () securityfocus com> -----

From: Ryan Russell <ryan () securityfocus com>
To: <incidents () securityfocus com>
Subject: CodeRed II ARIS Incident Analysis
Date: Sun, 5 Aug 2001 06:45:13 -0600 (MDT)
Message-ID: <Pine.GSO.4.30.0108050638330.19856-100000@mail>

Here is a text version of one of our Incident Analysis Reports from the
ARIS project.  Probably of most interest to this mailing list is the
section down a ways called "technical Details".  Hope you find it useful.

                                Ryan


CodeRedII
DRAFT

Analysts:
Ryan Russell
Guest Analysts:
Marc Maiffret and Ryan Permeh

Incident Analysis Report
August 4, 2001

Executive Summary

A new worm affecting unpatched Microsoft IIS web servers has been
discovered.  This worm takes advantage of the same vulnerability as the
widely publicized Code Red worm.  This worm is not a variant of Code Red,
however, the author has embedded the string "CodeRedII" inside the code.
This would seem to indicate that this worm is in response to, or inspired
by, the original Code Red worm.

This worm has a more malicious payload, a backdoor access method. It
leaves a copy of cmd.exe, named root.exe, in a location accessible to the
web server.  If successful, this will allow any attacker (not just the
worm author) access to the victim web server at a later date.

The fix is to apply the Microsoft patches.  Most companies will have these
in place by now due to Code Red.



Associated Vulnerability: MS Index Server and Indexing Service ISAPI Extension
 Buffer Overflow Vulnerability
Associated Bugtraq ID: 2880
Urgency: High
Ease of Exploit: Automatic
Associated Operating Systems: Windows NT 4.0, Windows 2000

Overview

A new worm, which has been named CodeRed II, has been discovered in the
wild.  This worm has been spreading extremely quickly.  It takes advantage
of the same ISAPI Indexing Service buffer overflow as Code Red.  However,
this worm is a bit more damaging, as it leaves a backdoor on the victim
web server.  Once it has infected a new victim, it spreads out from there,
but it favors the same address space as the current victim.  This turns
out to be a very effective spreading mechanism, and many hosts have been
compromised in a very short period of time.


Patches

* Windows NT 4.0:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30833

* Windows 2000:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30800



Attack Signatures

The original Code Red worm sends the following request during the attack:

/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
HTTP/1.0

The new worm sends a very similar header:

/default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%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

The difference is that it uses X instead of N as its filler character.
The machine code that follows is different between the two.


IDS Updates

By now, all the major IDS vendors have rules to catch the overflow
attempts.  In addition, some of the IDS' are spotting the string "cmd.exe"
in the exploit code, and alarming on that.  SecurityFocus recommends that
you update to the latest ruleset available for your IDS as soon as
possible.  Even if you are not affected by the attempts, there are efforts
underway to notify other Internet users that appear to be infected.


Recommendations

SecurityFocus recommends that you apply the patch immediately. In
addition, SecurityFocus analysts recommend that you implement as much of
the following hardening/checklist document as possible:

* IIS4:
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/columns/questions/iischeck.asp

* IIS5:
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/iis/deploy/depovg/securiis.asp

There is also an IIS5 Hotfix Checking Tool to check for patches that
haven't been installed. You can get it from Microsoft Technet at:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=24168



Attack Data


Figure 1 - ISAPI Overflows and cmd.exe requests August 3 - 5
http://www.securityfocus.com/data/staff/crii-attempts.pdf



Figure 2 - Top attacking countries for ISAPI Overflows and cmd.exe
requests August 3 - 5
http://www.securityfocus.com/data/staff/crii-countries.pdf


The trailing off of the graphs is a result of that being the most recent
data at the time, and is not indicative of the worm slowing down.

Note that the cmd.exe attacks have a very sharp growth rate, while the
actual overflow attacks remain relatively flat.  The cmd.exe attacks are
new with this worm (they didn't appear with Code Red), while Code Red
tends to mask the activity of the new worm at present.

The new worm doesn't favor a particular language version of Windows 2000
for attack.  In fact, it attacks all language versions, and if it finds it
is running on a Chinese version of Windows, it spawns twice as many
threads.

Technical Description

This technical description is based on an analysis and disassembly
performed by Marc Maiffret and Ryan Permeh of eEye Digital Security. Their
full analysis and disassembly can be found at the following location:

http://www.eeye.com/html/advisories/coderedII.zip

The worm has three sections: The infection mechanism, the propagation
mechanism, and trojan component.

When the worm successfully installs itself on a new victim, it goes
through a number of initialization steps:

* Obtains the current victim's IP address (used in propagation step, see below)
* Checks to see if the system language is Chinese (Taiwanese or PRC)
* Checks for previous execution, if so then it jumps to propagation
* Checks to see if the "CodeRedII" atom has been set, if so then sleep
 forever (kills new arrivals of same worm)
* Adds the "CodeRedII" atom (if previous check failed)
* Sets the number of worker threads to 300, or if it is a Chinese system, 600.
* Spawns a thread back at the first step, which will then jump to propagation,
 since that will no longer be the first execution
* Calls the trojan functions
* Sleeps for 1 day on non-Chinese system, 2 on Chinese
* Reboots the system (which will remove any memory resident worms, leaving
 only the backdoors and explorer.exe trojan)

The propagation mechanism is the most novel aspect of this particular
worm.  Here are the steps performed:

* Check local time.  If it is less than the year 2002 and is also less than
 the 10th month, then continue.  Otherwise, reboot.  This should limit the
 worm to the end of September, 2001 if it lives that long.
* Sets up the sockets needed to connect to other potential victims.  Uses
 non-blocking sockets, which gives a performance advantage.
* If it gets a connect, it sends a copy of itself (so far, all copies are
 identical, no self-modifying code)
* Repeat

The most interesting piece is how it selects a new victim IP address to
try.  The worm generates 4 octets in the range 1 through 254, to avoid IP
addresses with a 0 or 255.  It takes one of these bytes, and binary ANDs
it with 7, yielding a random number between 0 and 7.  It then consults a
table:

dd 0FFFFFFFFh           ; 0 - addr masks
dd 0FFFFFF00h           ; 1
dd 0FFFFFF00h           ; 2
dd 0FFFFFF00h           ; 3
dd 0FFFFFF00h           ; 4
dd 0FFFF0000h           ; 5
dd 0FFFF0000h           ; 6
dd 0FFFF0000h           ; 7

which determines how much of the randomly generated IP address will be
used versus the original address.  For example, if it generates a 5, then
half will be random, and half will be the old IP address.  If the current
victim IP address is 192.168.1.1, the new one to try might be
192.168.45.67 (byte order is reversed in the machine code.)

This has the result that 3 times out of 8, it stays within the equivalent
of a Class B of the attacker, 4 times out of 8, it stays within a Class A
equivalent, and 1 time out of 8, it goes after a completely random IP
address.

For the most part, the Internet address space is a sparse matrix.  Many of
the possible (and assigned) addresses are not reachable from the Internet.
Still others have been delegated to a particular ISP or geographic region,
but are not yet in use by actual customers.  The result is that actual
hosts tend to be bunched together in numerically-related netblocks.  The
CodeRed II worm favors nearby IP addresses which tend to have similar host
types (i.e. Windows), so it is exhibiting a much higher rate of growth
than previous worms.  This also means that if it finds its way onto an
RFC1918 network, it would likely be much more damaging to that network
than previous worms.

It should also be noted that the worm takes measures to avoid 127.x.x.x
and 224.x.x.x.

Finally, during the trojan step is when the backdoors are installed.
This portion has the following steps:

* Gets the system directory (usually c:\winnt\system32)
* Appends cmd.exe to the string
* Copies the resulting string (usually c:\winnt\system32\cmd.exe) to c:\inetpub\scripts\root.exe and 
c:\progra~1\common~1\system\MSADC\root.exe
* Creates c:\explorer.exe
* Goes back and repeats the steps for drive d: instead of c:

The trojan explorer.exe doesn't get executed until the next time the host
is rebooted and someone logs in.  When it is run, it executes the real
explorer, and then does the following in an infinite loop:

* Sets SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SFCDisable to 0FFFFFF9Dh (disables system file protection)
* Sets SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\Scripts to ,,217
* Sets SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\msadc to ,,217
* Sets SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\c to c:\,,217
* Sets SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\d to d:\,,217
* Sleeps for 10 minutes

The Virtual Roots ensure that the scripts and msadc directories stay
mapped, and maps a c and d virtual root which don't normally exist.
These are mapped to the drive roots, which will allow an attacker yet
another way into the victim web server remotely.  Even if the root.exe
files are removed and the overflow patched, if explorer.exe is running, an
attacker can execute the original cmd.exe, or any other executable, with a
command similar to the following:

http://IpAddress/c/winnt/system32/cmd.exe?/c+dir


File Names

The worm itself is memory-resident only.  However, it may leave behind
files named root.exe, in the script and msadc directories under the IIS
webroot.  These should of course be deleted, as they are copies of
cmd.exe, and will permit remote access to your web server.  In addition, a
file named explorer.exe will be created in the root of c: and d: if it
exists.  This needs to be removed, and the host rebooted.

Resources

Securing IIS:
http://securityfocus.com/focus/microsoft/iis/iissecure.html

Free Code Red scanner from eEye:
http://www.eeye.com/html/Research/Tools/index.html

Community Credits

SecurityFocus wishes to thank the many Internet users who have provided us
with logs during the Code Red process, as well as now CodeRed II.  This
has enabled us to notify many Code Red victims, who were then able to
clean up their affected hosts.  We also wish to thank the many ISPs and
other providers who had to search through their logs to track down who had
the dynamic IP address at that time, and notify them that they were
infected.




----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com

----- End forwarded message -----

-- 
Elias Levy
SecurityFocus.com
http://www.securityfocus.com/
Si vis pacem, para bellum


Current thread: