New "SQLsnake" Microsoft Worm

sevenn writes "A new worm, targeting the Microsoft SQL daemon, has been sweeping the net. It uses massive scanning, default passwords, exploits against vulnerable versions and even attempts to brute force passwords. Here is the (vague) Microsoft bulliten, the SANS analysis, and a securityfocus article" Already over a thousand compromised system- you're apparently only vulnerable if you run MS SQL, but the worm is causing a substantial spike in traffic to port 1433 on the net.

Comments

McAfee

[Triskaidekaphobia]

McAfee's description. The AV vendors are calling it Spida, instead of snake.

Digispid/SQLsnake

[Scoria]

Symantec has produced a more informative bulletin; however, they have entitled the worm "Digispid" as opposed to SQLsnake.

Re:Thousand compromised?

[Foochar]

Keep in mind that Access XP includes a desktop version of SQL server that I believe is installed by default. Microsoft is trying to move away from the Jet engine that Access is based on and towards using SQL for all databases, both large and small. I'm sure that some of the thousands of infected systems are desktop systems.

There are also plenty of business apps that run on top of SQL server. The program's installer takes care of setting up the SQL server with little to no knowledge or intervention required on the users part.

Re:Databases shouldn't be outside the firewall

[ColdCuts]

One of the things incidents.org points out (http://www.incidents.org/diary/diary.php?id=156) is that some microsoft products have sql server included as a hidden or optional install. Access 2000, Visio, even Visual Studio 6 had an option for installing MSDE. If installed, no password is set for the account.

Some basic thoughts on securing SQL.

[blowdart]

I've just mailed this to a couple of security lists I take part in. Posting here seems like a good idea (although now, of course, I am outed as a SQL Server user)

Please feel free to forward these recommendations to any other lists as you see fit. However, as with all system changes, things can go wrong. Make sure you have backups. I take no responsibility if your SQL server dies. Or if the sun fails to come up :)

• The automated MS baseline security tool checks for blank sa passwords.
• You can safely (well ish) drop the xp_cmdshell stored procedure from your servers. There's very little valid use for this (smug mode - I had mentioned this in a presentation to SQL-PASS 2 years ago!) This can kill some things, like BCP. Don't hold me responsible if something stops working :)
  use master
  exec sp_dropextendedproc 'xp_cmdshell'
• Don't run mixed mode security if you can help it. MSDN has details.
• You can of course, change the port SQL listens on. Not ideal, but for those that want a wide open to the world SQL database, it's an option. (Run the Server Network Utilities program on the server, and choose properties for TCP/IP - don't forget to tell the client machines the new port)
• I want to restate - SQL does not log logins (failed or otherwise by default). Turn it on. (Enterprise manager, right click your server, choose Properties, then the security tag. Login events go to the Application log.
• From what I see the worm adds a password to guest and moves it into the admin groups. It's done using the username, not a SID, so renaming your guest accounts would stop this. Always a good idea to enforce this at a domain policy level.
• You may also wish to consider dropping the ActiveX stored procedures. Do you want/need sa to be able to create ActiveX objects?

  sp_OACreate sp_OADestroy sp_OAGetErrorInfo sp_OAGetProperty sp_OAMethod sp_OASetProperty sp_OAStop

  The same goes for registry sps

  xp_regaddmultistring xp_regdeletekey xp_regdeletevalue xp_regenumvalues xp_regremovemultistring

• Check the login tables for null passwords (mixed mode). Run the following SQL

  use master
  select name, Password
  from syslogins
  where password is null
  order by name
  

• Use a low access user account for SQL Server service not LocalSystem or Administrator. This account should only have minimal rights (Run as a Service Right IS required). If you use Enterprise Manager to make this change, the ACLs on files, the registry, and user rights are done for you.
• Check the other extended stored procedures, delete as you see fit.
• Don't run SQLMail unless you have to.
• Don't use TCP/IP as a network protocol unless you have to.

Finally, MS have released a bulletin