********** 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. ------------------------------------------------------------------------- POLITECH -- Declan McCullagh's politics and technology mailing list You may redistribute this message freely if you include this notice. To subscribe, visit http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ -------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Sun Aug 05 2001 - 09:50:39 PDT