A worm, code-named "Voyager Alpha Force," that takes
advantage of blank SQL Server system administrator (sa
) passwords has been found on the Internet. The worm looks for a
server that is running SQL Server by scanning for port 1433. Port 1433 is the
SQL Server default port. If the worm finds a server, it tries to log in to the
default instance of that SQL Server with a blank (NULL) sa
If the login is successful, it broadcasts the
address of the unprotected SQL Server on an Internet Relay Chat (IRC) channel,
and then tries to load and run an executable file from an FTP site in the
Philippines. Logging in to SQL Server as sa
gives the user administrative access to the computer, and
depending on your particular environment, possibly access to other computers.
Each of the steps in this section will help to make your
system more secure in general, and any one of them alone will prevent this
particular worm from infecting your server that is running SQL Server. Note
that these steps are part of the standard security "best practices" for any SQL
- If your authentication mode is Mixed Mode (Windows
Authentication and SQL Server Authentication), secure your sa login account with a non-NULL password. The worm only works if
you have no security for your sa login account. Therefore, it is best to follow the recommendation
from the "System Administrator (SA) Login" topic in SQL Server Books Online to
make sure that the built-in sa account has a strong password, even if you never directly use the
sa account yourself. For increased security, enable Windows
Authentication Mode (Windows Authentication only), thus removing the ability
for anyone to log in as sa user. Configure your clients to use Windows Authentication.
- Enable auditing for successful and failed logins, and then
stop and restart the MSSQLServer service.
- Block port 1433 at your Internet gateways and assign SQL
Server to listen on an alternate port.
- If port 1433 must be available on your Internet gateways,
enable egress/ingress filtering to prevent misuse of this port.Note Contact your network administrator or your firewall vendor for
more information about setting up ingress/egress filtering.
- Run the SQLServer service and SQL Server Agent under an
ordinary Microsoft Windows NT account, not a local administrative
For information about how to recover an already compromised
system, visit the independent CERT Coordination Center at the following Web
provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft does not
guarantee the accuracy of this third-party contact
: There is no bug in SQL Server that permits this penetration; it
is a vulnerability that is created by an unsecured system.
following files indicate the presence of the worm:
- rpcloc32.exe (md5 = 43d29ba076b4fd7952c936dc1737fcb4
- dnsservice.exe (md5 = 79386a78a03a1665803d8a65c04c8791
- win32mon.exe (md5 = 4cd44f24bd3d6305df73d8aa16d4caa0
Additionally, the appearance of the following registry key
indicates the presence of this worm:
The following registry keys are existing keys for
SQL Server, and they are used by the worm to control access to the computer by
using the TCP/IP network library:
The worm uses the xp_cmdshell
extended stored procedure, which allows the worm to run any
operating system command that the account running the SQL Server service has
permission to run.
For more information about how to help secure a SQL Server server, visit the following Microsoft Web sites: