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."
Relying on a vendors automatic update feature is no substitute for solid system administration.
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.
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.
With the exploits going around recently I've realized a couple of things when it comes to security.
First and foremost is secure code. Right now, almost everyone and their grandmother has a firewall. They do a good job of protecting ports a user can't shutdown totally (some NetBIOS ports) and protecting insecure applications a user or organization wants to run internally but doesn't want the world to access (NFS, NIS, etc). The majority of these exploits target applications that firewalls will usually let past such as HTTP, FTP and e-mail.
Frankly I'm not sure how coders should go about writing secure applications, but it needs to be done. Perhaps at large organizations there should be a dedicated person or term in charge of verifying code is clear of buffer overflows and other nasties. Either way, the code itself needs to be secure or because a firewall won't do a thing. Without it even the most secure configurations will continue to be cracked.
Second is firewall configuration. Many firewall administrators tend to forget about outbund packets. Obviously there are some they need to let out (HTTP, FTP) but when it comes to things like SQL and outbound portmap, there's really no reason. Depending on the organizations needs they can more than likely block all outgoing UDP. By doing this they can help slow the spread of worms (such as this one) and reduce liability when it comes to crackers using their systems as a point to attack other systems.
Firewalls that block incoming packets just don't cut it, and never have. We need to have secure code and need to block unnecessary outbound packets as well.
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.
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.
"Provided by the management for your protection."
I know, I know... there are going to be tons of posts lambasting admins for not updating their boxes. Sometimes the cure is worse than the disease. Hell, last week a live update caused a catastrophic failure to the email systems. The IS boys were not lazy, did what they should, and lost 36 hours of their lives rebuilding the boxes from tape because of a bad patch.
Patches that fix something specific are fine. Patches that add new features or change API behavior can really make a mess. I've seen plenty of kit that requires xx service pack and the latest yy version breaks it.
As a side note, make sure you get the patch if you are running the MSDE on any of your boxes.... Same problem as SQL server - way to many vendors will fold that one into a dev version of a product. I know I almost found out the hard way...
+++ UGUCAUCGUAUUUCU
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?
Good troll, but you're 100% wrong.. One command will do it.
Another clueless jackass spouting off about things he has no idea about...
Basically, the idea is that by running "ancient" versions of software products, the script kiddies are completely thrown for a loop--their collections of 'sploits only work on more recent versions of code.
:)
It doesn't work, at least not for Microsoft's products. You and grandparent post forgot the Microsoft Support Life Cycle, say Windows 98 and NT 4.x will be entering "Non-supported phase" after June this year, Windows 2K even earlier, March.
Granted, SQL server 7.0 is still under the coverage of normal support til March, 2004, and if you happened to be a premium customer, they the period can be extended to 2006.
However, do not forget when a product is desupported, Microsoft will not take care of new problem found in it. No service patch, no enquiry. No MS reseller would dare take up the maintenance. They'd only offer you one option thereafter: upgrade.
Keep using the desupported products? Sure you can, but can you bet your career on a desupported product? You're welcome to do so as they can have a convenient target to blame when shit happens.
No linux vendor does anything like this; it's absolute insanity, and it's half the problem with MS admins (not) patching their software - they know better.
For years I was forced to run an IIS server which was outdated, unpatched, and very vulnerable. I couldn't update it because the service packs would break the software running on it - and the reason was that the service packs, while they fixed the vulnerabilities, also introduced all sorts of new features I did not need or want. So I was reduced to keeping a very watchful eye on it.
The entire infrastructure of Microsoft software distribution method is simply broken, and stupid.
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...
Would you rather have a system where you have to manually implement every patch, or would you rather have a system where you didn't have any choices which patches were implemented?
That argument is an example of a logical fallacy called "bifurcation" - presenting two alternatives as if they were the only two alternatives, when in fact more may exist.
Somehow I keep my Debian system updated with the latest security patches without much effort, and without being forced to accept patches I don't want.
Have you got your LWN subscription yet?
... is that oopses like this one have exactly zero impact on their market share, companies' acceptance of MS "solutions" etc... This is not a free market as known for ages, definitely.