< Back to Articles
August 2003
Learning from SQL Slammer
Protect yourself from future attacks
by Shon Harris
The SQL Slammer worm—aka Sapphire or SQL Hell—was only 376 bytes when it appeared on January 25, 2003. Yet Slammer, deemed the fastest computer worm in history, raced around the Internet infecting 90 percent of vulnerable computers within 10 minutes (according to several sources, including Microsoft). Slammer doubled its number of victims every 8.5 seconds; the extremely damaging CodeRed worm took about 37 minutes to do the same. Slammer was scanning approximately 55 million systems per second within 3 minutes of its release. By 10:00 a.m. on January 26, several ATMs were unable to process transactions, many Internet links were overwhelmed with traffic, several root DNS servers were unavailable because of the degradation of bandwidth on certain links, and approximately 120,000 computers were infected. The worm's scanning activity finally slowed, mainly because the increasing amount of traffic it generated restricted the available bandwidth. Eventually ISPs started blocking the type of traffic that the worm generated, further slowing Slammer's scanning and repopulation activities.
Many people might have heard of the Slammer worm, but few people fully understand the root of the attack. Familiarizing yourself with Slammer's methods can help you evaluate the risk to your environment and prepare for future attacks by similar worms.
The Root of the Problem
Systems running the following are vulnerable to Slammer's type of attack:
- Microsoft SQL Server 2000 Service Pack 2 (SP2), SP1, release to manufacturing (RTM), or SQL Server 2000 Evaluation Edition
- Microsoft SQL Server Desktop Engine (MSDE) 2000 SP2, SP1, or RTM
- Any application that installs MSDE 2000 SP2, SP1, or RTM without the necessary hotfixes: MS02-061 (Elevation of Privilege in SQL Server Web Tasks), MS02-056 (Cumulative Patch for SQL Server), MS02-043 (Cumulative Patch for SQL Server), and MS02-039 (Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Execution)
MSDE provides a code base for programmers so that they don't need to manually write base code for their products. One reason that so many systems are vulnerable to worms such as Slammer is that many IT departments don't know which applications were built using MSDE and thus which systems need to be patched.
To communicate with SQL Server, client systems can use one of two interprocess-communications methods: sockets on TCP port 1434, or named pipes over a NetBIOS session on TCP ports 139 or 445. Sockets, which are interfaces through which applications can communicate using the TCP/IP stack, use a combination of IP addresses and port numbers. Named pipes, which are actually shared memory segments that applications and NetBIOS use for process communications, don't use port numbers but require processes to exchange specially formatted requests.
Clients don't usually know which method of communication a SQL Server system is configured to use, so they probe the server to determine how future communications should take place. The client software sends a message to the SQL Server Resolution Service operating on the server's UDP port 1434. Microsoft SQL Monitor listens on this port and responds to incoming client requests, indicating which communications method to use. When the server receives this type of request, it accepts all the data in the request packet, and the SQL Monitor thread opens the registry and reads the value set for the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\AAAA\MSSQLServer\CurrentVersion registry subkey (for SQL Server 2000 systems).
When SQL Monitor makes the call to open the registry, it puts the client's |
