Worm:W32/Slammer sparked off a major epidemic in January, 2003. Slammer exploited a buffer overflow vulnerability in Microsoft SQL server 2000 in order to propagate.
Based on the settings of your F-Secure security product, it will either move the file to the quarantine where it cannot spread or cause harm, or remove it.
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. For patch information, see:
A False Positive is when a file is incorrectly detected as harmful, usually because its code or behavior resembles known harmful programs. A False Positive will usually be fixed in a subsequent database update without any action needed on your part. If you wish, you may also:
Check for the latest database updates
First check if your F-Secure security program is using the latest detection database updates, then try scanning the file again.
Submit a sample
After checking, if you still believe the file is incorrectly detected, you can submit a sample of it for re-analysis.
NOTE If the file was moved to quarantine, you need to collect the file from quarantine before you can submit it.
Exclude a file from further scanning
If you are certain that the file is safe and want to continue using it, you can exclude it from further scanning by the F-Secure security product.
Note You need administrative rights to change the settings.
Worm:W32/Slammer was first detected on the Internet on 25th of January 2003 at 05:30 GMT. After that it was detected in 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 emails.
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.
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 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.
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.
The initial report of the worm can be seen here: http://online.securityfocus.com/archive/1/308306
Though no infection occurred and infected machines could be cleaned simply by rebooting, reinfection was possible if the vulnerability remained unpatched with the necessary updates from Microsoft.
For more information, including the patch, see:
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.
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:
For master list for MSDE apps, see http://www.microsoft.com/technet/security/MSDEapps.asp
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.
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.