So, as the Code Red worm comes to the end of its day in the sun, I've been wondering how it could have been better.

Note that this is not notice of intention to actually write a worm. I have no desire to do so. However, every time a new worm makes its way onto the scene (whether something automated like Code Red, or something socially spread like Melissa), I find myself thinking, "If the coders of this only had a brain, then it could have been a lot worse". With that in mind, I decided to arbitrarily award myself the qualification of having a brain, and I got into a conversation about how to make a worm better.

First point: it needs to be able to adapt to new exploits out there in the wild.
This is of central importance. Otherwise, people can just patch the exploit that the worm uses, and, lo: it dies. What with IDS systems out there watching for specific code strings, email gateways that block everything with a hint of scripting in it, and the occasional sysadmin who not only keeps up with security but gets around to applying patches to his software, it's a tough life for a poor worm trying to make its way in the big wide world.

Therefore, we come to conclusion number 2: the worm must be remotely controllable.
Steve Gibson, in his essay about how grc.com was DDoSed, tells of Zombie bots, which connect from a cracked machine to an IRC server and await commands. This sort of principle should be co-opted into a worm, so that the worm can receive new exploits, and thus live on beyond its single attack being patched or blocked.

That being the case, we can see that conclusion 3 will state that adding new exploits to a worm remotely pretty much requires the worm to embed some kind of scripting language.
This is, of course, unless the worm's owner intends to send binary patches for the worm to apply to itself (which seems rather like hard work -- if you're going to go to all that effort, why not just dispatch a new worm?). Since the worm must either pass the language interpreter around with itself, or download it from somewhere, we conclude that it has to be small. There are dozens of languages out there, and there's nothing stopping the worm's author from writing their own, but it seems to me that the best bet would probably be Tcl, since you can get a small Tcl installation, libraries and all, into under 100K, which is impractical for most languages that would include file and socket manipulation, both of which are obviously required.

One of the other reasons for choosing Tcl is that it is cross-platform, which is point number 4: the worm should run on more than one platform, if at all possible. If it can run on multiple platforms, then it can spread more easily; limiting it to one platform may well mean that all its known lines of attack are blocked and it dies before a new exploit comes along. We'll come back to implementation of this point in a short while.

The worm, for minimal size, should also be able to download things from the net (this is point 5). Now, people have tried having a worm contact a fixed point on the net in some way before; either by downloading parts of itself or by sending information (such as grabbed passwords) back to a mailbox or web page CGI. This, though, introduces a single point of failure into the worm; block the downloads, or track the downloads, or close the mailbox, or find out who owns the mailbox, and you may be able to stop the worm, or find out who wrote it. This is where distributed file storage networks can come in handy. Imagine if the requisite downloadable parts were posted to a Usenet binaries group. That way, the worm can use any news server that carries that group (and there are countless lists of news servers on the net -- the worm could probably find some using Google) and grab its extra binaries. Cancels are notorious for not being honoured, especially in alt groups, so once the binaries were posted to Usenet, it would be difficult to get them back. This binary download tactic would be useful for cross-platform operation; the worm can attack a given OS platform box using a stored exploit, then download the binary for that OS to run on it or to add as part of the buffer overflow coded in the exploit. These binaries wouldn't need to be big; they really only need to bootstrap the downloading of the scripting engine, in which the bulk of the virus code could be written.

In short, then, a worm that can take on new exploits would be very difficult to kill, especially when combined with the other points above. This is a concerning thought; if I've thought of it, so have other people, and they might be the sort who would actually construct and deploy such a thing. How long can it be before we see worms that exhibit some degree of intelligence and user-controllability?

(with thanks to magenta)

© Aquarius, July 2001