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.

Thousand compromised?

[WildBeast]

Who needs MS SQL Server? Are you telling me that thousands of companies with a load of data are installing SQL Server without having a database admin to do the work? Sweet, they deserve what they get. What kind of people install SQL Server without putting a password for the SA account? Apparently, plenty :)

Long live human stupidity.

Re:Thousand compromised?

[Anonymous Coward]

Nope, there is a new MS-SQL mini server that runs on workstations. Installs a blank sa password and get this no admin tools are installed. So this means many people are running MS-SQL and don't even know it.

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.

Digispid/SQLsnake

[Scoria]

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

two versions out

[martin]

According to Sophos (www.sophos.com) there are two vesions out.

the first one just attempts the 'default' null passwd and 'sa' username (the administrator).

The second tries a brute force attack on the passwd.

So no change from trying to telnet into a *nix box as root then....

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.

Correction

[IncarnationTwo]

To quote security focus article:

'According to SANS incident handler Johannes Ullrich, a preliminary analysis shows the code, which has been dubbed "SQLsnake," attempts to log in to the SQL administrator's account on a remote server using a "brute force" password cracker.'

So, it inflicts even systems, that do not have blank sa password. It only inflicts those systems, instantly.

.NET Developers Vulnerable too

[IdleMindUI]

The Microsoft Data Engine (MSDE) that comes with the .NET SDK is just a stripped down version of SQL server. Unfortunately enough, it's got enough "features" to make it vulnerable to attack. Sure I'm just stating the obvious, but I've already talked to 3 boneheaded .NET developers that insist that they're not running SQL Server. Imagine what I found on port 1433...

Re:The Bugtraq article

[jamie]

"Slashdot's filters SUCK like HELL."

Maybe you don't really want to post a huge comment that will require readers to click through anyway (it's too big to display at once).

How about posting a link to the ISS Alert instead? Is that so hard?

Re:Lazy admins again.

[Error27]

Remember the Red Hat piranah bug a couple years ago where there was a default password?

That default password existed--in beta software--for two weeks before it was found. Slashdot was up in arms about it. Alan Cox personally appologized for letting the default password slip by his check.

I believe that slashdot was correct to get upset about piranah. I think any vendor who distributes software with default passwords deserves the same.

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

MS Defaults

[pavera]

I've been messing with MySQL and PostgreSQL a bit recently, and I have some experience with MS SQL as well.

This bug is obviously MS's fault, the default install of MS SQL allows connections from anywhere, what is that? I don't even think there is a per IP or IP range block you can put specifically on MS SQL.

In contrast MySQL and PostgreSQL both default install with only local host allowed to connect to the DB. And, the admin has to specifically *ALLOW* hosts or IP ranges to connect.

Obviously, a brute force attack on a specific TCP port number will not work against MySQL or PostgreSQL, as the connection will be refused outright, unless the worm can also spoof IP's.

Dumb defaults MS, once again.