DataBus - Vol 41 No. 6: October-November, 2001
|
A Closer Look at 'Code Red'
On Thursday July 19th, Code Red compromised at least 359,104 hosts in approximately thirteen hours. This statistic, from the Cooperative Association for Internet Data Analysis (CAIDA), shows just how damaging and far reaching the Code Red worm has been. For those unfamiliar with worms, they are self-propagating pieces of code that take advantage of flaws in computer software. In this case, the Code Red worm takes advantage of a remotely exploitable hole in Microsoft's Internet Information Server (IIS) versions 4 and 5. The worm sends a Uniform Resource Locator (URL) to a host that overflows a buffer in Microsoft's Index Server, a part of IIS. This buffer overflow allows the worm to execute arbitrary code. Code Red installs a copy of itself into memory on the infected computer and attempts to infect additional hosts. There appear to be two versions of the worm. The first, called CRv1 by eEye (the team that initially analyzed the worm), has a flaw in its random generation of target IP addresses. CRv1, first publicly reported in the wild around July 15th, uses a random number generator that makes use of a static seed to get new IP addresses to attack. This static seed means that the worm will hit the same machines over and over again. CRv1 spread, but not quickly, and not well. Then, sometime on Thursday, July 19th, CRv2 was released into the wild. CRv2 is nearly identical to CRv1, except that it uses a better random number generator to create target IP addresses. CRv2 also does away with the temporary website defacing. CRv2 was enormously successful. Infecting 359,104 hosts in such a brief time is nothing short of amazing. According to CAIDA, at its peak, CRv2 was infecting more than 2000 new hosts every minute.
Function
When the worm successfully infects a new system, there are a series of steps that it follows. These steps are explained in greater technical detail in eEye's analysis on their website. - Step 1: Setup Environment - This step consists of copying the worm code from the attack host to the victim host. The entire code for the worm is sent from the infected system to the victim host. This differs from many other worms that rely on obtaining their code in a separate session, either connecting to a central repository, or retrieving it from the attacking host. This attack is entirely self-contained in one URL. - Step 2: Create Threads - CRv1 and CRv2 have nearly the same functionality when it comes to creating the attack threads. They each launch 99 threads (processes) to infect new hosts. - Step 3: Spread - At this point, the first 99 threads begin randomly attacking IP addresses. The worm doesn't attack the localhost addresses or multicast addresses. All other addresses, regardless of whether or not they are routable, are attacked. The worm doesn't perform any kind of checks to verify if a host is up or not, but just attempts to connect to port 80 on the random IP address and send the malicious web request. This results in some additional fallout detailed below in "Side Effects." - Step 4: 100th Thread - If CRv1 infects a US English system, the 100th thread is used to deface the website with the following message: "Welcome to http://www.worm.com!, Hacked By Chinese!" The defacement does not happen right away. The creators of the worm gave it two hours to infect additional hosts before displaying the defacement, rather than give itself away by defacing the website too quickly. CRv1 does not change any of the files on the filesystem to perform its defacement. Instead it intercepts connections to the website, and substitutes a new message. Normally an administrator could check the integrity of the files stored on the filesystem to ensure a webserver has not been hacked, but in this case, the worm sends the hacked message without tripping any alarms. If CRv2 infects a US English system, the 100th thread intercepts calls to the website, performs harmless redirects, eventually returning the unchanged index of the webserver. If the OS is not English, then both CRv1 and CRv2's 100th thread go on to infect new hosts. - Step 5: c:\notworm - The worm checks for the existence of the file c:\notworm. If this file exists, the worm goes dormant. If not, the worm proceeds to step 6. There are several theories for why this check might exist. Perhaps the check was for testing purposes during creation of the worm. Maybe its intent was to be used to disable the worm at a later time. It's not clear what the programmers originally intended this to be, other than a way to disable the worm. - Step 6: www.whitehouse.gov - Although spreading quickly was one of the worm's missions, it had another mission to perform as well. As soon as the date hit the UTC 20th of any month (the first case would be Friday July 20th, 2001) , the worm was to begin attacking one of the www.whitehouse.gov IP addresses. This was to continue until the UTC 28th (Saturday July 28th, 2001 for the first round) of that month. From the 28th through the end of the month, the worm sleeps. eEye has stated that the worm will begin eternal sleep. Others have claimed that the worm will continue to spread after the end of the month (see CERT advisories CA-2001-19 and CA-2001-23.) Early reports on August 1st show that the worm began spreading again, but was less prolific than before, infecting approximately 22,000 systems by mid-afternoon. In any case, PATCH YOUR SYSTEMS. It's likely that the worm, or a worm utilizing the same vulnerability, will be infecting systems for a while. Thanks to eEye's analysis, the Whitehouse was able to coordinate with their ISP to divert traffic intended for the IP address in the worm. The www.whitehouse.gov website remained active on another IP address. Because the worm's creator used a static IP address, the worm didn't fully succeed in its second mission.
Side Effects
Side effects of the Code Red worm are outlined below. - ICMP Floods: eEye estimates that on a slow network, an infected host can attempt to infect up to a half million addresses in a single day. This generates significant traffic, many times to nonexistent hosts or networks with no route. When packets are sent to these systems, ICMP messages such as "Host Unreachable" or "Network Unreachable" are sent in response. The extra traffic generated by these ICMP messages and HTTP requests causes many network devices to increase significantly in load and start dropping packets. The side effect can lead to Denials of Service (DoS) and increases in network latency. - Denial of Service for Networked Devices: There are several reports on BugTraq (and at least one advisory by Cisco) that indicate this worm was affecting more than just IIS boxes.
Conclusion
This worm could have wreaked havoc across the Internet. In a way it did, but not to the extent that it could have. We were lucky this time. Next time, I wouldn't count on that. All it takes is a copycat to add the ability to delete the filesystem upon infection. Maybe the next person will just want to add some remote control software like Sub7 or BackOrifice to the server. It's hard to say what the next worm of this kind will do. One thing's for sure though; with the success of Code Red, there are bound to be similar worms out there soon. Unfortunately, many administrators probably still haven't heard of the Code Red worm and have no idea that their systems have been compromised. Many security professionals and organizations are looking through the list of compromised hosts and crafting emails to send to the administrators of these domains advising them to patch their servers. This will help, but based on past experience, the problem will not completely go away. Many of these vulnerable systems will remain vulnerable, even after warnings from the security community. Some administrators won't understand, won't believe, or won't care about whether or not their systems are vulnerable. Regardless of the platform used for future attacks, the results of a worm like this could be devastating. A fundamental shift in programmers' and system administrators' views of security needs to happen to limit the likelihood of an event like this occurring in the future.
Update
Prior to publication of this lesson, a new worm utilizing the same flaw in Microsoft's IIS server was released into the wild. The release occurred sometime late in the week of August 3rd. As theorized in the conclusion, this worm is much more malicious than the original Code Red, leaving backdoors and modifying system configurations. The new worm is called Code Red II (a name given by the worm authors in the code). This should not be confused with CRv2, as these worms are very different in function. Here some of the highlights of the new worm :
References and Additional Information
Cisco Security Encyclopedia (CSEC) - http://www.cisco.com/go/csec Vulnerability ID 3394 explains details about how the buffer overflow works, as well as relevant links and CSIDS signatures. eEye's Analysis - http://www.eeye.com/html/Research/Advisories/AL20010717.html The original analysis, these guys even named the worm. Code Red II Analysis : http://www.eeye.com/html/advisories/coderedII.zip CAIDA's Analysis - http://www.caida.org/analysis/security/code-red/ Great analysis with lots of data, and some great statistics. Microsoft Advisory - http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-033.asp Includes patch information. CERT Advisory - http://www.cert.org/advisories/CA-2001-13.html CERT Advisory - http://www.cert.org/advisories/CA-2001-19.html CERT Advisory - http://www.cert.org/advisories/CA-2001-23.html CERT Recovery - http://www.cert.org/tech_tips/win-UNIX-system_compromise.html CERT has some good steps to follow after a system compromise. Cisco Advisory - http://www.cisco.com/warp/public/707/cisco-code-red-worm-pub.shtml Cisco Advisory - http://www.cisco.com/warp/customer/63/ts_codred_worm.html Good list of affected gear and patches.
Sue Mangiapane is an Account Manager for Cisco Systems, Inc. Sue can be reached by phone at 949-789-5006, by Fax at 949-789-5005, or by e-mail at .
|
CEDPA