New Microsoft SQL Server Worm

Ian Bell writes: "A new unnamed worm has been released and, once again, Microsoft software is the target. More specifically, this new worm targets Microsoft SQL servers with no administrator passwords set. Once the server is infected, it logs onto Internet Relay Chat (IRC) servers and is ready to receive commands and act accordingly. Although this can be a fairly malicious worm, it is very unlikely to infect many servers due to the fact that majority of Microsoft SQL servers have administrator passwords."

Re:Stupid

[iso]

They do, except for in SQL Server '97. All recent versions make you set a password by default. This worm will only exploit SQL Server '97.

Re:default password == blank

[Katravax]

Installers for the last couple versions of mssql do indeed ask you to set the sa password, but allow you to override that with the "blank password" checkbox. So since SQL 7.0, you have to go out of your way to have a blank password.

I've done contract development at quite a few places that had publicly exposed sql servers with blank sa passwords.

Re:Astounded

[AnimeFreak]

I am not bashing Mac users here, but face it, there are more Windows/Unix users than there are Mac OS users.

Thus saying that, with less users using that OS, the less chance of a security problem occuring due to the low usage of Macintoshes as Servers. I am certain there are a lot of undiscovered bugs in Mac OS that we're not aware of, it is only a matter or time before they're found or never found out at all.

IIRC, the last bug or exploit that I have seen involving the Mac OS was a exploit in Microsoft Internet Explorer. That is a third-party issue though.

I feel the urge to move back to Macintosh now, though. OS X looks very purdy.

MSDE doesn't listen to 1433

[Otis_INF]

The installment you refer to doesn't listen to a TCP/IP port, you have to configure that yourself in the registry. Therefor these installments are not vulnerable.

Re:Before you trash Microsoft,

[mgv]

So if someone is a worm victim, they either unthinkingly opened an attachment or didn't keep their machines up to date. Either way it was preventable.

Actually, microsoft has created alot of reluctance amongst more experienced users to keep up to date.

Many service packs have actually broken systems in the past - making people who know what they are doing reluctant to apply a service pack until they are sure that it really works.

Also, many security updates depend on these service packs. In fact, some of microsofts own update reporting system will not see the patches until they are running on an up to date service pack.

It becomes a catch 22 - either way, you are dammed (well, you certainly would have been in the past). Maybe microsoft will not make these sort of errors again. Hmmm, did I just say that? ;)

So, I'm not sure its totally preventable on MS software.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:MSDE too?

[Anonymous Coward]

Yes, the worm is most likely targeted against MSDE.

There's a HUGE security hole in MSDE given that it installs with blan password and makes it very difficult for administrators to set a password.

There was a nice article about the problem in the german c't magazine. It's not online, but it's c't 20/01 page 44. ... if you read german.

(http://www.heise.de/ct/inhverz/search.shtml?T=M SD E)

Re:MSDE doesn't listen to 1433

[Dahan]

Seriously, check out the KB article [microsoft.com] I referenced. It explicitly mentions that you can't use named pipes on Win9x (as a server-side net library... i.e., MSDE can't listen on a named pipe on Win9x). And the "default" install of MSDE (1.0, at least) has "NetworkLibs=4095" in the unattend.iss file, which translates to Named Pipes, TCP/IP, and Multiprotocol.

As for the real SQL Server, I just installed SQL Server 7.0 Developer Edition on a test Win2K Server machine--if I pick custom install, it lets me choose which network libs to install, and by default, Named Pipes is checked (and can't be unchecked), TCP/IP Sockets is checked, and Multi-Protocol is checked. I cancelled that and restarted the setup using all the default/typical settings, and after it was all done, I started the service and it was happily listening on TCP port 1433 with no password on the sa account.

So MSDE and SQL Server default to a couple of protocols; TCP/IP is one of them. You do not have to specifically tell them to listen on TCP/IP.