Silence of the Worms
Silence of the Worms
What you are about to read is a dramatized scenario of how computer attackers and security mistakes can damage an organization. While fictional, the narrative is based on real-world attacks described in the media and in my experience dealing with computer attacks at commercial enterprises. As you may expect, all names have been changed to protect both the innocent and the guilty. At each stage of the game, we will point out the attacker's moves as well as the mistakes made by the victim organization. By learning from the mistakes of others, we can all improve our defenses.
And now, close the blinds and dim the lights. Grab some popcorn and snuggle up to your computer screen, as the curtain rises on our play, Silence of the Worms.
Meet Hannibal Cracker
Hannibal Cracker wanted to "own" some computer systems. Not "own" in the sense that he had title and deed to the machines; he wanted complete remote control of other people's computers. Hannibal wasn't an attacker for glory and fame. Cold, hard cash was his prize. Hannibal Cracker had a lifestyle to maintain: an appetite for travel, some debts accumulated over the years, and a desire for cool electronic gadgetry. The economic situation of Hannibal's country was pretty bleak, and Hannibal, a computer expert, had recently lost his job. Hannibal was pretty good at slinging code, and he fancied himself something of a security expert.
Hannibal cooked up a scheme to make a little money from a computer attack. To understand his scheme, let's look at the world viewed by Hannibal, as shown in Figure 1. Hannibal had a computer connected to the Internet, shown wearing a black hat. As we've all learned through various major attacks in recent years, the Internet is the home of enormous numbers of vulnerable computers, shown as machines sitting on the yellow cloud. Many of these machines are operated by unsuspecting potential victims, folks such as you and me. In our scenario, one such potential victim was Clarice Commerce, a medium-size online financial site that allowed customers to engage in generic financial exchanges. The Clarice Commerce network is the blue cloud.
){kind=link}
Figure 1 Silence of the Worms, a scenario.
Hannibal's attack was to be carried out by a worm. For the uninitiated, worms are self-replicating computer attack tools that crawl from vulnerable system to vulnerable system across a network, such as the Internet. Because a worm uses its most recent victims to find even more victims, a skillfully written worm spreads exponentially, potentially compromising hundreds of thousands or more computers in less than a day.
As shown in Figure 2, Hannibal released his homegrown worm. While he employed some of the publicly available code for worms on the Internet, he used his programming skills to tailor the worm to his own desires. This wasn't one of those loudmouth worms that you read about all of the time, like Code Red or SirCam, which spread rapidly in July and August 2000. Although a lot of worm writers look for quick fame by creating a program that defaces Web sites or launches floods against the White House, Hannibal's worm attempted to keep quiet.
){kind=link}
Hannibal's silent worm propagated to several systems on the Internet, taking them over using a buffer overflow attack. Buffer overflows are one of the most common attack types on the Internet today; they involve sending more data into a program than the coders originally expected. By overflowing a buffer, the attacker (or an automated worm) can take over and completely control a victim machine. Thousands of buffer overflow attacks exist. Hannibal selected a new one discovered one month earlier by security researchers and embedded it in his worm. In our scenario, when Hannibal takes control of a new victim, we will show the victim pictorially by displaying a sad face on the victim computer screen (see Figure 2).
Figure 2 Release the worm.
Having taken over its initial targets, Hannibal's silent worm spread exponentially. It randomly generated new addresses for systems to attack in an efficient manner to spread evenly throughout the Internet. Hannibal wanted to cast a wide net. For each new infection, the worm morphed, altering its appearance as it propagated, using polymorphic techniques borrowed from computer virus writers. Polymorphic worms are more difficult to detect, making Hannibal's attack even stealthier. As shown in Figure 3, the worm spread far and wide. Within hours, hundreds of servers succumbed to Hannibal's evil will. In fact, from this point on in the story, whenever Hannibal looked at his computer screen in his dimly lit apartment, scary music started to play.
){kind=link}
Figure 3 The worm morphs and spreads.
After a second round of attacks, the worm spread further and faster. Eventually, Hannibal's worm began to encounter some very interesting servers. Among numerous other systems, the worm took over the Web server of Clarice Commerce, as shown in Figure 4.
){kind=link}
Figure 4 The worm morphs again and spreads to an interesting target.
Mistake #1: Like many others on the Internet, Clarice Commerce failed to install a patch to repair the buffer overflow vulnerability in its Web server. Many software vendors release security vulnerability fixes on a frequent basis. If these patches are not applied in a timely fashion, an attacker can take over a target system. To defend your own systems, you must have an explicit process for determining when patches are available. Someone on your staff should subscribe to vendor and security mailing lists that distribute such warnings, such as the Bugtraq mailing list.
Mistake #2: Clarice Commerce did not configure its systems to minimize security vulnerabilities, allowing the worm to easily take over the machine. Your organization should have detailed security-hardening guidelines, available from some system vendors as well as organizations such as SANS. One important element of hardening critical systems involves inoculating machines against simple buffer overflow attacks by configuring them with nonexecutable stacks. A large majority of buffer overflow attacks simply will not work if the system stack is configured in this way. Keep in mind that nonexecutable stacks can break some programs (so test these fixes before implementing them), and they do not provide a bullet-proof shield against all buffer overflow attacks. Still, preventing the execution of code from the stack will stop a huge number of known and even as-yet-undiscovered vulnerabilities in their tracks.
To create a nonexecutable stack on a Linux system, you can use a free kernel patch. On a Solaris machine, you can configure the system to stop execution of code from the stack by modifying the file /etc/system, as described here. On a Windows NT/2000 machine, you can achieve the same goal by deploying the commercial program SecureStack.