The Zotob Worm

If you’ll forgive the possible comparison to hurricanes, Internet epidemics are much like severe weather: they happen randomly, they affect some segments of the population more than others, and your previous preparation determines how effective your defense is.

Zotob was the first major worm outbreak since MyDoom in January 2004. It happened quickly -- less than five days after Microsoft published a critical security bulletin (its 39th of the year). Zotob’s effects varied greatly from organization to organization: some networks were brought to their knees, while others didn’t even notice.

The worm started spreading on Sunday, 14 August. Honestly, it wasn’t much of a big deal, but it got a lot of play in the press because it hit several major news outlets, most notably CNN. If a news organization is personally affected by something, it’s much more likely to report extensively on it. But my company, Counterpane Internet Security, monitors more than 500 networks worldwide, and we didn’t think it was worth all the press coverage.

By the 17th, there were at least a dozen other worms that exploited the same vulnerability, both Zotob variants and others that were completely different. Most of them tried to recruit computers for bot networks, and some of the different variants warred against each other -- stealing "owned" computers back and forth. If your network was infected, it was a mess.

Two weeks later, the 18-year-old who wrote the original Zotob worm was arrested, along with the 21-year-old who paid him to write it. It seems likely the person who funded the worm’s creation was not a hacker, but rather a criminal looking to profit.

The nature of worms has changed in the past few years. Previously, hackers looking for prestige or just wanting to cause damage were responsible for most worms. Today, they’re increasingly written or commissioned by criminals. By taking over computers, worms can send spam, launch denial-of-service extortion attacks, or search for credit-card numbers and other personal information.

What could you have done beforehand to protect yourself against Zotob and its kin? "Install the patch" is the obvious answer, but it’s not really a satisfactory one. There are simply too many patches. Although a single computer user can easily set up patches to automatically download and install -- at least Microsoft Windows system patches -- large corporate networks can’t. Far too often, patches cause other things to break.

It would be great to know which patches are actually important and which ones just sound important. Before that weekend in August, the patch that would have protected against Zotob was just another patch; by Monday morning, it was the most important thing a sysadmin could do to secure the network.

Microsoft had six new patches available on 9 August, three designated as critical (including the one that Zotob used), one important, and two moderate. Could you have guessed beforehand which one would have actually been critical? With the next patch release, will you know which ones you can put off and for which ones you need to drop everything, test, and install across your network?

Given that it’s impossible to know what’s coming beforehand, how you respond to an actual worm largely determines your defense’s effectiveness. You might need to respond quickly, and you most certainly need to respond accurately. Because it’s impossible to know beforehand what the necessary response should be, you need a process for that response. Employees come and go, so the only thing that ensures a continuity of effective security is a process. You need accurate and timely information to fuel this process. And finally, you need experts to decipher the information, determine what to do, and implement a solution.

The Zotob storm was both typical and unique. It started soon after the vulnerability was published, but I don’t think that made a difference. Even worms that use six-month-old vulnerabilities find huge swaths of the Internet unpatched. It was a surprise, but they all are.


This essay will appear in the November/December 2005 issue of IEEE Security & Privacy.

Posted on November 11, 2005 at 7:46 AM • 17 Comments

Comments

Tom GrantNovember 11, 2005 9:27 AM

"Zotob was the first major worm outbreak since MyDoom in January 2004."

I guess that "Sasser" in May of '04 was 'minor' then?

Automated patching tools are not a panacea. Mission critical applications (especially in CITRIX environments) require extensive testing before a patch hits the production environment.

However, this is no reason for inaction. Patch Management needs to become a "normal business process" rather than
an "exception" caused by circumstance.

By being proactive and keeping systems patched and up to date "we" can slow the spread of this crud way, way down.

"Zero-day" exploits may always be a big threat...but even those can be cut down on if software houses tighten up their code standards (or hire 3rd party firms to test their code for them).

Bottom line, patch security is a process...make it part of yours (if it isn't already).

C TurnerNovember 11, 2005 9:30 AM

You say "What could you have done beforehand to protect yourself against Zotob and its kin?"

Simple, use something other than Win-whatever.

Tim HowlandNovember 11, 2005 10:07 AM

Well, you need to do the same things you do with any other communicable disease:

1) Reduce contact with people who are infected.

2) Wash your hands frequently

3) If there's an immunization shot available, and the medical side effects from the shot seem to be manageable, take it

4) Don't sleep around

5) Don't sleep with people who sleep around

6) If you find the son of a bitch who is spreading smallpox-infected blankets, throw his sorry ass in jail

I think medicine is a better analogy than hurricanes, but that's just me ... :)

DeepakNovember 11, 2005 10:19 AM

this industry is not taking our patch releases seriously. the industry should think that we are really doing very important stuff. ok i ll do one thing. i will search a vulnerability in my product (thats a 15 pico second job) and write a virus which will exploit that vulnerabilty. and then after releasing my regular patch on tuesday, i will "release" the virus in the same weekend. so what will those experts out there will say :
"had we installed the patch as soon as it was released, we would have been safe from this virus"
and i will do the same for a couple of times until the "had we installed ....." argument gets deep in the minds of the experts.

