worm blog

Nematodes – Beneficial Worms

Yet another appearance of the "Good Worm" idea, this time from Dave Aitel. Dave's done two things with this idea, he's proposed a case for the beneficial worm and he's created some code to generate them efficiently.

This presentation presents concepts for taking expoitation frameworks into the next evolution: solving complex security problems by generating robustly controllable beneficial worms. The Why, How, and What of Nematode creation are discussed, along with some concepts in Mesh routing.

Problems discussed include legal issues, controlling your worm, writing an intermediate language, the Nematode Intermediate Language (NIL) for writing robust worms, reliability problems, commications protocols, and future work.

Nematodes – Beneficial Worms, given at Hack In The Box 2005 in Kuala Lumpur, Malaysia.

Anyone who reads this site regularily knows that I am wholely opposed to the idea of actually using a "good worm" for a variety of reasons. Dave brings up a few good points that are difficult in some scenarios: an enterprise network is a distributed scenario hard to manage from one location, it's the things that you didn't instrument with a patch management agent that often cause you problems, and it's a race against the worm. These are all fine problem statements, but they're also all solved.

Asset discovery (see slide 17) is easy with an instrumented network that does passive, constant monitoring. Several products and tools do this, this isn't a hard problem any longer. Patch management already provides a way to manage the hosts you do have under your control in a distributed, scalable fashion. And finally you can always filter a host or a service if you have problems with something. You own the network, you own the distrubution layer, you can do whatever you want.

Worms or nematodes are a poor choice for this problem for the following reasons: bandwidth consumption, management, and the introduction of instability into your network. Nematodes work by breaking into hosts and installing themselves, which can break production software that wasn't supposed to go down. For example, the Code Red and Nimda exploits had negative effects on non-IIS servers at times, including the Cisco embedded web server on many routers and switches. This is not a good thing to have happen with your management techniques. Managing a deployed worm is a difficult task, and Dave simply glossed over it. If you leave them run forever to try and gain completeness, you run the risk of them walking out the door on a laptop and spreading wildly. You can't direct them, and you can't stop them reliably once they're out. Finally, all that scanning and attack activity will consume great quantities of bandwidth and cause network fabric load to skyrocket. Again, not a good thing.

While Dave correctly points out some problems that need better solutions, I don't see how unleashing a wild agent on your network will improve the situation.

What is interesting out of Dave's talk is the nematode generation tools he wrote. They work well, and the yget around the problem of a lot of boilerplate code that has to be written for any worm. This is potentially a scary development, as more sophisticated attackers will begin improving their worms with these kinds of tools and dropping in exploits in a matter of minutes. Expect this to become a problem in the short term. One possible solution: write your IPS and IDS signatures (ie Snort, Bro, ISS, etc) against the core code of the system that is more or less invariant because it is that boring, boiler plate code. Then you may be able to track the appearance of these new worms without knowing the exploit they're using.

Jose Nazario discusses worms

At the risk of looking like I'm just tooting my own horn, I'll make mention of a recent interview I had about the worm problem. In a recent SecurityFocus interview, I spoke at length about the worm problem. The interview focused mostly on counterworms, a subject which comes up here from time to time. Here's an excerpt:

It's tempting to think about fighting fire with fire when a worm hits -- launching a counterworm to stop the worm. The most natural thing to do is to deliver a counterworm with a payload that contains the patch for the security vulnerability exploited by the worm, which would prevent its spread.

