So Many Worms, So Little Time

Introduction

Let’s face it; the Internet is a dangerous place, and it’s not getting any better. Statistics show a rapid increase in the rate of Internet-based attacks. The ability of attackers to rapidly compromise large numgers of system poses a “real and present danger” to the overall security of the Internet. A thousand zombie hosts can cause a lot of damage, but the damage that can be caused by the tens of thousands that can be taken over by an Internet worm are staggering.

A Bit Of History

The Internet had its beginnings back in 1965 when ARPA sponsored a study on the “cooperative network of time-sharing computers”. By 1966, the first ARPANET plan was developed. Over time this simple experimental network grew into what is know as today’s Internet. Interestingly, in 1985 the ARPANET was brought to its knees by on 27 October because of an accidentally-propagated status-message virus. This was not the first virus however.

As early as 1949, self-replicating programs were being developed, and in 1981, several viruses were infecting the Apple world. The first computer viruses were simple because the computing capability was so limited. Most early viruses would simply copy themselves to a new location, then progress from there. Eventually, as more computing power became available, more complex viruses were developed. This included the addition of code to be executed once the virus had replicated itself to a new disk or computer.

Computer “worms” were first considered as a means of automating network management tasks. Experiments were performed at Xerox Palo Alto Research Center in 1982. The key problem noted was controlling the propagation of these programs. This became especially apparent to a young Robert Morris; a 23 year old doctoral student at Cornell University. Morris unleashed a worm on the Internet, not realizing that he had drastically miscalculated the rate of propagation and the impact it would have on compromised systems. The worm spread at a phenominal rate, must faster than originally intended. When Morris realized his worm was spreading faster than he anticipated and tried to post removal instructions. Unfortunately, these instructions were not received because most administrators had removed themselves from the Internet.

The worm infected over 6,000 machines across the country and, while no physical damage was caused by the worm, between $100,000 and $10,000,000 was lost due to lost access to the internet at an infected host (According to the United States General Accounting Office). Morris was sentenced to three years of probation, four hundred hours of community service, $10,050 in fines plus the cost of his supervision.”

The worm era really seemed to take of in the late 1990’s. There was a sharp increase in the frequency and number of worms, as well as the damage they caused. A very short list of the most memorable worms includes:

• Melissa in 1999
• Code Red, Nimda and Ramen in 2001
• Slammer and Blaster in 2003.

Less Time To Respond

Along with the increasing number of worms, there is a disturbing trend; reduced time between the discovery of vulnerability to the time of active propagating code. Code Red raised security community awareness in that it was able to infect more than 359,000 computers connected to the Internet in less than 14 hours. The cost of damages incurred by Code Red and its subsequent strains was estimated to be in excess of $2.6 billion! The rapid spread of Code Red led to the hypothesis of a faster spreading worm which came to be called a “Warhol Worm“. A Warhol Worm would be capable of infecting all vulnerable hosts on the Internet in approximately 15 minutes to an hour. The theory stated that this would be accomplished “by using optimized scanning routines, a hitlist scanning for initial propagation, and permutation scanning for complete, self coordinated coverage.

Theory became reality on Friday, 19 March 2004, at approximately 8:45 p.m. Pacific Standard Time (PST). The Witty Worm began its spread, but this attack was unlike anything seen previously:

• It began to spread the day after the ISS vulnerability was publicized. This represents the shortest known interval between vulnerability disclosure and worm release!
• It was the first widely propagated Internet worm to carry a destructive payload.
• It started in an organized manner, spreading from an initial ‘seed’ of about 110 hosts. This number grew to 160 in the first 30 seconds.
• It reached its peak (supposedly infecting all vulnerable machines on the Internet) in about 45 minutes.
• It affected systems owned by people who were actively trying to security their computers and network.

This assemblage of features presents what appears to be an insurmountable security problem. Previous worms have lagged several weeks behind publication of new vulnerabilities. This has led to a general trend of patch management to protect vulnerable systems. There was generally sufficient time to patch these systems before malicious code was widely circulating. The Witty worm started to spread the day after information about the exploit and the software upgrades to fix the bug were available. We can no longer count on a buffer period in which to patch our systems. We must be on the alert to any new attacks, be ready to implement a multi-pronged defense, and prepared to monitor all systems until the threat has passed.

How Do We Defend Ourselves?

The patch management model of security our systems is a failure. Now don’t misunderstand me. I’m not saying we should not patch our systems; I’m saying we cannot rely on this as a sure defense. In fact, there is no single security measure that will ensure our complete protection. We must employ security countermeasures for every possible avenue of attack.

First and foremost, deploy a defensive perimeter. A firewall is a definite MUST, but don’t stop there. Firewalls should only allow traffic which corresponds to tightly defined rules. Include protections such as file attachment filters for email and via web content filtering. Use internal firewalls throughout the corporate network at various segment intersections. Apply appropriate access-control lists (ACLs) on routers and switches. Implement an intrusion detection system (IDS). Deploy anti-virus protection on servers and email gateways.

Inside the perimeter, examine your demilitarized zone (DMZ). Harden all servers, change all default passwords, and disable unnecessary service and protocols. Consider host-based IDS on critical systems. Check account permissions, file permissions, and trust relationships.

Internal systems need the same level of consideration as external-facing systems. Ensure all workstations are running anti-virus software. All workstations should be hardened, too. Make user end-users have the knowledge and awareness necessary to help protect your environment through regularly scheduled Security Awareness Training. Enforce the use of cryptographically strong passwords. Discourage the use and downloading of unauthorized software and perform regular audits to check for these things.

Develop two critical response protocols. The first of these is a process to assess new threats, determine the vulnerability of your environment, and then develop countermeasures to provide protection until appropriate patches can be applied. If you are vulnerable, consider the following:

• Can the attack be stopped at the perimeter? Can the protocol be disabled? Can the ports be blocked by firewalls/routers?
• If the particular service is critical and cannot be shut down, blocked, or disabled then can the service be moved to another, non-vulnerable system? This is a good argument for diversity. If possible, move from a vulnerable platform to one that is not vulnerable to Linux). True, this requires more overhead for maintenance and administration, but diversity means flexibility.

Next, develop an Incident Response Protocol. You need to know, in advance, how you will need to respond when a system has been compromised. Determine how to quickly identify compromised system and remove them from the network. Response time is critical because even a small number of compromised systems can quickly spread and cause disruptions. Consider the following questions:

• Can the compromise be identified by monitoring traffic patterns?
• What about bandwidth utilization?
• Does the attack open up a backdoor that can readily be identified?
• Once a compromised system has been identified, what’s next?
• Will you take the system offline?
• Will you cordon off that network segment to prevent the infection from spreading?
• How will you contact external support of the network is down?
• Do you have out-of-band management capabilities?
• If the infection is spread via email, can you quickly block attachments at your mail gateway?
• Will you shut down your mail gateway?

Summary

There is no single security countermeasure, or silver bullet, that can protect our networks completely. Over time the threats have grown in both number and complexity, while the timeframe for response has been shortened dramatically. Previous successful attacks have shown that even those who are well protected and have large budgets and resources can be compromised. We need to be constantly alert, tracking the latest vulnerabilities, and monitoring the health and performance of our networks. Finally, we must have a plan of action in place, with a well trained staff ready to respond at the drop of a hat.

Don’t Panic… Prepare!