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.
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...
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
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.
"You can't fight in here! This is the war room" --Dr. Stra
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.
Along comes e-mail, the Internet, databases, web sites, etc. Joe Enthusiastic runs into the President's office and says, "Mr. Smith! I have found a great new way to communicate with our customers!". Mr. Smith, though he is 90 years old, takes a look and says, "Yeah, that looks interesting. Buy one and set it up".
So the company buys one (database server, e-mail server, web site, etc.) and sets it up according the skimpy directions in the box. It works for a while, then blows up, seriously damaging the business.
NOW the company is told, oh, you should have known. You should have known the instructions in the box were incomplete and dangerous. You should have known you needed an 80k/year DBA to use that. You should have known the product was dangerous. You should have known...
Sorry. I am not buying it anymore. And I think the general business world isn't going to buy it much longer. Either the Internet will be abandoned, or there will be heavy, heavy government regulation of who can connect and how. Sort of like the phone company in the 1950's.
My 0.02 anyway.
sPh
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.
If they need to haul stuff, they buy a truck. If they want to stay in business, they don't leave the keys in it and the windows down while it's parked somewhere in public.
If they need to make copies, they buy a copy machine. If they need machine tools, they buy them. They also tend to keep these things in locked rooms so joe public can't walk in and trash them.
If they buy computer systems, they leave the passwords blank and expect people to not use them. That's not bad programming, it's stupid users.
http://online.securityfocus.com/archive/1/273029
It's not just stupid users. Somebody chose this machine for the business and it's something that they NEED in order to function. Not only that, they may not have a (practical) way to keep it secure when you look at how the machine is really used. I'd sugggest reading the entire thread, because there are more juicy details into the security problems and politics associated with big machines like these.
/ \
\ / ASCII ribbon campaign for peace
x
/ \
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