Worm Lays Waste To IT's Defenses
Politics, project delays and an ineffective response allow for a Sasser disaster.
May 31, 2004 12:00 PM ETComputerworld -
I was planning to spend my week evaluating disk encryption products before the Sasser worm breached our defenses. What's more frustrating than the worm, however, is the fact that proposed projects that could have prevented it have been bogged down for a number of reasons.
My team and I are almost done selecting a patch management product and have all but decided on PatchLink Update from PatchLink Corp. in Scottsdale, Ariz. We run a wide range of servers and operating systems, and PatchLink seemed to work with the majority of them during our evaluation.
Meanwhile, we continue to deal with frustrating patching problems. The W32/Sasser attack is the latest example.
Sasser takes advantage of a previously known vulnerability within Microsoft's Local Security Authority Subsystem Service, which helps manage security and authentication for Windows networking. Had we applied the appropriate patches when they were released, my company might have avoided the worm.
As it was, we first realized that something had gone wrong when the IT help desk received a spate of calls about arbitrary system shutdowns and references to a dialog box indicating an "LSA Shell" problem. At about the same time, network bandwidth usage spiked.
We turned to our in-house Snort intrusion-detection system expert, who quickly associated the traffic with Sasser. This worm attacks by looking for vulnerable machines through TCP Port 445, which is used for Windows networking. Once Sasser finds a vulnerable host, it spreads itself by installing a file transfer protocol server on Port 5554 and leaves Port 9996 open for commands to execute. It then modifies several registry entries and services, causing the system shutdowns. Finally, it spreads by scanning other systems for vulnerable hosts and directing those to the FTP server port to download the malicious code.
The impact of Sasser on my company was substantial. Help desk calls started coming in from all of our hub sites as well as from overseas and remote users with corporate Digital Subscriber Line connections. Although we knew we had to find every infected system, we lacked the time and resources to locate them all. So, to buy time, we asked the network engineering group to reconfigure the access control lists on our network devices to block Ports 5554 and 9996. We use Mountain View, Calif.-based Solsoft Inc. to centrally manage many of our ACLs. Unfortunately, we also have many network devices that it doesn't manage, and we spent several hours visiting every one of them.
After the ACLs were updated, network degradation decreased, as did the
Security
Additional Resources



White Papers & Webcasts
Death to PST Files
Download Now
The Tangled Web: Silent Threats & Invisible Enemies
Download Now
Tape Killed the IT Guy
Watch Now
Forrester Consulting Mobility Study: Taking Control of Enterprise Mobile Device Diversity
Download Now
BRM: What You Can Do To Reduce Risk In Challenging Times
Watch this webcast now!
What IT Must Do to Support Employee-Owned BlackBerry, iPhone and Android Mobile Devices
Download Now
Web 2.0, Social Media and the Dark Web - A Web Criminals Paradise?
In this discussion, learn about the challenges of protecting your users from the potentially unsafe content hidden in the "Dark Web".
eGuide: Enterprise Security
Smart Security Strategies for 2010. Read now!
Disaster Recovery 2008: Reduced Costs and Improved Performance
How long can your Enterprise afford to be without your data? With an accelerated disaster recovery program, you never have to answer this...

