The Slammer Worm Virus of 2003

It was predicted that some day a virus would spread throughout the internet in less than an hour. This prediction came true early in 2003, when the Slammer Worm was unleashed. In the following paragraphs, I will discuss what occurred during the attack, which systems were vulnerable, and the extent of damage caused. Then, I will explain how the virus was eliminated and what could have been done to avoid infection. The final areas of discussion will focus on the long-term effects of this network threat and some conclusions I’ve drawn from my research.

At approximately 1230 a.m. EST on January 25, 2003, the Slammer Worm was received by its’ first victim. This worm, also know as Sapphire or W32.SQLExp, immediately began generating clones of itself and instructed the infected system to query random hosts across the internet. Whenever a query hit another vulnerable host, that host would become infected and continue the same clone and scan process. Within three minutes, there were fifty-five million database queries traversing the internet every second. The worm was so swift it infected all 75,000 vulnerable hosts in approximately fifteen minutes. With that many hosts sending out random scans across the globe, the internet was virtually shut down. The bulk of the increased traffic occurred in the first few hours and slowed substantially by the end of the day. However, traffic analysis still showed remnants of the attack throughout the following week. This was primarily due to the fact that some hosts picked up the worm when they began operations on Monday morning. How was Slammer able to penetrate defenses and move so quickly?

The virus infected a host by exploiting a bug in Microsoft Sequel (MS-SQL) software. Any host connected to the internet running an unpatched version of MS-SQL Server 2000 was vulnerable to this attack. The worm was able to spread so quickly because it was very small, 404 bytes, and was sent using the User Datagram Protocol (UDP). UDP is faster Transfer Control Protocol (TCP), because it is connectionless, which means the worm didn’t have to wait for acknowledgement from a host before continuing. When the Slammer worm finds a host, it uses the buffer overflow vulnerability to hide its’ intentions. The initial string of characters in the request contains a series of 01s to fill up the 128K of memory. Once the memory is filled, the remaining bits overflow into and overwrite the instruction stack. At this point, the host is reprogrammed to do what the Slammer’s author had intended. It began by using the system time as an IP address, then forwarding a copy of the original worm code to that address. The host then shuffled the bits of the manufactured IP to create a new address for another forward. This process continued in a loop fashion for every host infected. Since these hosts are powerful servers with high-speed connections, it’s easy to see how the internet could be flooded in very little time. What were the effects of this speedy piece of malicious code?

The primary result of the Slammer Worm was Denial of Service (DOS) for many hosts across the globe. The worm traffic was so intense, that internet servers could not keep up. For an illustration, figure 2 shows a view of the internet thirty minutes after the attack captured by the Akamai Network Control Center. The lines indicate jammed server-to-server connections. For another view, figure 3 shows how Slammer had spread across the globe in that same thirty minutes. While nothing was actually destroyed from this attack, there was lost revenue estimated around $1 billion. South Korea was the hardest hit country, where 27 million people lost internet and cell phone usage. In Australia, the American Express website had to be closed for several hours and Bank of America customers were unable to use 13,000 Automated Teller Machines. While South Korea was the hardest hit, because its’ network isn’t as robust, the United States had the most traffic. As a result, several businesses and government agencies were negatively affected. Some of problems attributed to the worm include: the Davis-Besse nuclear power plant in Ohio was disabled for five hours, Continental Airlines had to cancel some flights, Country-wide Financial closed its’ website for the day, and Seattle’s Emergency 911 operators had to resort to manual operations. All these problems created by the Slammer lead to the following questions. What was done during the outbreak to eliminate the threat and what should have been done to avoid it altogether?

The Slammer Worm spread so quickly, it was impossible for network personnel to react fast enough to avoid contamination. However, the response to eliminate the virus was quite substantial. Within an hour, most sites had instituted filtering of port 1434. This action blocked the traffic and enabled those sites to install the fix for the vulnerability. Once all sites had been patched, the threat ended. This brings us to the root of the problem, which is patch management. The software update to fix this vulnerability had been available for six months. If all SQL server hosts had installed the patch, Slammer would be a figment of our imagination. What else could have been done to avoid Slammer?

In the real world, we know everyone isn’t able to install all required patches due to any number of resource constraints. However, there are other measures that could have been taken to improve a corporation’s network security. One key area of concern is the presence of corporate backdoors into secure systems. While some of those backdoors are inevitable, it is important for every business to have a sound security posture. An example of this type of posture comes from Cisco Systems. They have instituted a six-phase set of best practices which helped them avoid Slammer contamination. I will summarize these phases in the table below:

Preparation

Having the people, processes, procedures, architecture, and tools in place.

Identification

Products and technologies used on routers help identify abnormal traffic.

Classification

Knowledge of architecture and traffic patterns aids in classifying threats.

Traceback

Allows identification of all sources of potential attack, such as VPNs or laptops.

Reaction

Cisco immediately used Access Control Lists throughout their entire network.

Postmortem

Conducted daily sessions for 2 weeks, discussed status and lessons learned

Now that we know how Slammer could have been avoided, let’s look at the long-term ramifications from this attack.

While the attack did cause a lot of panic and brought with it a healthy price tag, there weren’t really any negative long-term effects. The worm was virtually eliminated in a very short time and it wasn’t destructive in nature. In my opinion, I see many positive effects from this network threat. I believe the Slammer Worm helped to ‘wake up’ many corporations to the fact that this type of threat exists and they need to take it seriously. This worm could have had a very destructive pay load and caused unheard of damage. It could have been released during the business week and wreaked much more havoc. Who knows what the lost revenue could have been? Therefore, it should be considered a relatively cheap lesson-learned that brought about heightened awareness and, undoubtedly, an improved security posture for many businesses throughout the world.

In conclusion, we must realize the threat is real. Software vulnerabilities can be an open door to a shutdown of the online world. As the telephone world merges with the internet, the world will become more and more reliant on online connectivity in all walks of life. These new technologies also bring new opportunities for malicious behavior. Security against these threats is of the utmost importance.

Now, I will summarize the preceding paragraphs. We looked at the events surrounding the Slammer Worm and which systems were susceptible. Then, I explained the damages caused during the attack. I followed that with the method used to eliminate the virus and provided a detailed description of ways it could have been avoided. And finally, I discussed the long-term effects caused by the attack, including my own drawn conclusions. Unfortunately, human nature dictates that malicious behavior is inevitable. The question is, how will we deal with it?

References

Boutin, Paul. Slammed! July 2003. 22 September 2005. http://www.wired.com/wired/archive/11.07/slammer.html>

Moore, Paxson, Savage, Shannon, Staniford, & Weaver. The Spread of the Sapphire/Slammer Worm. 22 September 2005. http://www.caida.org/outreach/papers/2003/sapphire/sapphire.html>

Beverly, Robert. MS-SQL Slammer/Sapphire Traffic Analysis. 20 September 2005. http://momo.lcs.mit.edu/slammer/>

Poulsen, Kevin. Slammer worm crashed Ohio nuke plant network. 19 August, 2003. 21 September 2005. http://www.securityfocus.com/news/6767/>

Barry, David. Proactive Protection. 2004. 23 September 2005. http://www.cisco.com/warp/public/784/packet/jan04/pdfs/PK16108B_SPS.pdf>