thats it. then all our pathces will be downloaded like hell, as soon as they are released. wow (self patting) ...

-One microsoft manager

Erik W.November 11, 2005 10:48 AM

@Deepak
The problem is in these two sentences: "Far too often, patches cause other things to break." and "its 39th of the year."
39 critical service bulletins in 8 months. One major security hole per week, more or less.
Now, assume I am the network manager of a large company...maybe 600 PCs under my care; most running a standard suite of software, but with many oddball things, and not all local to me. What you're suggesting is that once a week on average I have to drop everything, download your patch and test it against EVERYTHING running on my network and then roll it out.

What you're saying is that I have to have someone whose whole job it is to do this.

JimNovember 11, 2005 10:52 AM

"Could you have guessed beforehand which one would have actually been critical?"

I couldn't have guessed, but the SANS Internet Storm Center had released warnings earlier in the weekend about the likelihood that an outbreak was immanent. Their advice on or about 12 August... "Patch now!"

If you don't follow ISC as one of your primary security tools, you risk your systems.

@C Turner
Do you care to comment on the PHP worm that is currently spreading around various Linux installations where the recommended recovery action is rebuild the server?

DeepakNovember 11, 2005 11:17 AM

@Erik W
no. i am not asking you to immediately install what ever is released....

i am just trying to highlight a possibility which the vendor could (unethically) use to establish a practise in the industry

ARLNovember 11, 2005 12:02 PM

Allan Cox said it best when dealing with the issue of comparing security in Windows and Linux "Neither is good enough". I take the position that it is like two privates arguing over who has the higher rank.

Programs that have problems with patches may have issues of their own. If a patch breaks something then it is possible that the programmer was mis-using something to start with.

Erik W.November 11, 2005 12:43 PM

@Deepak
But I wasn't responding to your plan; I was responding to this: "this industry is not taking our patch releases seriously. the industry should think that we are really doing very important stuff."
My point is that to "take [your] patches seriously" is a full-time job. And I don't (and the industry as a whole doesn't) think it should be. And even if every IT professional on the planet did agree with you, the corporate world wouldn't pay for it.

Erik W.November 11, 2005 12:48 PM

@ ARL
in my experience, once one's company is invested in a particular application and counting on it to do the work of the company, the fact that it's written poorly and is fully culpable for the fact that it breaks when an OS patch is applied doesn't matter. We don't have the time or leverage to make the guys who wrote it go back and follow the rules; we just have to deal with the results.
Yes, in an ideal world, I would be able to contact those guys and say "your shit broke when we patched the OS! You better fix this!" and they would have a new version out right away.

And I'd get a pony.

MithrandirNovember 11, 2005 2:09 PM

Proactive protection, perhaps? There exist products that stop zero-day exploits. My employer sells one. It stopped Zotob quite nicely, without any updates.

The nice thing about these is that they make patch deployment less urgent, so adequate compatibility testing can be done.

CyphrpunkNovember 11, 2005 7:33 PM

How did the Zotob worm spread? Wouldn't an ordinary Linksys router, used in many home cable and DSL installations to share connections, be enough to keep the problem at bay? Getting a $30 router seems like cheap insurance against this kind of thing.

Davi OttenheimerNovember 12, 2005 1:02 PM

@ Deepak

"i will search a vulnerability in my product (thats a 15 pico second job) and write a virus which will exploit that vulnerabilty"

Please explain why that "15 pico second job" should wait until AFTER the product is shipped.

One would think that vulnerabilities so easy to find should be identified prior to release and if so susceptible to remote worm/virus attack should be fixed earlier as well.

Davi OttenheimerNovember 12, 2005 1:09 PM

@ Bruce

"Although a single computer user can easily set up patches to automatically download and install -- at least Microsoft Windows system patches -- large corporate networks can’t."

I've worked on automated data distribution solutions that touch over 100,000 systems and dispute your claim that large corporate networks can't automate patching. I think Patchlink, BigFix, Shavlik, etc. would also disagree with you.

The issue is that many large environments won't make changes without controls in place to evaluate the risk of fixing bugs, but they often are not able to place the same rigor around estimating the risk of not fixing them (because the threats are tough to gauge without specialized knowledge).

CalabashNovember 14, 2005 4:01 AM

Remarkably, there's been no mention (until now) of a significant development noted in passing in Bruce's comments:

"Two weeks later, the 18-year-old who wrote the original Zotob worm was arrested, along with the 21-year-old who paid him to write it."

Ponder that: 2 weeks to arrests. Let's hope we see more of this. And yes, I know that an arrest is not equal to a conviction after trial.

Davi OttenheimerNovember 14, 2005 8:34 PM

@ Calabash

Good point, and another example of how regulations (laws) might help steer the market away from abuse. The theory is that going to jail is a big disincentive for anyone who might try to exploit vulnerabilities in a system, due to the negative consequences. But what about cases where the person is a corporation and the motive is profit (e.g. Sony DRM)?

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..