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.