If you haven't changed the SA password on your SQL Server, you may be soon
paying the price. Beginning last week, an old worm has come back in full force,
infecting about 100 SQL Servers an hour. Reports of heavy port 1433
scanning began in early may but by the 22nd, the virus really began to take its
hold on systems with no SA password.
The worm code named "SQLsnake" attacks SQL Servers with no SA password. Once
it finds a server with no SA password, it then attacks your system in the
following order using the XP_CMDSHELL extended stored procedure (allows it to
shell to a command prompt):
- Enables the domain's Guest account if it is not already
- Grants the Guest account Administrator rights to the local machine
- Grants the Guest account Domain Admin rights to the domain
- Copies itself to your system directory
- Gathers information about the databases, network interfaces and your
Windows password hash into a file
- Emails the file to
ixltd@postone.com, which is an overseas
e-mail address that we believe was originally owned by the worm's author
- Begins to look for other
SQL Servers in your network and outside your network to infect
It is now believed that more
than 10,000 systems have been affected, but what is even more scary is that this
could be only the first attempt at the virus. Back in November of last year, a
similar virus infected a modest amount of SQL Servers but did not propagate as
well as SQLsnake. Original reports I read stated that this virus only
infected SQL Server 7.0 since it was the only server that shipped with a blank
password. This is incorrect however. SQL Server 2000 machines are less
vulnerable, but still can be poorly configured to have a blank SA password. To
prevent your SQL Server from being infected, take the following action:
- Change your SA password to a non-blank and hard to crack password
- If you're not blocking
TCP port 1433 and UDP port 1434 to untrusted areas, do so now.
- Make sure your SQL Server
is not running under an account like LocalSystem or a domain account with lots
of permissions, like a Domain Admin or an Account Operator
If you think there's a risk of infection in your network, you can run a free
tool by E-Eye to scan you network for infected machines. The SQL Scanner is
available for free on
If you have been infected, you can remove the virus by performing the
following steps:
First, unhide the virus' files by using the attrib command file at the command
line:
attrib -h %WinDir%\system32\drivers\services.exe
attrib -h %WinDir%\system32\sqlexec.js
attrib -h %WinDir%\system32\clemail.exe
attrib -h %WinDir%\system32\samdump.dll
attrib -h %WinDir%\system32\pwdump2.exe
attrib -h %WinDir%\system32\sqlprocess.js
attrib -h %WinDir%\system32\sqlinstall.bat
attrib -h %WinDir%\system32\sqldir.js
attrib -h %WinDir%\system32\run.js
attrib -h %WinDir%\system32\timer.dll
Then, delete the virus' files:
del %WinDir%\system32\drivers\services.exe
del %WinDir%\system32\sqlexec.js
del %WinDir%\system32\samdump.dll
del %WinDir%\system32\clemail.exe
del %WinDir%\system32\sqlprocess.js
del %WinDir%\system32\sqlinstall.bat
del %WinDir%\system32\sqldir.js
del %WinDir%\system32\run.js
del %WinDir%\system32\timer.dll
del %WinDir%\system32\pwdump2.exe
And unregister the following DLL file
regsvr32 /u TIMER.DLL
Finally, delete the
following registry keys:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetDDE\ImagePath
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetDDE\Start
HKEY_LOCAL_MACHINE\software\microsoft\mssqlserver\client\connectto\dsquery
An additional word of
warning is that once the virus infects your outer SQL Server, it can begin to
attack and infect other SQL Servers in your network that may be on the other
side of a firewall. What worries me most about this virus is the ratcheting up
in intensity of these worms. This is not a SQL Server flaw, but a user flaw. In
a way, it's like locking the doors of your house, but leaving the window wide
open next to the door. No matter what the environment, including development,
never have an SA password that is blank.
