An unsecured SQL Server server that has a blank (NULL) system administrator password allows vulnerability to a worm
This article was previously published under Q313418
This article has been archived. It is offered "as is" and will no longer be updated.
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 password.
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 Server installation.
- 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 account.
"Steps for Recovering from a UNIX or NT System Compromise"Microsoft 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 information.
Important: There is no bug in SQL Server that permits this penetration; it is a vulnerability that is created by an unsecured system.
The following files indicate the presence of the worm:
- rpcloc32.exe (md5 = 43d29ba076b4fd7952c936dc1737fcb4 )
- dnsservice.exe (md5 = 79386a78a03a1665803d8a65c04c8791 )
- win32mon.exe (md5 = 4cd44f24bd3d6305df73d8aa16d4caa0 )
SOFTWARE\Microsoft\Windows\CurrentVersion\Run\TaskRegThe 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:
SOFTWARE\Microsoft\MSSQLServer\Client\SuperSocketNetLib\ProtocolOrderThe 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:
virus antivirus scanner logon login
Article ID: 313418 - Last Review: 12/07/2015 08:14:00 - Revision: 8.0
Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition
- kbnosurvey kbarchive kbprb KB313418