Code Red II summary and analysis issued by SANS Incidents.org
The new worm that was first identified and reported on Saturday has now been analyzed. Here is a summary of the facts issued by www.incidents.org (SANS) based on the excellent analyses referenced at the bottom of this report
EXPLOITED VULNERABILITY
------------------------
This worm uses the same mechanim as the original Code Red worm to infect vulnerable servers. That is, the worm looks for IIS servers that have not patched the unchecked buffer vulnerability in idq.dll or removed the ISAPI script mappings. See the Code Red Patch FAQ at http://www.incidents.org/react/code_red.php for information on patching systems to remove the vulnerability.
Except for using the buffer overflow mechanism in order to get the worm code executed on a vulnerable IIS server, this new worm is entirely different from the original Code Red CRv1 and CRv2 variants.
Note: According to eEye, the worm code will be successfully executed only on a Win2000 system running a vulnerable IIS server, WinNT-based IIS servers will simply crash when attempting to execute the worm code. Our experiments and reports received from users confirm this finding...
Code Red II Worm Analysis Update
=================================
The new worm that was first noticed yesterday has been
analyzed. Here is a summary of the facts based on the
excellent analyses referenced at the bottom of this page.
EXPLOITED VULNERABILITY
------------------------
This worm uses the same mechanim as the original Code
Red worm to infect vulnerable servers. That is, the
worm looks for IIS servers that have not patched the
unchecked buffer vulnerability in idq.dll or removed
the ISAPI script mappings. See the Code Red Patch FAQ
at
http://www.incidents.org/react/code_red.php for
information on patching systems to remove the vulnerability.
Except for using the buffer overflow mechanism in order
to get the worm code executed on a vulnerable IIS server,
this new worm is entirely different from the original Code
Red CRv1 and CRv2 variants.
Note: According to eEye, the worm code will be successfully
executed only on a Win2000 system running a vulnerable IIS
server, WinNT-based IIS servers will simply crash when
attempting to execute the worm code. Our experiments and
reports received from users confirm this finding.
BACKDOOR
--------
The most damaging property of this new worm is that the worm
creates a back door on an infected server, leaving the system
wide open to any attacker.
The worm copies %windir%CMD.EXE to the following locations:
c:inetpubscripts
oot.exe
c:progra~1common~1systemMSADC
oot.exe
d:inetpubscripts
oot.exe
d:progra~1common~1systemMSADC
oot.exe
This provides a means for a remote attacker to execute
arbitrary commands on the compromised server.
In addition, the worm creates a trojan copy of explorer.exe
as described below. Due to the actions of the trojan
explorer.exe, IIS will make the C: and D: root directories
accessible to a remote attacker even if the root.exe
command shell program is removed from the scripts and
msadc directories.
TROJAN EXPLORER.EXE
--------------------
The worm carries its own copy of explorer.exe. The worm
places its own copy of explorer.exe at c:explorer.exe
and d:explorer.exe. By placing the trojan file in these
locations, Windows will find and run the trojan rather
than the real explorer.exe because of the way Windows
seaches for executables by default. Specifically, unless
the system has been patched against the "Relative Shell
Path" vulnerability, the trojan explorer.exe will be
executed when the next user logs into the system.
(See http://www.microsoft.com/technet/security/bulletin/MS00-052.asp)
Upon execution, the trojan first runs the real explorer.exe
(thus the user will not notice any problems) and then goes
on to modify the system registry as outlined below.
First, the trojan program adds the value SFCDisable=0xFFFFFF9D
to HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionWinlogin.
This registry setting completely disables the Windows File
Protection (WFP) mechanism. WFP prevents the replacement of
certain monitored system files. See the following for more info:
http://support.microsoft.com/support/kb/articles/Q222/1/93.ASP
Next, the trojan sets the following "Virtual Roots" in the registry:
SYSTEMCurrentControlSetServicesW3SVCParametersVirtual Rootsscripts to ,,217
SYSTEMCurrentControlSetServicesW3SVCParametersVirtual Rootsmsadc to ,,217
These "217" settings ensure that the scripts and msadc directories
(which contain the root.exe copy of cmd.exe) have read/write/execute
permission.
Finally the trojan sets these two "Virtual Root" values as well:
SYSTEMCurrentControlSetServicesW3SVCParametersVirtual Rootsc to c:,,217
SYSTEMCurrentControlSetServicesW3SVCParametersVirtual Rootsd to d:,,217
These mappings, which do not normally exist, map the root C: and D:
drives to a place where IIS can find them, namely /c and /d. The
permissions here are also set to read/write/execute.
Quoting eEye's analysis, the purpose of these mappings are described:
--------
Basically the above code creates a virtual web path (/c and /d) which maps
/c to c: and /d to d:. The writer of this worm has put in this
functionality to allow for a backdoor to be placed on the system so even if
you remove the root.exe (cmd.exe prompt) from your /scripts folder an
attacker can still use the /c and /d virtual roots to compromise your
system. The attacks would basically look like:
http://IpAddress/c/inetpub/scripts/root.exe?/c+dir (if root.exe was still
there) or:
http://IpAddress/c/winnt/system32/cmd.exe?/c+dir (Where dir could be any
command an attacker would want to execute).
----------
Note that the trojan explorer.exe need only be executed once for
these registry changes to be made. Once the "Virtual Root"
registry settings are in place, and the IIS server is restarted,
the backdoors become enabled. Further, the backdoors will
remain enabled, forever after, regardless of whether or not
explorer.exe is running.
To emphasize, note that even killing the trojan explorer.exe process
will not remove the back doors. Further, even killing the explorer.exe
process and removing the copies of root.exe and deleting the registry
settings will not eliminate the backdoors. If the trojan explorer.exe
is executed again (e.g. when the next person logs in), the registry
settings will be reinstated, making the C: and D: drives again
externally accessible following an IIS server restart. (See
See http://www.avdf.com/jan98/art_ot001.html for more information
on creating Virtual Roots under IIS.)
Finally, note that even deleting the registry settings, removing the
copies of root.exe, and removing the trojan explorer.exe is not sufficient
to clean the system. During the time the system was backdoored any other
attacker could have installed new backdoors that are not associated
with this worm and would not be found.
The trojan process sleeps most of the time, but wakes
to loop through these registry key modification steps every
10 minutes. This way, even if an administrator notices the
registry settings and deletes them, the trojan will reinstate
the settings a few minutes later.
PROPAGATION
-----------
How aggressively the worm attempts to propagate itself
depends on whether or not Chinese is the language installed on
the system. If Chinese, the worm creates 600 threads and
attempts to spread for 48 hours. If non-Chinese, the worm
creates 300 threads and attempts to spread for 24 hours.
After the infection-spreading interval, the system is
forcibly rebooted. The reboot flushes the memory resident worm,
and leaves the backdoors and the explorer.exe trojan in
place.
TARGET SELECTION
-----------------
The 300 or 600 worm threads all work simultaneously to
propagate the infection. Each chooses a random target IP
and then uses one of the following masks with the given
probabilities.The masked parts of the IP are replaced
with the host computer's own IP information. Thus, the
worm mostly confines its targeting to IP addresses close
to the host computer's own.
0.0.0.0 (probability 12.5%) => random
255.0.0.0 (probability 50.0%) => same class A
255.255.0.0 (probability 37.5%) => same class B
Target IPs which are excluded are 127.x.x.x and 224.x.x.x,
and no octet is allowed to be 0 or 255. In addition, the
host will not attempt to re-infect itself.
INFECTION PROCESS
-----------------
Before each attempt to connect to a new target, the worm
checks the local time to see if the year is less than 2002
and if the month is less than 10. If either of these checks
return false, then the worm ceases the propagation cycle
and reboots the server. Note that this implies that all worms
will cease propagating by Oct. 1, 2001.
To aid performance, the worm uses a nonblocking socket to connect
to each target. Specifically this means that if one thread is
stuck waiting for a slow connection to a particular target,
the wait will not slow down the rest of the threads from continuing
their scanning function.
After making a successful connection with a target (the three way
handshake has completed), the worm thread uploads all of the
worm code at once, looks for an acknowledgement, and then moves on
to attempting to infect other hosts.
When a worm first arrives on a target and begins execution, the
worm checks to see if the host has already been infected, and if
so, disables itself. Specifically, the worm checks to see if a CodeRedII
atom has been placed using "GlobalFindAtomA". If the worm finds that
the atom exists then it goes to sleep forever. If the CodeRedII atom
does not exist, the worm creates the atom and continues execution.
DOWNLOADS
---------
Corecode provides a .zip file containing a IDA Pro project file
and a plaintext disassembly for both the worm and the trojan
explorer.exe at:
http://www.eikon.tum.de/~simons/ida_root/
To download the eEye analysis and their disassembly files:
http://www.eeye.com/html/advisories/coderedII.zip
The worm binary can be found at the Unixwiz site:
http://www.unixwiz.net/techtips/CodeRedII.html
REFERENCES
-----------
Corecode's Analysis:
http://archives.neohapsis.com/archives/incidents/2001-08/0092.html
NAI's Analysis:
http://vil.nai.com/vil/virusChar.asp?virus_k=99177
eEye's Analysis:
http://www.eeye.com/html/advisories/coderedII.zip
SecurityFocus Analysis:
http://archives.neohapsis.com/archives/bugtraq/2001-08/0066.html
ACKNOWLEDGEMENTS
-----------------
We are very grateful to Jesper Johansson for reviewing this
report and providing many helpful suggestions and technical details.
Many thanks are due to corecode, who stayed up all night and provided
the very first analysis of the worm binary to the public.
We'd also like to recognize Stephen Friedl of Unixwiz for performing
a higher level analysis last night and posting his findings to the web
before any other concrete information was available.
Also, we thank Matt Scarborough for testing the worm on WinNT
to confirm that these systems crash rather than running worm
code successfully.