However, remember the following things. Even if you knew instantly what vulnerabilities the worm was exploiting and how to prevent its use of that hole, how would you prepare a worm with the patch payload in time to launch it in a meaningful time period? How would you outpace the worm (in about 6 hours, Blaster had reached it's peak propagation speed; SQLSlammer reached that speed in a matter of a few minutes; Witty hit that point in a matter of minutes, too)?

Source: Jose Nazario discusses worms, an interview by Federico Biancuzzi, posted on 2005-08-16 at SecurityFocus.

On the functional validity of the worm-killing worm

Another paper that looks at the counterworm principle, some modeling, and attempts to come up with a better way to utilize this approach and not cause any of the obvious harmful side effects. I don't buy it, and I'm still against the idea of a "good worm".

The notion of worm-killing worm has been in the folklore for some time . However the obvious fear of the killer worm itself being compromised, or of any self-propagating code set loose (possibly over administrative boundaries), has barred serious exploration on the practical aspects of the idea. In this paper, we suspend such concerns momentarily, and investigate its functional validity. This effort is motivated by recent fast worm epidemics exemplified by that of SQL Slammer, which was overwhelmingly faster than traditional human-intervened response. Specifically, this paper evaluates the killer worm in terms of the prevention effect and the incurred traffic cost. Above and beyond, we consider supplementary techniques that could boost the performance and mitigate the harmful side -effects of the worm-killing worm.

Source: On the functional validity of the worm-killing worm, Hyogon Kim and Inhye Kang.

Return of the Anti-Zombies

Larry Seltzer, a columnist and writer at eWeek, has a nice opinion piece on the eWeek website concerning counter-worms. It mirrors many of the opinions I've expressed here, and squares off against many other opinions people have expressed, including Timothy Mullen's "Strike back" approach. A good read.

It's a recurring theme on security discussion lists: Someone ought to build a worm that infects insecure systems and remedies the problems on them.

Every six months or so someone thinks they're the first one to think of it. So in case any of you think it's a good idea, please stop wasting your time. It's a dreadful idea, it's been tried, and it's failed in the most miserable way. It's a Frankenstein's Monster in an e-mail attachment.

Source: Return of the Anti-Zombies, opinion by Larry Seltzer, posted June 28, 2005.

Models of Internet Worm Defense

David Nicol has an interesting presentation slide deck available, Models of Internet Worm Defense [PDF]. Sadly, there's no abstract associated with it, but Nicol's slide deck covers a number of mechanisms peple have looked at for worm defense, including quarantine, counter worms, and patching. He backs up his analysis and conclusions with sound mathematical modeling and lots of equations, as well as pretty graphs. You'll want to study the graphs for a while to see the true story there. If you print them out, make sure you get them in color as some of the information is stored in the color spectrum used.

WORM vs. WORM: Preliminary Study of an Active Counter­Attack Mechanis

Even more on the good worm strategy:

Self-propagating computer worms have been terrorizing the Internet for the last several years. With the increasing density, inter-connectivity and bandwidth of the Internet combined with security measures that inadequately scale, worms will continue to plague the Internet community. Existing anti-virus and intrusion detection systems are clearly inadequate to defend against many recent fast-spreading worms. In this paper we explore an active counter-attack method - anti-worms. We propose a method that transforms a malicious worm into an anti-worm which disinfects its original. The method is evaluated using the CodeRed, Blaster and Slammer worms. We show through simulation the effectiveness of an anti-worm with several propagation schemes and its impact on the overall network. We also discuss important limitations of the proposed method.

Source: WORM vs. WORM: Preliminary Study of an Active Counter­Attac Mechanisms, Frank Castañeda, Emre Can Sezery, Jun Xu.

Even More "Good Worm" Papers

An interesting paper by Nicol and Liljenstam makes a decent theoretical case for a defensive worm. This paper takes into account various forms of an active defensive worm. It ignores any ethical or legal implications of such a worm and only provides an analytical model.

The recent proliferation of Internet worms has raised questions about defensive measures. To date most techniques proposed are passive, in-so-far as they attempt to block or slow a worm, or detect and filter it. Active defenses take the battle to the worm—trying to eliminate or isolate infected hosts, and/or automatically and actively patch susceptible but as-yet-uninfected hosts, without the knowledge of the host’s owner. The concept of active defenses raises important legal and ethical questions that may have inhibited consideration for general use in the Internet. However, active defense may have immediate application when con- fined to dedicated networks owned by an enterprise or government agency. In this paper we model the behavior and effectiveness of different active worm defenses. Using a discrete stochastic model we prove that these approaches can be strongly ordered in terms of their worm-fighting capability. Using a continuous model we consider effectiveness in terms of the number of hosts that are protected from infection, the total network bandwidth consumed by the worms and the defenses, and the peak scanning rate the network endures while the worms and defenses battle. We develop optimality results, and quantitative bounds on defense performance. Our work lays a mathematical foundation for further work in analysis of active worm defense.

Source: Models of Active Worm Defenses, David M. Nicol and Michael Liljenstam. This paper is related to their paper listed in an October, 2004, rundown of papers on this blog.

Their paper finds a number of interesting conclusions, but also notes that they fail to address truly real world scenarios. These include detecting the worm's initial outbreak and how rapidly a counterworm can be deployed.

More on the "Good Worm"

Some more materials on the concepts of the good worm. These are two slide decks on the topic.

In The coming age of defensive worms [PPT], David Meltzer (Intrusec Security) lays out a decent case for the use of counter-worms as a defense mechanism.

And in The Case for Beneficial Computer Viruses and Worms: A Student's Perspective [PDF], the author goes over some of the historical cases evaluating the concept of a beneficial worm.

In either case, I'm still not convinced. While I like agent systems and distributed computing, we have better ways of doing this now. And you still have reliable, trusted mechanisms to distribute updates or changes either in response to a worm outbreak or prior to one. No "beneficial worm" is needed in either case.

The Myth of the "Good Worm"

Over on a 'dot net junkies' blog I spotted a resurgance of the idea of a "good worm". The good worm theory pops up every now and then, usually pushed forward by someone who sees a current storm and recognizes that the world needs a solution to this problem. This problem moves so fast that the solution must move just as fast. A counter worm is a natural conclusion to come to. This ideas was even put forth this summer in Slate:

The only way to stop MyDoom might be to out-hack the hackers. In the past, "white hat" programmers have launched viruses that expose security holes without causing destruction in an attempt to make computer users more security-conscious. Last year, one programmer took the next step. As the Blaster worm circled the globe, the do-gooder released a worm called Nachi that infiltrated the same security hole as Blaster. But Nachi wasn't a Blaster variant, it was a Blaster antidote: It erased copies of Blaster it found on PCs it invaded, then downloaded and installed a Windows update from Microsoft to secure the computer against further Blaster (and Nachi) attacks. Ingenious! There was only one problem: Nachi overloaded networks with traffic, just like Blaster had.

One thing Paul fails to note, that Nachi was worse than Blaster in terms of network destruction.

The potential for help from a good good worm is nothing more than a myth. The Welchia worm, which was designed to remove the Blaster worm, caused more damage to Navy IP systems than Blaster did owing to it's mechansm of detecting available hosts (ping flood the network). Research measurements I helped take and analyze (also presented at NANOG, October 2003) show that the Nachi/Welchia worm which appeared a week after Blaster did little to stop blaster. It was global filtering that helped with that.

Why are "good worms" a bad idea? Simple, and we can refute many of the key points raised in this 1999 argument in their favor:

1. Lack of Control. Any worm almost always fails to do anything but spread as far and wide as it can. If you try and control where it goes you typically fail. The only control you have is over the vulnerable software or configuration element you're abusing in the first place. The natural argument seems to be "attack the backdoor of the worm", as the Dabber worm (it attacked Sasser's backdoor). However, this winds up failing in light of polymorphic worms, worms which can be tweaked to control their backdoor port, and sites that filter this new "service".
2. Recognition Difficulty. AV software, which is specially designed to do this sort of thing, routinely fails to detect variants. How can an amatuer expect to do this?
3. Resource Wasting. Look at the Netsky/Bagle/Mydoom wars from the spring of 2004 to see how messy this gets ... The Welchia example from above is another example.
4. Compatibility Problems. This is actually your biggest risk. Virus and worm authors can afford to trash systems, their goal allows it. The goal of a good worm is to "do no harm" and restore order. However, this is difficult, even in well tested configurations, simply due to the complexity problem. This rarely works.
5. Effectiveness. Data that we've collected (still waiting to publish it ..) shows that Nachi wasn't effective against Blaster. These things simply fail to work.
6. Unauthorised Data Modification.
7. Copyright and Ownership Problems. These two are related, not so much by copyright but by authorzation and ownership. Despite the best of anyone's possible intentions, it's still unauthorized use and access of resources. It's against the law in many countries. It's against the law for a reason, and intentions don't matter.
8. Responsibility. Ultimately the responsibility for the host lies with it's manager, and responsibility of ingress and egress traffic lies with the network managers. The use of "good worms" attempts to usurp that responsility without accepting the responsibility of fixing introduced problems. Again, did the Welchia author(s) stand up to accept responsibility for network disruptions from their creation? No. You simply haven't had reason to trust anyone to do this.

While this sort of thing may seem reasonable even in a controlled environment (ie a corporate network), consider this: you already have legitimate access to the system, so use it to your advantage. Install AV agents that are constantly updated, filter inbound and outbound traffic and payloads, and be ready to disconnect disruptive sytsems if you can.

The good worm is actually a myth and is likely to cause more problems than it's worth. Don't buy into it. Fighting speed with speed is one thing, but don't fight fire with fire.