Federico Biancuzzi interviews Jose Nazario to discuss modern computer worms and the design goals behind them.
Could you introduce yourself?
I'm Jose Nazario. You may know me from endeavors such as Wormblog and InfosecDaily, two sites I created to help myself and others keep abreast of information security knowledge. Wormblog is a project I started in the spring of 2004 as a way to post paper abstracts and events in the worm landscape. InfosecDaily was a system I set up for myself to track blogs, news, and notices in information security. There's hundreds of sites to track, and I wanted a way to look at it all in one glance, so I set up an automatic news creation system. The sites are public, and anyone is free to look at them. Infosecdaily, together with Ejovi Nuwere, has recently undergone a nice transformation to help manage the news flow.
I currently work for Arbor Networks, a network security solutions provider. We help secure enterprises and service providers from a variety of threats, including worms and DDoS attacks. Prior to joining Arbor I contributed to and worked on a few open source projects, including LinuxPPC (many years ago), libnet and OpenBSD, and completed a Ph.D. in biochemistry at Case Western Reserve University where I studied enzyme kinetics and mechanisms.
While studying for my Ph.D., I began to get interested in high performance computing, specifically for large scale dynamics calculations. This required me to learn a lot more about computing than I knew previously (I had always dabbled), and I began to enjoy the computing circles a lot more than the biochemistry ones. After a security incident on a server I ran, I dove head first into that speciality. Along about 1999 or 2000, I participated in a number of forensic investigations and incident response activities. One of the things we found was that a DDoS toolkit was being distributed using a simple, worm like program. Between this and the ADMw0rm, I saw a trend emerging. We looked at some of the evidence in front of us and made some extrapolations and eventually wrote them up as "The Future of Internet Worms", which I presented at the BlackHat briefings in 2001. What's funny is that in the past couple of years we're starting to see these ideas come to fruition with systems like the RBot and NeseBot families.
Worms were particularily fascinating to me because of my studies in enzyme kinetics, or their rates of catalysis. Self propagating network worms are somewhat similar to biological populations, so the concepts and math were familiar to me. It was a natural fit, and I came along at the right time.
Is there any way to take advantage of the worm's speed of spread and use it for something good?
In theory, sure. In reality, I haven't seen it.
When a worm hits, suddenly you're faced with a challenge: an adversary that can be moving very quickly and launching from an increasing number of points. A problem that was once in only one place is suddenly everywhere. It's a challenge to stop the spread of worm. Bruce Ediger has explored this in theory, and he's a big proponent of the idea.
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)?
A number of reasonable ethical concerns also come to mind. How would you prevent the worm from propagating beyond your responsibility's border? How would you ensure that the patch really worked and stopped the worm? How would you shut down the worm?
None of these real world concerns are satisfied, in my experience, with counterworms. Too many problems crop up and they're simply never effective at really slowing down the worm. The Nachi or Welchia worm didn't stop the Blaster worm from propagating too quickly.
Bear in mind that you can beat the worm to the punch. You own the network, you own the hosts. You have legitimate, immediate access everywhere. Once you detect the worm, you can employ a number of specific actions on your network to stop the worm's spread, through firewall rules, router ACLs or even VLAN ACLs (VACLs). You can also use agents on the hosts to deploy patches, shut off services, or quarantine or vaccinate the hosts immediately.
This approach remediates the concerns I have about legitimate access, breaking software installations, shutting down the action immediately and controlling the effect.