Code Red Worm

January 26, 2000

An innocuous Microsoft bulletin (MS00-006) was posted to the Microsoft Web site and sent out to the various security lists (http://www.microsoft.com/technet/security/bulletin/ms00-006.asp). The vulnerability was called "Malformed Hit-Highlighting Argument Vulnerability" and was all but buried in the steady stream of Microsoft vulnerabilities.

June 18, 2001: The First Attack

A security hacker group published an advisory warning of a remote buffer overflow in Microsoft's Internet Information Server (IIS). If properly exploited, an attacker could gain remote administrative access to any server running the product. In other words, a hacker could gain complete control of the target system, performing any action he desired.

This vulnerability was the result of an ISAPI filter that handled requests for the Microsoft Index Server. The server typically handles requests by sending a specially formed GET request with an .ida extension. This particular hacker group was able to cause a buffer overflow in that filter and execute arbitrary code on the remote system. In essence, the group proved the voraciousness of MS00-006, which was released some eighteen months earlier.

The initial advisory stated that, owing to the wide character nature of the overflow, other techniques needed to be used to take advantage of the flaw. A "heap spraying" technique was developed but was unreliable and volatile. Other techniques were available but were not made public; the initial advisory led others to believe that exploitation was too daunting a task. As a result, no exploits really were released to the public domain for this hole at that time. However, a small number of exploits had occurred. The unfortunate consequence was that the majority of people in the field took a "No exploit, no threat" stance.

July 12, 2001

Information and packet logs were released from network administrators who were experiencing a large number of attacks targeting the .ida vulnerability. The attackers appeared to be using a technique that accessed a full range of memory and made the exploitation of the overflow relatively straightforward. Analysis of the logs revealed that a new worm was in its infancy.

The Details

Little was known about the vulnerability and its risk to IIS Web servers at that time. But as analyses of the attacks grew, so did the security community's understanding of the threat. We knew it was a worm of some sort, but beyond that we were just picking up the pieces and trying to complete the puzzle. The details trickling in indicated the following:

The worm first gained control of a Web server via buffer overflow.

The worm began the infection process by creating a list of randomly generated IP addresses. A flaw in the code implementation ensureed that the random numbers were never be truly random. The author of the code had used a hard-coded "seed" that passed to the random number generator. As a result, each server infected by the worm generates the same list of IP addresses and subsequently reinfects the same systems multiple times.

After infection the worm would do the following:

The worm environment set up on the infected system.

The worm created 100 threads to spread itself.

The first 99 threads were used to infect other Web servers.

The 100th thread checked the victim to determine whether the server is an English (U.S.) Windows NT/2000 system. If the system was English (U.S.) the worm proceeded to modify the content of the Web server. The index of the local Web server was replaced and text inserted that read: "Welcome to http://www.worm.com!, Hacked By Chinese!" The modified Web page stayed active on the server for ten hours and then disappeared. The message reappeared only upon reinfection.

If the server was not an English (U.S.) version, the thread was then used to spread infection.

In each thread, the worm checked for the file C:\notworm. If the file was found, the worm went dormant. If the file didn't exist, the thread continued the infection of other systems.

Each thread checked the system clock. If the date was after the 20th of the month (GMT), the thread stopped infection and instead attacked http://www.whitehouse.gov. The worm attacks by sending 100k of data to the Web port of the White House Web site from the 20th to the 28th of the month. With each infected system performing this attack it resulted in an effective denial of service attack.

If the date instead was between the 1st and the 19th of the month the worm disregarded the White House Web site and continued infection as normal.

Luckily, the hacker's mistake in his random number generator algorithm actually saved further significant infection. His incorrect implementation prevented the first generation of the worm from being truly effective. Unfortunately, it wasn't long until someone decided to correct the mistake.

Note: for more information check out http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-033.asp

July 19, 2001

On the morning of July 19 a new variant was found to be infecting unpatched IIS Web servers. The worm replicated the first variant with one minor, but crucial, change: A random seed replaced the static seed used in the first generation code. Now each infected computer generated a new list of randomly generated IP addresses. The result of this minor change was alarmingly obvious. In just fourteen hours, the newly evolved Code Red infected more than 359,000 machines.

Because the code was identical to the first worm aside from the random seed, the damage to systems was still Web page defacement. But the impact on the global infrastructure was immense, owing to the sheer number of hosts that were penetrated and used to shoot data off to additional hosts. The worm spreaded and infected so rapidly that a large number of machines were reinfected as system administrators rebooted to install a patch for the .ida vulnerability. In fact, at one company we know of, in the time it took to rebuild its systems and apply the patches, the worm's virulence reinfected the very system being cleaned.

The foundation had been laid, and it wouldn't be long until a more malevolent variation reared its head.

August 4, 2001

http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30833

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

A completely new variant appeared. This worm had nothing in common with the previous worms. Its source code included the string "CodeRedII," giving the worm its name. The worm does its work in the following manner:

First the worm checks the host for a previous infection. If the host is found infected, the worm goes dormant.

The worm checks to see if the current system is Chinese. If so, the worm creates 600 threads. If the system is a non-Chinese server, the thread count is set to 300.

The worm spawns the propagation threads.

The payload of the worm is now executed:

The worm first gets the local system time. The worm checks to see whether the year is prior 2002 and the month less than 10. If the date is outside this range, the system is rebooted.

CodeRed II implements an advanced method for generating IP addresses to probe. First, a random IP address is generated. A mask then is applied to the IP to produce the target address. One-eighth of the time the worm attempts to infect a completely random IP address. One-half of the time the worm probes addresses within the same class A range of the local address. Three-eighths of the time the worm probes addresses within the same class B range of the local IP.

If the worm generates an IP of the local system or a broadcast address, that IP is skipped and a new address is generated. The method that CodeRed II implements allows the worm to spread at a much faster rate than Code Red.

The payload of the CodeRed II worm is far more dangerous than the previous variants, because it modifies the host's remote administrator (SYSTEM)-level access after infection. CodeRed II doesn't attempt any denial-of-service attacks nor does it modify the Web page. After infection anyone has the opportunity to take control of the server, which the worm accomplishes by:

1. Setting the drive to C:.

2. Copying cmd.exe from the Windows system directory to \inetpub\scripts\root.exe and \progra~1\common~1\system\MSADC\root.exe.

3. Placing an embedded binary code written to the file explorer.exe in the root drive of the system.

4. Setting the drive to D: and repeating the previous steps.

The file explorer.exe is a Trojan that, when called, carries out a number of malicious steps. The following are highlights of those steps:

1. The local windows directory is retrieved.

2. Explorer is executed from within the local Windows system directory.

3. The Trojan disables windows file protection.

4. A virtual Web path is created with maps /c and /d to C: and D:, respectively. This functionality is implemented allowing the system to be backdoored. If root.exe is removed, an attacker may still be able to compromise the server.

Code Red, including its variants, was the most successful worm to ever hit the Internet. During more than three months the number of successful infections by the three worms was astounding. Monetary losses were estimated in the billions of dollars.

Nimda Worm

September 18, 2001

Reports flooded in from users and administrators with details of attacks on their Web servers. In addition to the Web attacks observed, suspicious e-mail messages containing wave file attachments were reported. At first glance, many thought that the traffic was another Code Red variant on the loose. But upon further analysis, it was clear that a new worm had hit.

The new worm, officially named W32/Nimda-A, or more commonly Nimda, was designed to infect Win9x, NT, and Windows 2000. The Nimda worm utilized a number of vectors (methods) to spread and infect:

1. Through e-mail: Outlook An email is received with an attachment named "readme.exe" of the mime type "audio/x-wav." If received by a vulnerable e-mail client, previewing the message caused the readme.exe file to execute without the user's consent. The subject line of the e-mail is changed and the e-mail address of the sender is spoofed.

2. Through the Web: IIS The worm hunts Web servers for the root.exe backdoor left by the CodeRed II worm. Other attack methods include the Unicode vulnerability (CVE-2000-0884) and the Double decode vulnerability (CVE-2001-0333). All are specific to the Microsoft IIS Web server.

3. HTML files The worm appends code to all ASP, HTML, and HTM files that exist on an infected server. As a result, users visiting the infected pages may unwittingly infect their systems.

Network Shares Nimda Also Has the Ability to Spread via Misconfigured or Insecure Network Shares

The Details

E-mails are received with the attached file readme.exe. Relying on vulnerabilities in some versions of Internet Explorer and the Outlook mail client, the executable is forced to run automatically without user acknowledgment. Nimda alters its attributes to "hidden" and copies itself to the system root with the filenames load.exe and riched32.dll. It then attempts to spread itself via network shares. The system.ini file is altered to include the following line: shell=explorer.exe load.exe -dontrunold.

This addition caused the virus to execute on startup.

E-mail addresses are gathered from the address book, inboxes and outboxes, and HTML/HTM files. The virus is then forwarded to the recipients. IIS Web servers that suffer from the Unicode vulnerabilities are penetrated. IIS Web servers that contain the backdoor left by Code Red II are penetrated.

After gaining control of a vulnerable IIS server, the worm uses TFTP to transfer its code from the attacker to the victim. The file transferred is named Admin.dll. Javascript code, which downloads the file readme.eml and is added to ASP, HTM, and HTML files. If the site is visited by an insecure version of Internet Explorer, the file is downloaded and the virus continues traveling.

Finally, while spreading through unprotected networks, the virus creates files with the .EML and .NWS extensions. These files are identical to the readme.eml file.

Without question, the ubiquity of Nimda's infections was due to its use of multiple infection vectors. As the vulnerabilities affected became known, the real reasons behind it's the worm's spread became clear: Known vulnerabilities hadn't been patched or resolved. In a perfect world all the losses would have been prevented if users and administrators had applied the appropriate remedies. Of course, the world is far from perfect, and worms will continue to thrive in the future. If tomorrow's worm utilizes vulnerabilities that are unknown publicly and no fix existes a well-coded worm could cause absolute mayhem and seriously disrupt online communications.

Combatting Worm Evolution

Although the damage caused by the Code Red and Nimda worms was staggering, the damage could have been far worse. For example, the Code Red worm targeted only IIS5, yet the vulnerability also was present in IIS4. From our own analysis of the .ida vulnerability, we realized that executing code on an IIS4 server also was a rather trivial exercise. If Code Red had targeted IIS4 as well as IIS5, the outcome would have been disastrous. Unfortunately, we foresee another, more virulent and ferocious Code Red in the future.

Netcraft (http://www.netcraft.com) lists Apache as having 56% and Microsoft 30% of Web server market share. Microsoft's IIS is the obvious target based on its history of flaws coupled with the fact that it is a closed-source product. There's a lot hiding in it and it's just a matter of time before more flaws are uncovered. However, if an equivalent vulnerability is found in the Apache Web server, the pervasiveness of attack would be staggering.

React and Respond

One of the primary reasons that the spread of Code Red was somewhat controlled was because of the independent code analyses performed by various members of the security community. They highlighted exactly how the worm operated and what its greatest threats were. The Web site of the White House avoided danger by getting a heads-up from analysts.

The first step in understanding a new worm is to disassemble its binary code to identify the worm's actions. A few things can be done to make invasion a slightly more daunting task and give the worm a little more free time in the wild.

Tomorrow's worms will be coded in pure assembler language and will include polymorphic routines, anti-debugging techniques, and generally hard-to-trace code. Imagine a well-coded, cross-platform worm that can take advantage of unknown vulnerabilities in the two dominant Web servers in existence, the Apache and IIS.

It will be done. It's just a matter of when. The clock starts now.