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.
I'm glad to say that my servers were unaffected. Slapper does not affect AS/400 nor Linux.
"History doesn't repeat itself, but it does rhyme." Mark Twain
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.
I agree, I am sure MS had policies in place to keep all public-facing servers fairly up2date. One thing that I found to be true is when the article mentioned that alot of the developers internally had installed SQL or MSDE on their workstations. I know that when our comapny got Code Red / Nimda, it was the developers workstations with IIS that were propagating it to the rest of the network.
Just goes to show that people who are paid to be technically apt can be just as much of a crutch and regular users.
"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.
If it is not cost effective for MS, which faces the highest damages from such incidents (think PR), to patch its own software, how can they argue it is cost effective for ANYONE to insure that everything gets patched?
It seems to me if one were to include the costs of patching, insuring everything gets patched, and the expected losses (I assume probality is inherently high in then non-Unix world) from the inevitable missed patch (or, nonexistent patch/late patch), MS TCO would go through the roof. Then again, maybe the entire concept of TCO doesn't matter when the most significant costs can be hidden from ignorant managers who act as the software purchasing agents of the company.
Sdelat' Ameriku velikoy Snova!
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.
Although I respect Bruce Schneier (like he cares), I think it's pretty stupid to be quoted saying "This shows that the notion of patching doesn't work," without providing an alternative solution. I would love not to patch my servers, but perfect software just doesn't exist. What options do I have?
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.
1) Went to a news site (MSNBC? I forget...) - decided to try running a video - told me it needed the Microsoft plugin, sent me to Microsoft site to download Media Player 9.
2) Said okay, what the hell, I'll get it, EULA or no, downloaded, installed.
3) Broke my wallpaper changer - began giving me divide by zero errors when I changed wallpaper. Why? Who knows?
4) PowerPro began to crash on reboot for the wallpaper thingy... Why? Who knows?
5) Uninstalled Media Player 9.
10)Uninstalled WallMaster, reinstalled WallMaster.
11)WallMaster and PowerPro problem go away.
12)Irony - Even after I installed Media Player 9, the fuckin' news site STILL SAID I NEEDED THE PLUGIN!
Fucking morons...
Within the next six months, I intend to go Linux only and wipe fraggin' Microcrap off the disk...
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
You have to assume there *are* holes in application software such as SQL server due to its complexity.
Taking a reactive approach, and simply installing hotfixes are they're available will simply not work - patches are often not available until a number of days/weeks/months until after the vulnerability is known. Even if it hasn't been fully disclosed, the blackhats may well know about it, or be prompted to scrutinize that particular product more and find it before the full announcement.
The correct way to deploy such products is to design your network with this in mind, and firewall them off from the rest of the world.
That does NOT give you the security to not worry about patching (single layer security is bad) - keep your servers patched - but it does buy you a little time, and is an extra layer of defense in case there is a server that doesn't patch properly for some reason (file couldn't be overwritten for example), or is accidentally forgotten about.
I can think of *no reason* why an SQL server must be accessible to the world. You have a webserver that uses it as a back-end? Give the public access to port 80/443 of that ONLY, and disallow connections from anywhere but localhost to the SQL software. Even better (and the approach I always take - I don't trust Win-X to be visible to the internet, period), install it on a seperate physical machine, firewall that machine more tightly (ie, allow SQL connections ONLY from machines that require them, such as your webserver).
If you have client machines that need to access the database from the internet, thats what VPNs are for.
Since I've had enough sense to firewall my servers correctly (yes, I was a clueless idiot before as well ;), I have not had a single security breach.
I'm not saying that I'm definately immune to a concentrated attack, but you can definately stack the odds in your favour.
Yes, it is an investment in time, and probably money - but if you want a secure network, its simply the price you have to pay these days... how much is your data/uptime worth?
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.