Learning from SQL Slammer

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:

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_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerAAAAMSSQLServerCurrentVersion registry subkey (for SQL Server 2000 systems).

When SQL Monitor makes the call to open the registry, it puts the client's data on a stack. Most applications consist of subroutines that perform specific functions. When an application calls a subroutine, the application arranges the data that the subroutine needs in a structure referred to as a stack. As Figure 1 shows, the application puts a return pointer—which contains the memory address of the point in the application to which to return after the subroutine completes execution—on the stack, then adds the necessary variables in allocated buffers on top of the pointer. The subroutine first extracts data from the buffer on the top of the stack—last in, first out—and performs the necessary computations, then continues to extract data until it reaches the return pointer, which directs the subroutine to return control to the application.

The crux of the problem is that vulnerable systems don't carry out proper bounds checking and will accept a request message that's larger than the buffer space allotted for the client data. That data then can overwrite the memory segment along with other memory segments—including the return pointer. As Figure 2 shows, skillfully written buffer overflows input enough data to overwrite the buffers, add malicious commands, and overwrite the return pointer with a pointer that leads to the malicious commands rather than to the requesting application. If the overrun application is executing in a privileged mode, the malicious commands will also execute in that security context, letting the attacker create extensive damage.

Slammer creates a buffer overflow when SQL Monitor initiates a request to communicate with the registry, thus letting the worm execute its malicious commands in a privileged state. The infected system becomes a zombie that the worm uses to find and attack other systems. The worm makes a call to the Windows API GetTickCount function and uses the result as a seed value to generate random IP addresses, then opens a socket on the infected system and continually scans those IP addresses in an attempt to identify and infect other vulnerable systems.

One reason the original Slammer attacks occurred so quickly is that the worm uses UDP instead of TCP, so Slammer didn't need to establish a full TCP connection with each vulnerable system. The only limitation to the scanning activity and continual infection rate was the zombie's bandwidth connection to the Internet and internal servers. An infected SQL Server system could complete between 4000 and 30,000 scans per second, depending on its available bandwidth. Also, a connectionless protocol such as UDP doesn't require a three-way handshake, making it easier for the worm to bypass firewalls and spoof a UDP packet's source address and port.

After Slammer successfully completes a buffer overflow, the worm launches the second piece of its attack—generating a damaging storm of UDP packets between servers over the Internet, thus creating a Denial of Service (DoS) attack. SQL Server 2000 lets several instances of SQL Server run on the same physical machine. Different instances work as individual logical servers. The SQL Server system uses a keep-alive mechanism to determine which instances are active and which are inactive. When an instance receives a packet with the value of 0x0A on UDP port 1434, it generates and returns to the sender a keep-alive packet with the same value. If the first packet has been spoofed to appear to come from another SQL Server system's UDP port 1434, both servers will continually send packets with the value of 0x0A to each other, generating a packet storm that continues until one of the servers is brought offline or rebooted. (The Slammer worm was developed simply to replicate rather than to install backdoors, modify files, or retain access to compromised systems. Slammer doesn't install itself on a system's hard disk but lives only in memory. Rebooting an infected system flushes the memory and removes the worm, but unless further actions are taken, the system can be reinfected quickly.)

In July 2002, Microsoft released a patch for the exploited vulnerability, but many network administrators—no doubt numbed by Microsoft's continual barrage of patches and hotfixes—failed to apply the patch. Also, proper implementation of the patch required administrators to manually edit specific system files, which complicated installation. Furthermore, the patch interfered with SQL Server operations in several situations. When the worm hit, however, sites and ISPs reacted quickly, filtering traffic heading toward UDP port 1434. Fortunately, this port isn't crucial for most Internet communications. If Slammer had attacked a more widely used service and port, such as SMTP port 25, FTP port 21, or DNS port 53, just the act of filtering traffic could have caused more DoS problems. Also, few home users use SQL Server, so Slammer affected a smaller subset of systems than if it had exploited a vulnerability in a more popular service or application.

