A Brief History of The Worm

The first active Internet worm that required no human intervention to spread was the Morris worm released in 1988. It spread very rapidly, infecting all vulnerable machines in a matter of hours. Most recent active worms use the techniques pioneered by Robert Morris. The Morris Worm infected multiple types of machines (Sun 3s and VAXes), attacked multiple security holes (including a buffer overflow in fingerd, debugging routines in Sendmail, and password cracking), and used multiple streams of execution to improve its throughput when attacking other machines.

Although intended to be a benign proof of concept, the Morris worm had a significant impact due to a bug in the code. When it reinfected a machine, there was a fixed chance that the new infection wouldn't quit, causing the number of running worms on a machine to build up, thereby causing a heavy load on many systems. Even on a modern machine, such bugs would have a similar effect of overwhelming the system. This caused the worm to be quickly noticed and caused significant disruption. Most subsequent worms have mechanisms to prevent this from happening.

In 1996, the first Word macro virus appeared and became quickly widespread. This was due to two reasons: the far greater tendency for people to exchange documents, as opposed to executables, and the accidental inclusion of the virus on at least two Microsoft CDs. For the most part these were just annoyances, but they showed how the blurring of data and programs could create fertile ground for mobile code.

All this changed in 1999 when the Melissa worm appeared. Unlike previous macro viruses, this one would spread in a semi-active manner. When an infected file was opened for the first time, it looked through all Outlook address books and sent a copy of itself to the first 50 individuals. This was the first major e-mail worm and it quickly spread around the globe. The Melissa worm clearly illustrated the dangers of mixing code and data: items perceived by the user as benign data could contain malware.

After Melissa, mail worms have become annoyingly common, complete with toolkits. There have been some improvements in social engineering (ILOVEYOU and AnnaKornikova showed how proper subject choice can make a difference in the successful proliferation of a worm,) more comprehensive searches for new addresses, included SMTP routines.

Active worms have recently returned to prominence. The first one that attracted major attention, Code Red, demonstrated how swiftly a relatively simple worm can spread on the current Internet infrastructure: it effectively achieved complete infection in a little over twelve hours, even with the aborted early release of a buggy version. Code Red exploited a recently discovered (but patchable) buffer overflow attack in Microsoft's Internet Information Server.

Code Red 2 ended up being significantly more disruptive then Code Red even if the change in infection strategy was relatively mild. Instead of searching only randomly selected addresses, Code Red 2 preferentially probed for machines on the same subnet and nearby subnets. As a result, once a single machine within a corporate firewall was infected, it would quickly probe virtually every machine within the firewall and since it was attacking an on-by-default service, Code Red 2 quickly infested entire corporate networks.

Nimda
The latest worm of note, Nimda, did not really bring anything new to the table. It simply resurrected the idea of multimode operation: it was an e-mail worm, it attacked old bugs in Explorer and Outlook, spread through Windows shares, and an old buffer overflow in IIS. It also borrowed Code Red 2's preference for logically adjacent IP addresses in its scanning routines. The net result was a highly virulent, highly effective worm that revealed that several old bugs can be used even if each hole is patched by most machines: one needs all patches and vulnerabilities closed to stop a Nimda-like worm. Such a worm is also somewhat easier to write, as one can use many well-known exploits to get wide distribution instead of discovering new attacks.

The biggest lesson from both Code Red and Nimda is the sheer speed with which these fairly simple active worms can spread. By the time humans detect the presence of worms on the Net, through firewall activity or probes of monitoring IP ranges, they may well have spread worldwide.

Minimizing the Spread

The best way to defend against worms is obviously to prevent infection - once a single machine within a local subnet is infected it may be too late. One obvious defense is diversity, using less common operating systems and servers. Assuming there is no way to directly find vulnerable machines, the rate at which a worm spreads is directly proportional to the number of vulnerable hosts. This is because with fewer potential targets any given random probe is less likely to find a vulnerable machine, limiting the rate of spread. Thus, if one only has a few machines open to the wide internet, using a less common (i.e., non-Windows) OS offers an advantage, as there are less likely to be worms written for less common platforms, and those which are created will spread more slowly.

For example, Linux has had it's own fair share of worms, such as Ramen, Lion, and Cheese. But since the Ramen worm only attacked Red Hat 6.2 and 7.0 systems, it couldn't spread very fast when compared to Code Red, simply because the odds of any particular scan finding a vulnerable target are so much lower when compared to Windows worms. As an additional side benefit, most attempts to construct a worm for the purpose of wholesale information terrorism will target the most common platform, currently Windows, to increase the spread and damage done.

Firewalls are also essential to prevent both active worms as well as human intrusion. But external firewalls are not sufficient for larger institutions. With multimode worms like Nimda and local scanning worms such as Code Red, it becomes critical to split large internal networks with internal firewalls. Such a design is akin to how ships are designed with watertight compartments, the result being that a single intrusion should not allow a worm free reign in the corporate network.

Similarly, all executable content which crosses the firewall should be regarded as suspicious, especially e-mail. All macros and programs sent in e-mail should be quarantined to prevent future mail worms from spreading. There should be severe limits on what is allowed to cross firewalls, with a general attitude of "that which is not explicitly allowed is forbidden." If available, operating system options which only allow cryptographically signed code should be exercised, executable stacks should be disabled, and bounds-checking modifications should be used at all times.

Finally, there needs to be continued development of firewalls and anti-virus systems that detect and autonomously respond to new attacks. Since new viruses can spread much faster than humans can respond, the defenses need to be automated. Pure pattern matching methods, suitable against file and macro viruses or human-run exploit scripts, are not sufficient to defend against worms because worms can spread faster than updates are created. For the same reason anti-worms are not generally effective since by the time an anti-worm is ready for release it will be far too late.

Conclusions
Once a system is infected, there is not much that can be done to mitigate the damage. Regular backups are critical, as a malicious worm could easily overwrite or corrupt the existing data. Any reflashable BIOSes should be write-protected while software control of voltages, overtemperature set points, and clock rates should be disabled to prevent a malicious program from stressing a CPU through overtemperature and overvoltage conditions. Machines containing particularly sensitive information need to be completely isolated from the Net to prevent a SirCam-style worm or determined hacker from extracting information.