As business users resumed to work on Monday morning, turning on computers
with MS SQL Server 2000 and MSDE 2000, we monitored a second major peak in network
load especially on nameservers. This timed with the business starting hours in
Europe. A third, smaller peaks be seen later when business day started in USA.
The three load peaks (one from Saturday and two from Monday) can be seen in this
graf from Matrix NetSystems taken on Monday the 27th.
We do not expect to see major traffic peaks from this worm anymore.
BACKGROUND
The outbreak of worm was detected in the Internet on 25th of January 2003
at 05:30 GMT. After that it has been detected from most
countries around the world. However, there are unconfirmed reports of
the worm traces being spotted already on January 20th.
The worm generates massive amounts of
network packets, overloading servers and routers and slowing down
network traffic. According to many reports, as many as 5 of the 13
internet root nameservers were down because of this during Saturday
the 25th.
This worm does not infect typical end user machines at all: it only
infects computers running Microsoft SQL Server 2000 or MSDE 2000.
End users might only notice this worm because of network slugginess.
This worm is not a massmailer: it does not send any e-mails.
The worm only spreads as an in-memory process: it never writes
itself to the hard drive. In this sense it is similar to the Code
Red from July 2001.
The worm uses UDP port 1434 to exploit a buffer overflow
in MS SQL server. Close down this port on your firewall unless
you really need to have your SQL servers visible to the world.
As the worm does not infect any files, an infected machine can be
cleaned by simply rebooting the machine. However, it will soon
get reinfected if the machine is connected to the network without
applying relevant patches for MS SQL Server.
The effects of the network overload can clearly be seen in this
graf from Matrix NetSystems taken on Saturday the 25th.
The worm might have been started off with a hitlist of a thousand
or so vulnerable machines (along the lines of Warhol worms) to make
initial spreading faster.
Only machines running Microsoft SQL Server 2000 are infected by this worm. However, the SQL server
is embedded inside MSDE 2000 - Microsoft Data Engine 2000.
In addition, there are lot of other applications that might silently install Microsoft SQL Server or MSDE 2000. Examples of such software are:
Microsoft Biztalk Server
Microsoft Office XP Developer Edition
Microsoft Project
Microsoft SharePoint Portal Server
Microsoft Visio 2000
Microsoft Visual FoxPro
Microsoft Visual Studio.NET
Microsoft .NET Framework SDK
Compaq Insight Manager
Crystal Reports Enterprise
Dell OpenManage
HP Openview Internet Services Monitor
McAfee Centralized Virus Admin
McAfee Epolicy Orchestrator
Trend Micro Damage Cleanup Server
Websense Reporter
Veritas Backup Exec
WebBoard Conferencing Server
etc.
Are you unsure if your machine is running MS SQL Server 2000 or MSDE 2000? These programs
install an icon to System Tray. An icon which looks like a computer with a white
circle and a green 'Play' button on it:
If you don't trust the systray icon, an easy way to find out if you are running the SQL server is to locally check if your UDP port 1434 is open. To
do this, click Start/Run and type "netstat -p udp -a 100". Then investigate if the
output contains line like "UDP YOURCOMPUTERNAME:ms-sql-m". If it does, you might
be running MS SQL 2000 and you should apply relevant patches. To exit this display,
hit Ctrl-C.
Technical details
The worm code is 376 bytes in size which suggests that is was
written and hand optimized using the Assembly language.
The worm does not write itself to the disk. It exists only as
network packets and in running processes on the infected
computers. In this respect Slammer is similar to CodeRed.
Slammer exploits a buffer overflow vulnerability in Microsoft
SQL Server 2000 (MS02-039). When the SQL server receives the
malicious request the overrun in the server's buffer allows the
worm code to be executed.
After the worm has entered the vulnerable system first it gets
the addresses to certain system functions and starts an infinite
loop to scan for other vulnerable hosts on the Internet.
Slammer uses GetTickCount() function from the Win32 API to
initialize it's random number generator. It uses the random
numbers as IP addresses to search for vulnerable hosts. The worm
does not try IP addresses sequentally - it gets a new random
address for every infection attempt.
The worm uses a socket to send itself to to the vulnerable computers. The
socket in connected to the UDP port 1434 on the remote machine.
If the computer has Microsoft SQL Server 2000 it runs on that
port.
Sometimes the random generator returns numbers that are broadcast
addresses (eg.: x.y.z.0 or x.y.z.255) causing all the hosts on
the particular network to receive the malicious packet. In many
scenarios, this could infect several SQL Servers in the subnet
at the same time. This makes the spreading routine even more aggressive.
At the very least hitting broadcast addresses multiplies the network
load generated by the worm.
This picture shows a fragment of the virus code
Since the worm code does not have any delay in the scanning loop
it generates massive amount of network traffic as a side effect.
Slammer does not have any intentional payload or strings inside.
Detection
F-Secure created a special detection tool for the Slammer worm.
This tool is able to scan the computer's memory and find the active
Slammer infection.
Since the worm does not reach the disk on the infected computer
it disappears when the server is restarted. On the other hand the
server might get reinfected if the security problem is not fixed
by applying the Microsoft patches.
[Mikko Hypponen, Gergely Erdelyi; F-Secure Corp, January 25th, 2003]