Recovering and Preventing Future Infections
So how can you ensure that your systems are safe from this worm and others like it? First, determine which of your systems are vulnerable. Several Microsoft articles list susceptible applications, which include Microsoft Application Center 2000, Office XP Professional, Project Server 2002, Visio 2002 Professional, and Visual FoxPro 7.0. (You can find a full list of products at http://www.microsoft.com/technet/security/msdeapps.asp.) Then, determine whether these systems are running an applicable security patch. To do so, look in the systems' mssqlbinn folder for ssnetlib.dll. Systems on which this file has a version number of 8.00.679 or later are safe; systems with earlier versions of the file aren't secure. You can also review the following components to ensure that they have the indicated version: ssmslpcn.dll version 8.00.568, dbmslpcn.dll version 8.00.568, and ssnetlib.dll version 8.00.679. Or you can use the Slammer Vulnerability Assessment Tool (http://www.microsoft.com/technet/security/tools/chklist/svatool.asp).

Second, find and clean any systems that have already been infected. The malicious software (malware) lives only in memory, so rebooting the system will remove the worm.

Before you begin any repairs or updates, however, decide which solutions are best for your environment. Installing different security patches, hotfixes, or service packs on many machines can become confusing, so first build a matrix that lists the vulnerable systems in your environment, which susceptible product each system runs, and which patches, hotfixes, and service packs have been applied to each system. Then, compare this information with the options that Table 1 shows. The Microsoft article "INF: SQL Server 2000 Security Update for Service Pack 2" (http://support.microsoft.com/?kbid=316333) describes the updated SP2 security patch, which Microsoft refined and rereleased in Microsoft Security Bulletin MS02-061 after Slammer hit. The new version of the patch doesn't require manual configuration and doesn't cause the disruptions that the earlier version caused. You can also use the tools available in the SQL Critical Update Kit (http://www.microsoft.com/sql/downloads/securitytools.asp) to remove the worm and patch infected systems. And of course, SQL Server 2000 SP3a (http://www.microsoft.com/sql/downloads/2000/sp3.asp) contains all the fixes in both SP2 and SP1. Regardless of which path you take, make sure to install any patches and service packs on test servers before installing them on your production servers. Many patches fix one thing but break another, so test them fully before deployment.

What other steps can you take, aside from applying the necessary patches or service packs? Run SQL Server as a low-privileged local account instead of a more powerful domain or SYSTEM account. Doing so ensures that if a buffer overflow occurs, the attacker's commands won't execute at a high privilege. Make sure that your routers and firewalls block UDP port 1434 through ingress and egress filtering; communications with a SQL Server system's UDP port 1434 rarely need to take place over the Internet. Many environments use a Web-based front-end system that can accept requests from external clients and make the call to the SQL Server system internally rather than permitting a direct connection between external entities and the database. Be sure that you understand how data needs to flow to the databases and to applications that install MSDE 2000 before you shut down this type of traffic, though, or you could accidentally generate a DoS in your environment.

Last, just because a patch is difficult to implement is no excuse not to roll it out. And if a patch negatively affects an application's functionality, as the original SP2 patch did, look at the vulnerability that the patch addresses and determine whether you can take some other action to protect your systems. In this case, administrators could have properly configured ingress and egress filtering and accomplished much the same security as if they'd applied the patch.

Ready for Anything
Slammer marks an important step in the evolution of computer worms because of its simplicity and speed of infection, and the worm's success opens the door for similar but more dangerous worms. If a worm could scan and infect systems as quickly as Slammer did, then lay dormant so that its activity quickly came to a halt, identifying and cleaning the thousands of infected hosts would be a nightmare. Hindsight is twenty-twenty, but Slammer's original attack was a painful lesson of why administrators and security professionals need to stay vigilant and make sound architectural decisions. Applying patches, fortifying perimeter devices, and watching for excessive traffic to UDP port 1434 can be tiring and continual processes but really are the only protection against a worm such as Slammer, which most likely will continue to cause problems for organizations that fail to take these measures. For more information about Slammer, visit http://www.microsoft.com/technet/security/virus/alerts/slammer.asp, http://isc.incidents.org/analysis.html?id=180, or http://www.eeye.com/html/research/flash/sapphire.txt.