Skip to content

Personal tools
You are here: Home » SQL Server » SQL Server Articles Archive » Preventing SQL Worms
Seeking new owner for this high-traffic site.
Tap into the potential of this DBA community to expand your business! Interested? Contact us today.
Who Are You?
I am a:
Mainframe True Believer
Distributed Fast-tracker

[ Results | Polls ]
Votes : 3555

Preventing SQL Worms

by John Paul Cook

Most of the damage caused by SQL worms targeting SQL Servers could easily have been prevented by applying service packs to SQL Servers prior to the attacks. Properly configured firewalls could have limited propagation of the worm. SQL worms are a far greater threat than many people realize because there are many SQL Servers out of sight and out of mind. Since SQL 7, the SQL Server database engine has been offered for free as MSDE, Microsoft Desktop Engine. MSDE 1.0 is the SQL 7 engine; MSDE 2000 is the SQL 2000 engine. MSDE is effectively limited to five connections, two gigabyte databases, and does not come with any tools such as the Enterprise Manager or the Query Analyzer. Any strategy put in place to protect against SQL worms and other threats must protect both SQL Servers and MSDE installations.

MSDE may be installed as part of an Office XP Developer Edition, Visual Studio .NET, Web Matrix, or other Microsoft product installation. Untold numbers of third-party applications install and use MSDE behind the scenes.

Finding SQL Servers Including MSDE

SQL Servers (for the rest of this article, this term includes MSDE) are applications named sqlservr.exe (not sqlserver.exe). There can be multiple copies of sqlservr.exe installed on a machine as long as each is in its own directory. You can identify instances of SQL Server by searching for sqlservr.exe, but keep in mind that by default, XP and Windows 2003 Server do not search all folders as the following screen capture shows:

It is possible that SQL Server could have been installed to a location other than the default. Be sure to check Search hidden files and folders before starting your search.

A faster and more convenient way to find SQL Servers on a machine is to use the Services applet under either Administrative Tools or Computer Management (which is itself under Administrative Tools). On XP, Administrative Tools is not visible by default. To make it visible, right-click on the Start button, select Properties, click the Customize button, click the Advanced tab, scroll to the bottom of the Start menu items list and make a selection to Display the System Administrative Tools. The following screen capture from a Windows 2003 Server shows the Services applet. Because of space considerations, only a few services appear in this screen capture.

SQL Servers are installed as services and may be installed as either what is known as a default instance or a named instance. A default instance of SQL Server has a service name of MSSQLSERVER. Named instances begin with MSSQL$. As you can see, the first three entries shown in the preceding screen capture indicate that there are three SQL Servers installed. MSSQLSERVER is the default instance. MSSQL$NetSDK and MSSQL$WEBMATRIX are named instances. They are intended for use by software developers and may not be as properly secured as a production database should be.

All three SQL Servers are running with elevated privileges. It would be safer to run a SQL Server service under the context of a domain user account instead of a domain administrator account or Local System. The same is true of the SQL Server Agent service accounts. For more information, go to the Microsoft site for SQL Server and download these security whitepapers:

You can also go to Control Panel, Add/Remove Programs to find instances of SQL Server installed on a machine. They will not necessarily be grouped together as they are in the Services applet.

Identifying Versions

You can determine if an instance of a SQL Server is the full version or the MSDE version by connecting through osql or the Query Analyzer and running this command:

select @@version

Microsoft SQL Server 2000 - 8.00.194 (Intel X86)
Aug 6 2000 00:57:48
Copyright (c) 1988-2000 Microsoft Corporation
Enterprise Edition on Windows NT 5.2 (Build 3768: )

As you can see, the last line indicates the version of SQL Server. Here is the output from running the command on an MSDE instance:

Microsoft SQL Server 2000 - 8.00.534 (Intel X86)
Nov 19 2001 13:23:50
Copyright (c) 1988-2000 Microsoft Corporation
Desktop Engine on Windows NT 5.2 (Build 3768: )

Now look at the output from another MSDE instance:

Microsoft SQL Server  2000 - 8.00.760 (Intel X86) 
         Dec 17 2002 14:22:05
         Copyright (c) 1988-2003 Microsoft Corporation
         Desktop Engine on Windows NT 5.1 (Build 2600: Service Pack 1)

Do not make the mistake of thinking that SQL Server Service Pack 1 was applied to this instance. In this context, Service Pack 1 refers to the operating system only. You determine the SQL Server Service Pack level by looking at the version number on the first line of the output. The version number 8.00.760 is the proof that SQL Server Service Pack 3 was installed. This is explained in sp3readme.htm, a document that is included in the Service Pack 3 downloaded files. You should read it carefully before applying any version of SQL Server Service Pack 3.

