Slashdot Mirror
Win32 Blaster Worm is on the Rise
EvilNight writes "You know you've got it when a 60 second shutdown timer pops up on your screen. The virus uses the RPC vulnerability. It looks like it's reaching critical mass today. Luckily, it's an easy one to stop: Download this security update. Once you've installed that patch, go here and
download the removal tool." Update: 08/12 19:19 GMT by M : Security bulletin URL corrected.
The removal tool takes several minutes to run.e fault. asp?url=/technet/security/bulletin/MS03-026.asp
Just apply the exact patch and remove the msblast.exe from your windows/system32 directory.
Then run the tool afterwards to ensure it has
gone.
The exact patch needed is here
http://www.microsoft.com/technet/treeview/d
Mouse powered Chips, Open source Processors and Lego
Yes, yes, I know, this is /. and we all know this. My point is that the mainstream press is starting to make the distinction now.
Home users, maybe but businesses????
;-)
The largest ISP in Sweden, Telia, had 40 servers collapse from this virus and in effect prevented 16,000 users from logging on to their ADSL service. That gives you a great deal of confidence in an ISP, right?
Beware: In C++, your friends can see your privates!
Now, I didn't get hit -- between the firewall, ZoneAlarm and the patches, I think I'm Ok.
Design for Use, not Construction!
I patched my home machines probably within 24 hours of the patch being available. I've got a couple of machines, and nobody is depending on their uptime to make a living or maintain a professional corporate image. If only the real world were that easy.
My company lives in the real world. We were hit by this, but pretty lightly, a couple of machines and we were lucky enough to pull the plug on them and cut it off before it spread, mostly because I was monitoring slashdot, and I knew the symptoms of the infection the first time it came up internally.
Our firewall wasn't breached so much as apparently circumvented by a laptop belonging to a user that never accepted the patch -- he got the virus at home, then came to work and plugged in. I assume that just about any company with a firewall at all isn't allowing incoming TCP 135, so I'm guessing that hard-hit companies generally got it this way.
We had identified this patch as critical, even relative to all the other less-critical critical patches. That still meant we had to test it outside of production, which took some time, and we also had to keep an ear to the ground to find out if any of the (many) folks out there who apply patches without testing first had been burned by this one.
When we were satisfied at that point, we had made it available internally to all workstations via SUS -- worst case scenario here if the patch is bad is a lot of re-imaging, but no loss of data, no loss of critical network services, etc. We don't have workstations set to auto-install the patches, so that requires the user to click an install button to complete the process. In many cases, the users had done that. In some, they hadn't.
At that point we started pushing it out to machines via SMS, workstations first, and then starting to patch the servers. (I wish I could give you a timeline for each step here.) Again, we proceeded conservatively, not getting every box at once, and not letting SMS force our servers to reboot after the patch installation, but instead asking various sysadmins to schedule reboots for servers at an acceptable time as soon as possible after the patch was applied.
So, some servers were patched by yesterday. Probably half were not, especially if you count those that were patched but not yet rebooted, which you have to count as not patched, I guess. To my knowledge at this point, we cut this off before any servers were infected, which was really just luck once it was inside the firewall. It could have been worse, but at the same time, many of our boxes were safe by the time yesterday came.
Now, of course, we are frantically patching and rebooting. And if we had been a little more frantic beforehand, we could have easily had it done before yesterday. But little else is getting done today. We've got over 100 Windows servers to deal with here, production, development, testing, IIS, SQL, SMS, DCs, Citrix, physical machines, virtual machines, you name it. It is not trivial to get this job done. And doing it in a hurry is dangerous as well.
And we're lucky. All our boxes are at one location. I'm looking back at how we handled this, and I think that a little more focus and emphasis and we could have patched everything by now, but the attack could just as easily have come a week sooner, and we'd still be having this conversation.
The difficult truth is that, in many cases, it is possible to develop an exploit for a vulnerability more quickly than it is possible to adequate test and deploy a patch in a large and complicated corporate environment. You patch as quickly as you safely can while still getting everything else done, and you also take all the other steps you can to mitigate the damage if you get hit. That's the real world.
That's the legacy of MS policies like "DOS ain't done till Lotus don't run!"
You just know you'll let auto-update run and one day it'll "disable" your MP3s because WMV offer so much more security, or something similar.
Microsoft tested Windows NT 4.0 and Windows NT 4.0 Terminal Server Edition. These platforms are vulnerable to the denial of service attack however due to architectural limitations it is infeasible to rebuild the software for Windows NT 4.0 to eliminate the vulnerability.
Well, we patched what we could, and moved most critical services to Linux, but there's still one or two machines running NT. And it's only a matter of time before some luser slips a copy of this worm past our firewall....
Considering the amount if infrastructure that depends on NT4, doesn't this intentionally put the US at greater-than-necessary risk? I'd be fun to see M$ tried under the new anti-terrorism laws.....