Slashdot Mirror
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.
McAfee's description. The AV vendors are calling it Spida, instead of snake.
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.
Symantec has produced a more informative bulletin; however, they have entitled the worm "Digispid" as opposed to SQLsnake.
Do you like German cars?
Perhaps there just isn't good documentation on this, but this issue wouldn't be a problem if the SQL Server databases were properly installed and maintained.
First of all, a DB should never be outside a firewall. It's not necessary.
Second of all, this issue is aided by databases installed with blank admin passwords.
I don't know how you solve this. You can't prevent people from installing software. I guess Microsoft's new MBSA will point out the blank password issue and any patches missing, but...
I'm sorry.. but according to the topic post it said:
and even attempts to brute force passwords.
So either you're telling me, the writer lied... OR... it doesn't just attack blank passwords... so which is it?
www.slightlycrewed.com - Because aren't we all?
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....
This one isn't $M bashing! It's STUPID SYSTEM ADMINISTRATOR/STUPID DBA bashing.
Microsoft is semi-innocent on this one.
NOTE: They make their products so even a stupid administrator can install it, and this worm is proof of that!
I take no responsibility for what I say. Even though I'm never wrong
I'm waiting for the day when people stop saying "We got another worm." and start saying "We just got Microsofted again".
Outdoor digital photography, mostly in New Engl
Many exploitable holes such as these can be attributed in part to the management mentality that one or two over-worked, under trained "computer people" can handle professional system/network administration.
Frequently SysAdmins started their jobs in another field, like Engineering, and were sort of migrated over. Little formal training was given, let alone budget for. Most smaller (sub-Fortune 500) operations were more of a congealed mass than a designed network.
Then, when the LAN wasn't hooked to the Internet, and some poor schmuck install MS BackOffice and wanted to instal SMS Server, it told him he had to install SQL Server. A couple of quick clicks and you're done. Odds are, he clicked thru the admin password not thinking he'd EVER touch MS SQL other than as a backend for SMS.
Pity the new admin who inherits such a setup. You think a new admin is given time to actually check a network configuration out, much less do a proper security, performance, license audit? Nope. Get in and tell me why Outlook is saying my deleted folder is empty. I haven't emptied it since 1998 and everything was always there before when I needed it!
Stupid worms/viruses/exploits will prevail until the MENTALITY of management changes. Computers run most modern business, they are not an afterthought. The people that take care of them should be properly trained, with proper budgets. Periodic PM (preventative maintenance) needs to be allowed, scheduled and performed.
I feel pity for the admins who have to deal with these worms. I feel nothing but contempt for the management process that let them get in this position.
Learning HOW to think is more important than learning WHAT to think.
First of all, if you attempt to set a blank admin password for SQL Server it gives you a warning that doing so is a very bad idea. None the less, you'd be surprised at how many are blank (or just use sa/sa). The article makes it sound like the default sa password is blank - this is NOT the case. Also, although you cannot disable the sa account, you can rename it during setup.
Secondly, as has already been pointed out here, your database server should not be exposed to the net in general. There is usually very little reason to do so. If you need to let other machines access the SQL box from abroad, create an IP Security filter that only allows port 1433 for a specific subnet or ip address.
Don't complain that you got rooted when your login is root/root.
Natural != (nontoxic || beneficial)
A massive "unlocked door" worm has been ravaging users of Schlage locks. Aparrently hackers have been breaking into houses with Schlage locks installed. 9 out of 10 users were found to have installed the locks but never engaged the locking mechanism, and many times had left the key in the knob.
The bulletin MS02-020 was just released about a month ago. Only the admins that place a top priority on patches (such as myself) are safe.
I supported NT server for MS for over a year and can attest to the number of admins out there that rely too heavily on anti-virus software. When nimda spread and took over a buttload of systems, it was for this very reason. The thing spread before it could be researched and DAT files updated.
Here's some solid advice for NT/2000/XP/.NET admins:
Use the hfnetchk tool to monitor all NT based computers on your network for installed patches using the syntax hfnetchk -h host1,hotst2,host3 -v -z -s 1. It will also check for SQL, I.E., and IIS patches. Other products such as Office will have to be checked manually. At least Office has the officeupdate web site for easy installation that the users can do. Block email attachments with extensions that viruses use. Have anti-virus software installed that checks avery 2 or 3 hours for updates. Have a properly configured firewall (Blocks well known attacks) in place that only allows incoming session requests for what services are to be made available to the Internet. Lock down any services that are open to the Internet. Have strong passwords for all admin accounts (At least 10 random characters) and create a new one for each admin account once every few months. Same thing goes for any account that can authenticate in any way from the Internet (8 characters and changing every 6 months or so should be okay). If domain authentication is going to be provided to the Internet for some stupid reason, hack the registry so only NTLM v2 is used. Configure all windows computers to use the Peer-Peer node type 0x2. Use switches instead of hubs to prevent evesdropping and assign MAC addresses to ports for your servers to avoid MAC address spoofing. Most of these things are a one time setup. The ones that require maintenance are worth the trouble.
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?
is to put SQL Server on a port other than 1433. Of course for an existing installation, this could be a major change. But if you're setting up a new SQL Server, use another port. This is assuming you are using SQL Server and not another superior database product (like Oracle).
Believe in things of which no person has ever learned
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.
Well, I'll just wait here for that...
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
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 :)
use master
exec sp_dropextendedproc 'xp_cmdshell'
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
use master
select name, Password
from syslogins
where password is null
order by name
Finally, MS have released a bulletin