Another way to determine the service pack level of a SQL instance is to run the following command:

select serverproperty('ProductLevel')

A single string is returned. If it is RTM, no service pack has been applied. If the string is SP3, them SQL Server Service Pack 3 has been applied. Do not consider a service pack to be successfully installed until you have used one of these queries to confirm the installation.

SQL Security Tools

Microsoft has tools to help you identify instances of SQL Server that need to be patched. The tools are SQL Scan and SQL Check. You can download them from the Microsoft download center, or you can click here to go directly to the download. These are command line tools. You need to read the readme.txt files that come with these tools and choose the appropriate switches. SQL Scan has the ability to check an entire domain or range of IP addresses.

Preventing Worms

First and foremost, you must keep current on service packs. Currently, SQL Server Service Pack 3 is available for download from:

It is actually three different service packs, one for SQL Server 2000, one for MSDE 2000, and another for SQL Server 2000 Analysis Services. You must download and install the service pack appropriate for which of these components you have installed on the machine. It is important to understand that once the service pack is downloaded, running the service pack executable does NOT install the service pack. It merely unpacks the files needed to install the service pack. You must stop the SQL Server service before a service pack can be applied. You should back up your databases before applying a service pack.

Installing the Service Pack 3 for MSDE 2000 requires that you have administrative rights on the computer. Be sure to read the documentation carefully. The setup.exe is not just for applying a service pack; it will also install an instance of MSDE 2000. To only install the service pack, you will have to apply command line switches as described in the sp3readme.htm help file. You either need to know the instance name or which .msi file was used to install MSDE. As described previously, you can use the Services applet to find the instance names.

The Slammer/Sapphire worm exploits a buffer overrun vulnerability on SQL Server port 1434. Blocking UDP ports 1433 and 1434 at your firewall will protect your server from this worm and many other SQL Server exposures. You can also block your SQL Servers for inbound traffic on UDP port 1434, but this would interfere with name resolution.

MSDE Issues

MSDE requires special attention to the instructions in sp3readme.htm. Not all attempts at applying Service Pack 3 to MSDE have been successful. To log installation problems, use the modified syntax shown below:

setup /l*v c:\msde.log /upgradesp . . .

Additionally, if the MSDE being upgraded has a blank sa password (actually a NULL password, there actually isn’t a password), the installation will fail and show the following error message:

If you choose not to take advantage of the opportunity to fix this security vulnerability, use the following syntax:

setup /l*v c:\msde.log /upgradesp BLANKSAPWD=1 . . .

To change from a NULL password to a real password using osql, use syntax similar to this:

C:\>osql -E
1> sp_password NULL, 'Str0ngP@sswOrd', sa
2> go
Password changed.

.NET SDK MSDE and Visual Studio .NET

Users of the .NET SDK Version 1.0 must apply a special version of Service Pack 3 which can be found at this location:

Additionally, as the following link indicates, if you have both Visual Studio .NET and the .NET SDK MSDE installed, you should apply both the regular MSDE Service Pack 3 as well as the .NET SDK Service Pack 3:;en-us;813850

Application Center 2000

Application Center 2000 uses MSDE and has specific requirements for applying Service Pack 3. Details may be found at:


The Slammer/Sapphire worm is memory resident only. Stopping and restarting the SQL Server service will clear the worm from the instance, but will not by itself prevent reinfection. Applying Service Pack 3 stops and restarts the service, so it both clears the worm and prevents reinfection.

Baseline Security Analyzer

It is important not to focus so much attention on widely publicized threats as to overlook other weaknesses. Microsoft provides a free tool to help identify other vulnerabilities your machine may have.

Download the Microsoft Baseline Security Analyzer from:

The following screen capture shows a small portion of the scan performed on the entire machine:

The screen capture shows that the scan detected the service account privilege problems mentioned previously in this article. The Baseline Security Analyzer not only points out problems, but also provides hyperlinks to explanations on how to correct the identified problems.


Security best practices can prevent unnecessary down time caused by security threats. Staying current on service packs and hotfixes is essential. By understanding and expecting threats, proper planning can mitigate risks.


John Paul Cook is a database and .NET consultant. He also teaches .NET, XML, SQL Server, and Oracle courses at Southern Methodist University’s location in Houston, Texas.

Contributors : John Paul Cook
Last modified 2005-04-12 06:21 AM
Transaction Management
Reduce downtime and increase repeat sales by improving end-user experience.
Free White Paper
Database Recovery
Feeling the increased demands on data protection and storage requirements?
Download Free Report!

Powered by Plone