The Database as a Networked Server - Implementing Database Security and Auditing - page 85

routers and firewalls with the amount of network traffic that was being gen-
erated. As an example, utilizing the lightweight CPU on my laptop, SQL
Slammer generates more than 120,000 packets per second.
SQL Slammer is a perfect example of why network attacks are so deadly
and why attackers often resort to network attacks; if done correctly, an
attack can propagate at an exponential speed. Networks (and the Internet in
particular) are so interconnected that if an attacker can figure out how to go
through a hole in network security systems, he or she can wreak havoc on
almost anyone. Connectivity is so ubiquitous that 100 well-connected
machines that randomly scan other machines to which they have routes can
infect the entire Internet in 10 minutes. SQL Slammer exploited a bug in
SQL Server, but the real attack was on the network. The bug allowed an
attacker to make SQL Server do some things it was never supposed to do,
including infecting other database servers with a copy of the worm. Because
it used a legitimate port that is part of the default setup of SQL Server,
many firewalls that are charged with network security simply let the worm
pass right through.
SQL Slammer uses a buffer overflow vulnerability in the SQL Server
Resolution service. The vulnerability exists in SQL Server 2000 before Ser-
vice Pack 3 and MSDE 2000. Much of Slammer's success is a result of
MSDE rather than real SQL Server servers. MSDE is a database engine
based on SQL Server 2000 that is embedded in various Microsoft products,
such as the Office development environment and Visual Studio. The attack
was propagated by developer workstations, not only by SQL Server data-
base servers.
The resolution service normally runs on UDP port 1434 and is used to
initiate connections. When the SQL Server 2000 client netlib first connects
to SQL Server 2000, only the network name of the computer running the
instance and the instance name are required. When an application requests
a connection to a remote computer, dbnetlib opens a connection to UDP
port 1434 on the computer network name specified in the connection. The
server returns a response, listing all the instances running on the server
(supporting, for example, named instances and clustering architectures).
For each instance, the response reports the server netlibs and network
addresses the instance is listening on. After the dbnetlib on the client com-
puter receives this packet, it chooses a netlib that is enabled on both the
application computer and on the instance of SQL Server and connects to
the address listed for that netlib in the packet.
The vulnerability involves a buffer overflow condition. An attacker
exploits the vulnerability by sending specially crafted packets to the resolu-