Slashdot Mirror
MS SQL Server Worm Wreaking Havoc
defile writes "Since about midnight EST almost every host on the internet has been receiving a 376 byte UDP payload on port ms-sql-m (1434) from a random infected server. Reports of some hosts receiving 10 per minute or more. internetpulse.net is reporting UUNet and Internap are being hit very hard. This is the cause of major connectivity problems being experienced worldwide. It is believed this worm leverages a vulnerability published
in June 2002. Several core routers have taken to blocking port 1434 outright.
If you run Microsoft SQL Server, make sure the public internet can't access it. If you manage a gateway, consider dropping UDP packets sent to port 1434." bani adds "This has effectively disabled 5 of the 13 root nameservers."
I find it lucky that the worm writer didn't make the worm fire out random traffic on random udp ports with spoofed addresses.
/sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP
It's only the fact the traffic is all destined for a certain destination port that makes it easy to filter.
You are filtering it out on your firewalls, aren't you?
This could have been a lot lot harder to filter out. I expect we'll see ThisWorm v2 soon.
I dread the day someone finds a hole in Apache, Sendmail or something really popular and writes a worm like this...
Get your own free personal location tracker
Collected a packet disasembly and some urls here.
Everyone seems to be assuming this is a new use of an old (July) hole; I'm not certain of that. Any facts welcomed, see above url.
Microsoft released a patch for this 24th July, 2002.
ZDNet and Yahoo.
If you run Microsoft SQL Server, make sure the public internet can't access it.
What a pathetic overkill response. If you're running SQL server, make sure it's patched. When the last set of bind exploits came out no-one said "Unplug all your DNS servers", why is this any different?
SQL is easy to secure, and the guidelines are well known
And of course, patch it when patches appear
From digitaloffense: A new worm which exploits a vulnerability in MS SQL Server is bringing the core routers to a grinding halt. The speed of the propagation can be attributed to the attack method and simplicity of the code. The worm sends a 376-byte UDP packet to port 1434 of each random target, each vulnerable system will immediately start propagating itself. Since UDP is connection-less, the worm is able to spread much more quickly than those using your standard TCP-based attack vectors (no connect timeouts). Some random screen shots and information about the worm can be found HERE.
Best writeup I've seen is over at iss.net. They were the first to update their internet status homepage alerting of the vulnerability as far as I can tell.
http://average.matrixnetsystems.com/Daily/markR.h
http://mrtg.nac.net/switch9.oct.nac.net/3865/swit
The advisory announcing the flaws:m /
http://www.boredom.org/~cstone/worm-annotated.txt
http://www.nextgenss.com/advisories/mssql-udp.txt Various disassemblies and discussions: http://www.snafu.freedom.org/tmp/1434-probe.txt http://www.digitaloffense.net/worms/mssql_udp_wor
Writeups:n et.attack.ap/index.html / 20030125/ap_wo_en_po/na_gen_internet_attack_2 r tdetail.jsp?oid=21824
http://www.cnn.com/2003/TECH/internet/01/25/inter
http://news.bbc.co.uk/2/hi/technology/2693925.stm
http://story.news.yahoo.com/news?tmpl=story&u=/ap
http://bvlive01.iss.net/issEn/delivery/xforce/ale
Needless to say I've been working since then to apply appropriate firewall rules accross our network to block port 1434.
What you really need to do is to assess which ports you need to leave open, and to which hosts they correspond. You need to block everything, and then set rules to enable only the ports/hosts that are necessary (open ports 80/443 to webserver, etc).
Otherwise, you'll be doing the same thing for the next worm.
Some snippets from there:
It looks like if you stop the proccess sqlservr.exe it will take all of the CPU proccess back down to normal. Obviously you dont want to delete this file, but with it stopped you can at least get the box on the network to trouble shoot this stuff. So far from what we can tell, when you restart SQL the load stays down, but that could also just be that its sitting there idle waiting to be activated again. Hope this helps.
Alchemy Support
Alchemy Communications
It can giggle all it wants. The galaxy's not gettin any of our Bourbon.
Any server that doesn't need to be accessed from the public internet in the course of it's normal use should be firewalled off from it. That's just common sense.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Kudos to cstone@boredom. Interesting & educational, with a nutty crunchy flavor.
There are no SQL commands in the worm. It just initiates a bouncing ping between two MS SQL servers that continues until the network or one of the servers is brought down. An annotated dissection of the worm is provided here.
It was covered by the Slashdot masses on another security-related thread earlier this morning.
If you want an non-editor-controlled story queue, with story selection subject to user moderation, try submitting/reading here; the capability is now possible on Slashdot. It's not as simple as it could be, and it's only a week old, but it works without you having to leave Slashdot.
--LP
Disassembly of the 404 bytes being sent by affected systems
Postgresql and oracle are like screw drivers. Do you use one screw driver for all tasks? No. There are some things that oracle really kicks ass at that postgres really plain sucks at. Vice versa as well.
-
ping -f 255.255.255.255 # if only
Despite panicky headlines, and mails to bugtraq with titles such as "MS SQL WORM IS DESTROYING THE INTERNET", reports of "some hosts being hit by as many as ten packets a minute" don't seem too serious to me.n ed.uppsn ed.bits
Take a look at the LINX traffic statistics at
https://stats.linx.net/cgi-pub/combined?log=combi
and
https://stats.linx.net/cgi-pub/combined?log=combi
and you won't even see a glitch.
End of the world? I don't think so.
"...the volume from this triggers the Cisco netflow switching bug and is causing routers to lock up at places, etc."
The MS educational site license is a flat $40 per year for every computer, including Apples and Suns.
For that, a school can install any and every MS product where ever they please. Not only that, MS supplies training and testing materials and answer keys with that. So the classes are pre-written, too, and a GTA or undergrad can run them.
So yes, MS SQL is all over the place, and they've got lab assistants and volunteers admining them.
That doesn't mean that Amazon's DB servers have public IPs you know. There is no reason to have a DB connected to the internet, unless you just wanna see what happens...
Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
Yes it can indeed get inside a firewall. Say you got bonehead web developer front page dude at home running the developer version. It is no doubt infected with the worm since said developer is using front page and MS SQL on his home xpeeee box. He thanks you by logging in via VPN into your network and spreads the joy. Priceless.....
Got Code?
Gates acknowledged that the technology industry must make significant improvements, adding that, "Microsoft has a responsibility to help its customers address these concerns, so they no longer have to choose between security and usability."
How about easier ways to apply hotfixes remotely to desktop computers? (There are ways apparently, but requires installing IIS and SQL ironically, to run something called SUS.) I'd prefer the hotfix to simply have an option like '-m\\machine' to apply to domain machines in a domain admin context so I can script the installs to my tastes and needs. No need to get overly complex. Besides, I'd rather not have an IIS server at my site if I can help it. Apache runs everything. Just another damn thing to learn for something that should be simple.
Also, the hotfixes themselves only have about 10 different ways of applying at the command line unattended. How about standardizing the hotfix installers too...
Example, this is what is run after an XP desktop install with SP1 at our location...
It doesn't include latest javavm fix, which for some reason won't install right during the guirunonce part of an install, so I have to script to reboot the machine TWICE before running... Think that's bad? Here's some pre sp1 hotfix command lines from an earlier script.. And the syntax to install unattended is never easy to find on their site. I usually have to use google to search microsoft.com to find what I need, their search engine really sucks. Others must feel the same way since there is a dedicated google page for this at http://www.google.com/microsoftI've been a call all morning and we are sure now that SP2 does NOT protect your server from this attack...YOU MUST APPLY MS-039 to protect your server
I'm in France. I have 1434 in my logs all morning, but nothing since about 11:30 greenwich. The source IP's are about half and half Europe/US.
A few things are down over here, like my university's network, but haven't noticed any major crashing.
Congratulations! Now we are the Evil Empire
Another ignorant post because people insist on attacking the wrong person. EVERY protocol has vulnerabilities, that's the facts. The patch was release almost a year ago for this same issue. If you want to blame anyone, blame the shitty admins who don't filter out traffic if they must use MSSQL over the internet, or flat out block it if they don't. I know people think it's cool to bash MS, but in this case it's directed at the wrong person. Besides, last time I checked the root-servers weren't running Windows and they went down like a date on prom night.
My sig of choice is Marlboro
...and we lost tons of money. We were down for more than 8 hours and no customer could call in to check on their server problem tickets, hospitals needed service and we couldnt get technicians out there...our servers were swamped. This is serious when companies who deal with the lives of idividuals are at risk. Hospitals had ptient databases that couldn't get accessed, nor banks needed techs onsite to install new software or hardware upgrades before the open of business....nothing could get done. This was the first time IBM got hit this hard where it brought down 95 percent of the company globally. Yikes....Now I got back to collecting the hair I've been pulling out for the past 8 hours.
last time I checked the root-servers weren't running Windows and they went down like a date on prom night.
Actually NONE of the root nameservers went down, either during this worm incident, or during the Oct 21 incident. The network nameservers are generally highly overprovisioned, and do a very good job of responding to every request they receive, even under abnormal load.
What happened is that the increase in network traffic staturated some of the feeds to the root name servers making it impossible for requests to reach the name servers. This is the real danger of these attacks.
And as far as blaming negligent sysadmins for not patching their servers, well, sure. But sysadmins are not the only players in this game. Companies often have policies regarding software patches and validation that restrain what a sysadmin can do. And the fact is that the sysadmin did not put the vulnerability in the software, nor is this the first time a Microsoft product has servered as the vector for something like this.
A nice collection of data and NOTES.TXT here.
-- When you look to see how the system works, you usually find that it doesn't.
Here is a program they have for the NT/2000/XP line that lists hotfixes that have not been applied. It certainly is more comprehensive than the windows update site.... Hotfix Checker at MS
Hotmail still has *nix at it's base, so it's still up.....
No
It
Doesn't.
The site www.hotmail.com is running Microsoft-IIS/5.0 on Windows 2000.
If you haven't patched PostgreSQL within the last 6 months you are vulnerable to multiple buffer overflow/remote root exploits.
remote root???? Just about EVERY postgresql system runs as a normal user, how the hell do you get root out of that?
By default postgresql does NOT even support IP connections, you have to turn it on by either the -i option to postmaster or in the config file.
I think your looking at the Mordred buffer overflows from about 5 months ago. ALL of these require a valid user account to exploit. NONE were remote. Please post the location/posting of a REMOTE for a recent release of PostgreSQL. Versions 6.X, 7.1.X and 7.2.0 do count.
BWP
You should be using the Microsoft Baseline Security Analyzer to ensure that ALL the machines on your network are properly patched and locked down. It's so easy to run there should be no excuse for attacks like this.
!!!ATTENTION MS ADMINS!!!
I was just about to post the same thing! Moderators: mod this one up! People need to read this otherwise they'll think their cracked box is safe!
From securiteam.com: ..It can be configured such that clients can use named pipes over a NetBIOS session (TCP port 139/445) or sockets with clients connecting to TCP port 1433 or both. Whichever method is used the SQL Server will always listen on UDP port 1434. This port is designated as the Microsoft SQL Monitor port and clients will send a message to this port to dynamically discover how the client should connect to the Server.
Read further into the report. The exploits use the vulnerability in the code which listens to UDP port 1434. You can't turn this off!