Code Red 2001: The Worm That Targeted the White House Website

In July 2001, web servers around the world began to show an odd message on their home pages: "HELLO! Welcome to http://www.worm.com! Hacked By Chinese!" It was the visible sign of Code Red, a worm that spread through Microsoft's web server software at extraordinary speed and was programmed to attack the website of the White House. Behind the drama was a plain and familiar failure: the fix had been available for weeks, and many administrators had not installed it.

Discovery and the name

Code Red was first analysed by researchers at the security firm eEye Digital Security, including Marc Maiffret and Ryan Permeh, who began analysing the worm on 13 July 2001, shortly after it started to spread, and published an advisory on 17 July. They named it after the soft drink they happened to be drinking while working on it, Mountain Dew Code Red.

The vulnerability

Code Red exploited a buffer overflow in the indexing component of Microsoft's Internet Information Services, known as IIS. The flaw, in a library used by the indexing service, allowed a specially crafted web request to run the attacker's code on the server. Microsoft had released a patch for it in June 2001, in security bulletin MS01-033, about a month before the worm.

The worm lived in memory and did not need to write a file to disk to spread. After infecting a server, it started scanning for other vulnerable servers by generating internet addresses and trying the same attack on each.

How it behaved

The worm had a schedule coded into it, based on the day of the month.

1. In the first part of each month, it spread by scanning for new victims.
2. Between roughly the 20th and 27th, infected machines were programmed to flood a particular numeric address with traffic. That address belonged to the White House website.
3. After that, it went dormant.

The first version had a flaw: each infected machine generated the same list of addresses to scan, so the spread was limited. A new version released a few days later fixed this, using a random seed. That version spread dramatically. Measurements by researchers at the Cooperative Association for Internet Data Analysis, CAIDA, found that on 19 July, more than 359,000 computers were infected in less than 14 hours.

The White House response

Because the target was a fixed address, defenders had a simple option: change the address. The White House moved its website to a different address before the attack began, and the flood of traffic hit an address with nothing behind it. The worm's planned attack had little effect on the site itself, though the volume of scanning traffic strained networks around the world.

A second worm, Code Red II, appeared in August 2001. Despite the name, it was a separate piece of code that used the same vulnerability, but it installed a backdoor on the infected machine, which let attackers control it later.

Why it mattered

• Speed. The worm showed that an internet-wide infection could happen faster than any human response.
• Patch gap. A fix existed. The window between a patch and its widespread installation was the opening the worm used.
• No user action. Unlike email worms, nobody had to click anything. A vulnerable server connected to the internet was enough.

The episode reinforced the importance of vulnerability disclosure and patch management, and helped drive Microsoft towards a stronger security push. In January 2002 the company announced its Trustworthy Computing initiative, in which security became a stated priority in software development.

The defacement message gave the worm a public face, but the real damage came from the infection itself. Infected servers slowed down, scanning traffic congested networks, and cleaning up required administrators to patch and restart machines.

Code Red also made an uncomfortable point about monocultures. Because so many servers ran the same software in the same default configuration, one flaw gave one attacker access to a significant fraction of the visible web. Diversity helps a little, but the practical response for most owners is not to change platforms. It is to shrink the window between a fix being published and being applied. The worm spread in the gap between the two.

Security teams now measure this gap directly, and talk about the time to patch as a key figure. For a small site owner, the equivalent is simple: how many days pass between a security update appearing for your CMS and it being installed on your site? Aim for days, not months.

The lesson for site owners today

The Code Red lesson is the most repeatable in security: patch quickly. Attackers watch for new vulnerability disclosures and often have working exploits within days. The same automatic scanning continues now, aimed at popular CMS platforms, plugins and server components.

• Enable automatic updates where it is safe to do so, especially for security fixes.
• Subscribe to security announcements from the vendors whose software you use.
• Keep an inventory so that you know what needs patching.
• Remove software you no longer use, since an unpatched, unused component is all risk and no benefit.

For a wider baseline of measures, see the security page.

Making patching easier

Updates are only useful if you can apply them without fear. With Plesk on every plan, you can manage updates in one place, and our WordPress hosting is designed around keeping a CMS current. For a closer look at the practices we recommend, see the security page or the knowledgebase.