The Blaster Worm of 2003: Reboot Loops and a Message to Bill Gates

On 11 August 2003, computer users around the world began to see an alarming dialog box: a system service had terminated unexpectedly, and Windows would shut down in 60 seconds. Then the machine restarted, and again. The cause was Blaster, also known as MSBlast or LovSan, a worm that attacked a core part of Windows and, hidden in its code, contained a message to Microsoft's founder.

The flaw

On 16 July 2003, Microsoft announced a critical vulnerability in the Remote Procedure Call service that Windows used for DCOM, in bulletin MS03-026. The flaw was a buffer overflow that allowed an attacker to run code on the machine by sending it a crafted request, usually on TCP port 135. It affected most versions of Windows then in common use.

Within weeks, details had circulated in the security community, and proof-of-concept exploits were available. Microsoft and others warned that a worm would likely follow. They were right, and on 11 August the worm appeared.

What Blaster did

Once on a machine, Blaster scanned for other vulnerable computers, beginning from addresses close to its own and also at random, and attacked each one. The side effect was that the exploit, when it did not work perfectly, crashed the RPC service, which led to the forced restart sequence. For many people this was the first sign they had been infected.

The worm had two other features.

• A planned DDoS. From 16 August onward, infected machines were programmed to send a flood of requests to windowsupdate.com, the site Microsoft used for distributing patches.
• A message. Text inside the program, not displayed to the user, read in part: "billy gates why do you make this possible ? Stop making money and fix your software!!"

Microsoft responded to the planned attack by removing the name windowsupdate.com from the DNS, so the infected computers had nowhere to send their traffic. The company moved its update distribution to a different address, and users could still obtain patches.

Impact

A very large number of computers were infected, and companies and public bodies around the world reported disruption. Cleanup consumed the time of IT staff, and the boot loop made it hard to download the necessary fix. Users were advised to disconnect from the network, then patch and clean.

The worm appeared a few days before a large power outage hit parts of the northeastern United States and Canada on 14 August. Some people speculated about a link. The official investigation by a joint US-Canadian task force concluded that the blackout had other causes, including problems with trees, alarms and operating procedures at a utility.

Soon after Blaster, another worm named Welchia, or Nachi, appeared. It attacked the same flaw, but it attempted to download and install Microsoft's patch and then remove Blaster. Although its aim was seemingly benevolent, it caused heavy network traffic and its own disruption. It illustrated why security professionals do not accept unauthorised "helpful" code: even a worm with good intentions changes systems without consent and can cause damage.

The Blaster outbreak also highlighted the importance of the window between disclosure and exploitation. The vulnerability was announced on 16 July, working exploit code was circulating within days, and the worm arrived less than four weeks later. In earlier years, that interval had been much longer. It has continued to shrink, and for some flaws today, attacks start within hours of a public announcement. The practical conclusion is that waiting for a convenient moment to patch is a gamble against a clock you cannot see.

Arrests

Federal agents arrested Jeffrey Lee Parson, an 18-year-old from Minnesota, at the end of August 2003. He was accused of creating a variant of the worm, known as Blaster.B, that was modified to include a backdoor. He pleaded guilty and was sentenced in 2005 to 18 months in prison, followed by supervised release and community service. The author of the original Blaster was not publicly identified.

What it changed

Blaster, followed by Sasser the next year, convinced Microsoft that its patching process needed to improve. The firm worked towards automatic updates being switched on by default, and in 2004 released Windows XP Service Pack 2, which enabled the built-in firewall by default. The change blocked a large class of unsolicited inbound connections, and it is an excellent example of safe defaults protecting people who never touch their settings.

The lesson for site owners today

Blaster was possible because millions of computers were reachable on an unnecessary service, running without a firewall and missing a patch that had been published four weeks earlier. For a website, the equivalents are exposed admin panels, unused open ports and delayed updates.

• Switch on automatic security updates where you can.
• Run a host firewall that blocks everything you do not explicitly need.
• Do not expose management ports such as remote desktop, databases or control panels to the whole internet, if you can limit them to trusted addresses.
• Keep your server's operating system up to date, and plan restarts for patches.

If you need full control of your own server, a VPS is the usual next step.

Safer by default

With managed hosting, much of this is handled for you at the server level. See our hosting plans for the options, and if you operate your own VPS, the knowledgebase can help you configure the basics.