Slammer Worm Slams Microsofts Own
MondoMor writes "Microsoft's forgot to patch some of its own servers to protect it from the months-old vulnerability exploited by the Slammer Worm, reports C|Net. Oops. Apparently Redmond's network was hit pretty hard. Just goes to show that no matter who you are, you'd better keep your apps patched." Update: 01/29 01:59 GMT by T : And if you're running systems which might be affected, take note: whitehorse writes "The Microsoft KB article for the Slammer patch found here has an incorrect URL for 'Download the patch' referring to KB Q316333 which is only a handle leak fix. The real patch may be found later in the article."
damn
i would've beat you if MS SQL wasn't slowing me down
At my office, we weren't vunerable because we /didn't/ upgrade. We were still running SQL 7.. Just goes to show you...
Relying on a vendors automatic update feature is no substitute for solid system administration.
Oh the irony in this. Microsoft always insists you update your patches, but for some reason they don't. O well this could be a good thing for network administrators as at the end it stated they were going to work on a new way to install patches.. Or thats what it looked like they said to me.
...says that patch management in Microsoft operating systems gets 100% better in 1 year :P
Don't believe anything I say. I crash test crack pipes for a living.
As one of the articles I read on the issue stated, it really does show that their policy of blaming the users for not patching their systems perhaps isn't the best approach to take. It is in fact blaming the victim for the software's flaws. Maybe this will turn microsoft more towards making sure their products are more secure from the start if this info gets around enough. Yes, I know Billg's "Trusted Computing" plan is rather new, but they sure seem to get caught with their pants down often.
today is spelling optional day.
Larry Ellison is cackling like a little girl........
(found on another forum) 01/25/2003 1:04:37 PM
"MSN was total messed up, I couldn't even log on to the net last night it said that my user name and passworded was invalid so I call them up and the tech guy says wow that's weird I can't ether."
-- Boycott Shell
The article I read (on yahoo) states the unpatched servers were all on the internal network, not the internet, and that they were in use by researchers within microsoft.
Let's not jump too quickly on the bash microsoft bandwagon for that. (Of course, if they just did enough testing and didn't release buggy, vulnerable software in the first place...)
This story supposes that Microsoft should somehow be a paragon of network infrastructure. It's clear from past events that MS is among the lamer of companies when it comes to infrastructure/security. Take, for example, the time DNS for just about the entire collection of MS domains, such as msdn.com and microsoft.com, were completely disabled by an attacker. They had all four of their nameservers on the same subnet, and all running Microsoft DNS software. An easy target to say the least. Calling this sophomoric is being kind. It didn't take them long to fix it, and I believe that now they contract out their DNS to get maximum diversity (and they even utilize Unix nameservers!).
I fully expect to see more entertaining stories like this for a long time to come.
In reality, admins running enterprise systems must remember to check what the patch fixes and weigh it against known issues it may cause. In Microsoft's case, their admins would be sure to know the service release is out. My guess is compatability testing indicated they should wait for a future patch, or until they changed something in their setup that would make any problems from the patch a non-issue.
www.atacomm.com - The Leader in VoIP Product Distributi
How many times have you, on a Win2k server clicked the check box labeled "Remind me in four hours" and waited for the next shift to patch the box?
Oh joy, the pleasures of having an automated "Patch-me-now" daemon.
Lazy admin, none the less.
God knows why, but our company had an NT box running MS-SQL outside the Unix firewall.
It got nailed and then apparently had privileges to come in and nail the rest...
Took us out for 12 hours. We are talking significant production loss here. I'm just thanking
my luck stars that I have nothing to do with our NT setup.
I snicker and do my little dance quietly in my cube.
Was the Slapper worm developed by a disgruntled Microsoft employee, and unleashed from within Microsoft?
another place where Unices have MS beat?
Yep.
I love the way the article makes security + patching seem such a burden on system administrators. It's one of the main functions of a sysadmin's job. Any sysadmin who thinks security patches are optional, regardless of how shitty your OS's package management + patch integration is, deserves to have their network taken down and their ass fired.
Though I do get a kick out of thinking of the nightmare the Windows admins have keeping up to date with patches, whereas a few hundred lines of perl, and I have my own automated patching system, and RPM keeps track of it ( no rpm vs. deb flames, thank you ).
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
They probably don't. What's more likely is that one or more employees took their laptops home and hooked them up to their own Internet connection without any personal firewalling active. If those laptops happened to be running SQL Server, they become carriers. All it takes then is for them to be plugged back into Microsoft's LAN, and game over.
The thing to remember is this worm infected any machine running the MSDE (A scaled down MS-SQL server) So if you were running Access or Office 2000 or MS Visual Studio 6, or even Visio 2000 you could be affected by this. Most end users don't even know that they would be vulnerable and the statement "This particular worm largely ignored home and personal computers, due to the product it infects" is false. It also seems to have had an effect on certain Cisco routers. Not fun but you can't just blame "Poor Admins" as the culprits for the virualance of the worm.
*narf!*
It was likely not "bad admins" so much as bueracracy. Most large companies make it very hard to make any kind of change, which leads to a situation where only the scariest, hairiest bugs get patched. This one may simply have seemed too complex for the average person to exploit until it was too late.
This problem is actually a very interesting one that I've been looking at for years. It happens in everything from 300-person companies to giant mega-corps. It's not because people are stupid, but because large systems only can only avoid tripping on themselves by imposing arbitrary controls.
I think that the right solution is staged anarchy, which is sort of what many large companies (e.g. Microsoft, AT&T, IBM, etc) do with their research divisions or via acquisitions or both. The idea is that you let smart people go nuts and create the unsupportable. You then get more, but different smart people to turn THAT into the supportable. You then get more average corportate drones to convert the supportable into the existing production framework. You then present the existing production framework to the first group of smart people and let them start over again.
You get about a 6-month cycle if you do it right, and you keep reaping the benefits of wild-eyed hacking as well as stability.
Microsoft takes a lot of flack for their technology, but they do this one thing well. You may not like such things as NT, C#, etc, but they are fairly large and complex beasts that most companies would not be capable of cranking out on their own (hence the benefits of open source development so that they don't have to). MS was able to draw on (and some would say corrupt) the smart work of their research folks and of technologies that they acquired and "MS all over it" until it fit their sales and support model, which is one of the reasons that they could do something like go from "Internet-illiterate" to winning the browser war, practically overnight.
IBM does this quite a lot as well (all of their hard drive advances come from this sort of process).
Interesting stuff.
As an aside, the instructions are in a readme.rtf file, even though they are actually just plain unformatted ASCII text pasted into Word. Who in their right minds would have Office 2000 installed on their SQL server? Or is this supposed to be standard practice? Gee, I guess should also look into putting OpenOffice on my Linux firewall.
Here are some quotes from Microsoft's instructions.
OK, but there is also a Microsoft SQL Server\80\Tools\Binn\ directory. What about this one?
ssnetlib.dll "files"? Why plural? I only found one in the path they seem to reference, but actually there was another one in Microsoft SQL Server\80\Tools\Binn\. However there was no ssnetlib.pdb in the main path nor was there even a directory Microsoft SQL Server\80\Tools\Binn\dll.
Again, how can there be ssnetlib.dll "files"? What are they talking about? Also, earlier the (non-existent) ssnetlib.pdb file was supposed to be backed up from the Dll folder, now we put the new one into the Exe folder?
OK, so I unleash Slammer on my network to make sure the problem is fixed? (And how would you test it before Slammer was officially released?)
(NB: some of the above may not be completely accurate, being based on old scribbly notes jotted down in the midst of confusion. However the quotes are direct from readme.rtf.)
There are quite a few "porous" holes that get into Microsofts internal networks. None of them are direct and without something like this worm that uses their own software, none are likely to allow much in.
I've worked in some of the Microsoft data centers and done design work... I know how hard they (just like many of my other non-microsoft customer) try to keep people "out" of these networks. But I've seen development projects go on the "soft" network and then get forgotten about. Its machines like these that probably provided the bridge back into MS.
It happens. Regardless of the company. Just some get more publicity than others. You think BofA didn't have firewalls? And yet they went offline for what... half a day or more?
No one's laid blame on it, but I think that the real way to get rid of these worms is to transition the net to IPv6. Slammer, Code Red, Code Red 2... all of them work by brute-force IP scanning. That only works because the IPv4 addres space is so densely populated; with IPv6, a worm would never be able to spread itself that way because the odds against a random hit are astronomical. I'm not saying that this should be a substitute for keeping servers up to date, but all the patching in the world doesn't help when the problem is that some faraway node is crushed under the traffic created by a worm, and IPv6 is good for many other reasons as well.
There's no excuse. Just because it is harder to install than a simple windows update package isn't any kind of reason not to update.
I agree, however...
Microsoft has argued for a long time that Windows is easier to administer (than UNIX/Linux), and that you don't need to hire an expensive, trained admin (which I assume they are referring to UNIX admins, but aren't MCSE expensive, trained admins, all jokes about the quality of MCSEs aside?).
So here we are with MS SQL Server, which is supposed to be an enterprise quality database system... but it has no intuitive interface for installing patches. So either we have a real DBA, who should know how to do these patches, or we have a power user to manage the database through a better interface to keep up to date on patches.
Either it's easy and you don't need an admin, or it's difficult and you do need a trained admin. SQL Server updates can't be as "complex" as they currently are if Microsoft is going to claim that anyone can admin a Microsoft server product.
Granted, they may not be making the claim that SQL Server is easy to administer, but what are the customers going to think? If Windows is "easy" (or so says the advertising), then SQL Server must be easy too! They both have little wizards to automate tasks, they both have a graphic interface for management...