SQL Server Central is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
Search:  
 
 

SQLsnake Worm Hits SQL Servers and Networks Hard

By Brian Knight, 2002/05/28

Total article views: 4609 | Views in the last 30 days: 7

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 their website.

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.

 

 

By Brian Knight, 2002/05/28

Total article views: 4609 | Views in the last 30 days: 7
Your response
 
 
Related tags
 
Already registered?  

Free registration required

To read the rest of this article, and access thousands of other articles, we ask you to register on the site and subscribe to our newsletters.

Register

E-mail address:
Password:
Password (confirm):

  

Subscriptions

We ask you to register on the site and subscribe to our newsletters. Subscribing to our newsletters gets you:

  • ALL of our content (thousands of articles, scripts, and forum postings)
  • A daily newsletter (example)
  • A weekly news round up (example)
  • The opportunity to ask and answer questions in our forums
  • A daily Question of the Day to test and help you increase your knowledge of SQL Server.

We ask that you give the newsletter a try for a week. Over 200,000 SQL Server Professionals a day find it entertaining and useful. If not, you are welcome to unsubscribe at anytime.

Steve Jones
Editor, SQLServerCentral.com