{\rtf1\ansi\ansicpg1252\deff0\deftab720{\fonttbl{\f0\fswiss MS Sans Serif;}{\f1\froman\fcharset2 Symbol;}{\f2\fmodern Courier New;}{\f3\froman Times New Roman;}{\f4\fswiss Courier New;}} {\colortbl\red0\green0\blue0;\red255\green255\blue255;\red0\green0\blue255;} \deflang1033\pard\plain\f3\fs24\cf1\b Code Red (II) \par Version 0.2 - August 6, 2001\plain\f3\fs24 \par \pard\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\plain\f4\fs20 Code Red II Worm Analysis Update \par ================================= \par The new worm that was first noticed on Saturday has been \par analyzed. Here is a summary of the facts based on the \par excellent analyses referenced at the bottom of this page. \par \par \par \par EXPLOITED VULNERABILITY \par ------------------------ \par This worm uses the same mechanism as the original Code Red \par worm to infect vulnerable servers. That is, the worm looks \par for IIS servers that have not patched the unchecked buffer \par vulnerability in idq.dll or removed the ISAPI script mappings. \par Note, however, that due to the more malicious actions of this \par worm, patching and rebooting an infected server is no longer \par sufficient to clean the system. For more information see the \par Code Red FAQ at: \par \plain\f4\fs20\cf2\ul \par http://www.incidents.org/react/code_red.php\plain\f4\fs20 . \par \par \par Except for using the buffer overflow mechanism in order \par to get the worm code executed on a vulnerable IIS server, \par this new worm is entirely different from the original Code \par Red CRv1 and CRv2 variants. \par \par \par Note: According to eEye, the worm code will be successfully \par executed only on a Win2000 system running a vulnerable IIS \par server, WinNT-based IIS servers will simply crash when \par attempting to execute the worm code. Our experiments and \par reports received from users confirm this finding. \par \par \par \par BACKDOOR \par -------- \par The most damaging property of this new worm is that the worm \par creates a back door on an infected server, leaving the system \par wide open to any attacker. \par \par \par The worm copies %windir%\\CMD.EXE to the following locations: \par c:\\inetpub\\scripts\\root.exe \par c:\\progra~1\\common~1\\system\\MSADC\\root.exe \par d:\\inetpub\\scripts\\root.exe \par d:\\progra~1\\common~1\\system\\MSADC\\root.exe \par \par \par Given that the \\scripts and \\MSADC virtual folders have execute \par permission (they do by default), moving a copy CMD.EXE to these \par externally accessible locations provides a means for a remote attacker \par to execute arbitrary commands on the compromised server. IIS will \par pass commands to root.exe for execution when the server is presented \par with a request such as (where ARBITRARY_COMMAND is any command): \par http://IpAddress/c/inetpub/scripts/root.exe?/c+ARBITRARY_COMMAND \par \par \par In addition, the worm creates a trojan copy of explorer.exe \par as described below. Due to the actions of the trojan \par explorer.exe, IIS will make the C: and D: root directories \par accessible to a remote attacker even if the root.exe \par command shell program is removed from the \\scripts and \par \\MSADC directories. \par \par \par \par TROJAN EXPLORER.EXE \par -------------------- \par The worm carries its own copy of explorer.exe. The worm \par places its own copy of explorer.exe at c:\\explorer.exe \par and d:\\explorer.exe. By placing the trojan file in these \par locations, Windows will find and run the trojan rather \par than the real explorer.exe because of the way Windows \par seaches for executables by default. Specifically, unless \par the system has been patched against the "Relative Shell \par Path" vulnerability, the trojan explorer.exe will be \par executed when the next user logs into the system. \par (See \plain\f4\fs20\cf2\ul \par http://www.microsoft.com/technet/security/bulletin/MS00-052.asp\plain\f4\fs20 ) \par \par \par Upon execution, the trojan first runs the real explorer.exe \par (thus the user will not notice any problems) and then goes \par on to modify the system registry as outlined below. \par \par \par First, the trojan program adds the value SFCDisable=0xFFFFFF9D \par to HKLM\\SOFTWARE\\Microsoft\\WindowsNT\\CurrentVersion\\Winlogin. \par This registry setting completely disables the Windows File \par Protection (WFP) mechanism. WFP prevents the replacement of \par certain monitored system files. See the following for more info: \par \plain\f4\fs20\cf2\ul \par http://support.microsoft.com/support/kb/articles/Q222/1/93.ASP\plain\f4\fs20 \par \par \par Next, the trojan sets the following "Virtual Roots" in the registry: \par SYSTEM\\CurrentControlSet\\Services\\W3SVC\\Parameters\\Virtual Roots\\scripts to ,,217 \par SYSTEM\\CurrentControlSet\\Services\\W3SVC\\Parameters\\Virtual Roots\\msadc to ,,217 \par \par \par These "217" settings ensure that the \\scripts and \\msadc virtual directories \par (which contain the root.exe copy of cmd.exe) have read/write/execute \par permission. More specifically, the "217" permission mask corresponds \par to the OR of the following virtual folder settings: \par \par \par HSE_URL_FLAGS_SCRIPT | HSE_URL_FLAGS_DONT_CACHE | HSE_URL_FLAGS_EXECUTE \par | HSE_URL_FLAGS_WRITE | HSE_URL_FLAGS_READ \par \par \par In other words, the attackers wish to allow both scripts and executables \par to run. In addition, they wish to make sure that the content is not cached \par between requests, since requests may be different. Also they are allowing \par read and write. \par \par \par Finally the trojan sets these two "Virtual Root" values as well: \par SYSTEM\\CurrentControlSet\\Services\\W3SVC\\Parameters\\Virtual Roots\\c to c:\\,,217 \par SYSTEM\\CurrentControlSet\\Services\\W3SVC\\Parameters\\Virtual Roots\\d to d:\\,,217 \par These mappings, which do not normally exist, map the root C: and D: \par drives to a place where IIS can find them, namely /c and /d. The \par permissions here are also set to read/write/execute/don't-cache. \par \par \par Quoting eEye's analysis, the purpose of these mappings are described: \par -------- \par Basically the above code creates a virtual web path (/c and /d) which maps \par /c to c:\\ and /d to d:\\. The writer of this worm has put in this \par functionality to allow for a backdoor to be placed on the system so even if \par you remove the root.exe (cmd.exe prompt) from your /scripts folder an \par attacker can still use the /c and /d virtual roots to compromise your \par system. The attacks would basically look like: \par \par \par http://IpAddress/c/inetpub/scripts/root.exe?/c+dir \par (if root.exe was still there) or: \par http://IpAddress/c/winnt/system32/cmd.exe?/c+dir \par (Where dir could be any command an attacker would want to execute). \par ---------- \par \par \par Note that the trojan explorer.exe need only be executed once for \par these registry changes to be made. Once the "Virtual Root" \par registry settings are in place, and the IIS server is restarted, \par the backdoors become enabled. Further, the backdoors will \par remain enabled, forever after, regardless of whether or not \par explorer.exe is running. \par \par \par To emphasize, note that killing the trojan explorer.exe process will \par not remove the back doors. Further, even killing the explorer.exe \par process and removing the copies of root.exe and deleting the registry \par settings will not eliminate the backdoors. If the trojan explorer.exe \par is executed again (e.g. when the next person logs in), the registry \par settings will be reinstated, making the C: and D: drives again \par externally accessible following an IIS server restart. \par (For more information on creating Virtual Roots under IIS see: \par \plain\f4\fs20\cf2\ul \par http://www.avdf.com/jan98/art_ot001.html\plain\f4\fs20 .) \par \par \par Finally, note that even deleting the registry settings, removing the \par copies of root.exe, and removing the trojan explorer.exe is not sufficient \par to clean the system. During the time the system was backdoored any other \par attacker could have installed new backdoors that are not associated \par with this worm and would not be found. \par \par \par The trojan process sleeps most of the time, but wakes \par to loop through these registry key modification steps every \par 10 minutes. This way, even if an administrator notices the \par registry settings and deletes them, the trojan will reinstate \par the settings a few minutes later. \par \par \par \par PROPAGATION \par ----------- \par How aggressively the worm attempts to propagate itself \par depends on whether or not Chinese is the language installed on \par the system. If Chinese, the worm creates 600 threads and \par attempts to spread for 48 hours. If non-Chinese, the worm \par creates 300 threads and attempts to spread for 24 hours. \par After the infection-spreading interval, the system is \par forcibly rebooted. The reboot flushes the memory resident worm, \par and leaves the backdoors and the explorer.exe trojan in \par place. \par \par \par \par TARGET SELECTION \par ----------------- \par The 300 or 600 worm threads all work simultaneously to \par propagate the infection. Each chooses a random target IP \par and then uses one of the following masks with the given \par probabilities.The masked parts of the IP are replaced \par with the host computer's own IP information. Thus, the \par worm mostly confines its targeting to IP addresses close \par to the host computer's own. \par \par \par 0.0.0.0 (probability 12.5%) => random \par 255.0.0.0 (probability 50.0%) => same class A \par 255.255.0.0 (probability 37.5%) => same class B \par \par \par Target IPs which are excluded are 127.x.x.x and 224.x.x.x, \par and no octet is allowed to be 0 or 255. In addition, the \par host will not attempt to re-infect itself. \par \par \par \par INFECTION PROCESS \par ----------------- \par Before each attempt to connect to a new target, the worm \par checks the local time to see if the year is less than 2002 \par and if the month is less than 10. If either of these checks \par return false, then the worm ceases the propagation cycle \par and reboots the server. Note that this implies that all worms \par will cease propagating by Oct. 1, 2001. \par \par \par To aid performance, the worm uses a nonblocking socket to connect \par to each target. Specifically this means that if one thread is \par stuck waiting for a slow connection to a particular target, \par the wait will not slow down the rest of the threads from continuing \par their scanning function. \par \par \par After making a successful connection with a target (the three way \par handshake has completed), the worm thread uploads all of the \par worm code at once, looks for an acknowledgement, and then moves on \par to attempting to infect other hosts. \par \par \par When a worm first arrives on a target and begins execution, the \par worm checks to see if the host has already been infected, and if \par so, disables itself. Specifically, the worm checks to see if a CodeRedII \par atom has been placed using "GlobalFindAtomA". If the worm finds that \par the atom exists then it goes to sleep forever. If the CodeRedII atom \par does not exist, the worm creates the atom and continues execution. \par \par \par \par DOWNLOADS \par --------- \par Corecode provides a .zip file containing a IDA Pro project file \par and a plaintext disassembly for both the worm and the trojan \par explorer.exe at: \par \plain\f4\fs20\cf2\ul \par http://www.eikon.tum.de/~simons/ida_root/\plain\f4\fs20 \par \par \par To download the eEye analysis and their disassembly files: \par \plain\f4\fs20\cf2\ul \par http://www.eeye.com/html/advisories/coderedII.zip\plain\f4\fs20 \par \par \par The worm binary can be found at the Unixwiz site: \par \plain\f4\fs20\cf2\ul \par http://www.unixwiz.net/techtips/CodeRedII.html\plain\f4\fs20 \par \par \par \par REFERENCES \par ----------- \par Corecode's Analysis: \par \plain\f4\fs20\cf2\ul \par http://archives.neohapsis.com/archives/incidents/2001-08/0092.html\plain\f4\fs20 \par \par \par NAI's Analysis: \par \plain\f4\fs20\cf2\ul \par http://vil.nai.com/vil/virusChar.asp?virus_k=99177\plain\f4\fs20 \par \par \par Symantec's Analysis: \par \plain\f4\fs20\cf2\ul \par http://www.sarc.com/avcenter/venc/data/codered.v3.html\plain\f4\fs20 \par \par \par eEye's Analysis: \par \plain\f4\fs20\cf2\ul \par http://www.eeye.com/html/advisories/coderedII.zip\plain\f4\fs20 \par \par \par \par SecurityFocus Analysis: \par \plain\f4\fs20\cf2\ul \par http://archives.neohapsis.com/archives/bugtraq/2001-08/0066.html\plain\f4\fs20 \par \par \par \par ACKNOWLEDGEMENTS \par ----------------- \par We are very grateful to Jesper Johansson for reviewing this \par report and providing many helpful suggestions and technical details. \par \par \par Many thanks are due to corecode, who stayed up all night and provided \par the very first analysis of the worm binary to the public. \par \par \par We'd also like to recognize Stephen Friedl of Unixwiz for performing \par a higher level analysis Saturday night and posting his findings to the web \par before any other concrete information was available. \par \par \par Also, we thank Matt Scarborough for testing the worm on WinNT \par to confirm that IIS running on these systems will crash rather \par than running the worm code successfully. Specifically, Matt notes \par that Inetinfo.exe crashes, such that the IIS server loses all \par web services, HTTP, FTP, etc. (The NT operating system does not crash.) \par \par \par Finally, we'd like to thank Jason Fossen for testing the workings \par of the Code Red II registry settings and providing insightful information \par regarding these. Jason made the interesting discovery that if a virtual \par directory which already exists (e.g. /scripts and /msadc) is modified \par in the registry, then the next time IIS restarts the modifications are \par overwritten with the authoritative info from the metabase. That is, direct \par changes to the registry for previously existing virtual folders (/scripts and \par /msadc) are not picked up by IIS and the added permissions aren't reflected in \par the GUI. On the other hand, if a virtual directory is created in the registry \par which did not previously exist (e.g. /c and /d) then these changes are written \par to the metabase, hence, making the changes survive restarts of IIS. Jason \par speculates that this registry-to-metabase flushing may exist for backwards \par compatibility with older versions of IIS. All tests were performed on \par Windows2000 Advanced Server SP2. \par \pard\plain\f2\fs20 \par }