Steven Drew and Joe Stewart argue that it is possible to be forewarned and forearmed against even sophisticated internet worms
It's no secret that internet worms are becoming more and more advanced. With each incarnation, they are able to disrupt the internet as never before. Up to this point, the damage has been relatively small in comparison to what a truly nasty worm could do. Sure, the denial-of-service effect of Slammer put some companies out of commission for a day or two and stopped some ATMs and other services from working. But for the most part simply blocking UDP port 1434 on core routers quickly contained it. The worm writer witnessed this, and you can bet the next worm will not be so easily countered. That's why it is important to begin preparing now for the next outbreak.
Worms have been around for a couple of decades, but their frequency of occurrence is rapidly increasing due to two things. First, the population of vulnerable hosts has exploded. Second, the knowledge needed to write a worm is more widely available, literally a few clicks away from someone with the malice and forethought to write one. Much of the work needed to write a worm is actually done for them by legitimate security researchers. Worms are an unwanted side effect of the full-disclosure policy of many security institutions. However, the additional boost they get also becomes a weakness, as the worm writers lose the element of surprise.
All of the worms in the past three years have followed a particular pattern. They share common factors that contributed to their development. These factors are like pieces of a puzzle. If all the pieces are not present, worm emergence is unlikely.
Factor 1: Security advisory
The first factor needed is an advisory released by a vendor or an independent researcher. An advisory is considered serious enough to be republished by CERT and other institutions.
Factor 2: Exploit code
The second factor is working exploit/ proof-of-concept code, either by the researcher or a third party. Worm writers could develop the exploit code themselves, but the time invested in exploit development can be considerable; perhaps even more so than the actual spreading code of the worm. It is easier to wait for someone else to do the initial legwork. So far this seems to have been the case in the past five years.
Factor 3: Targets
A third and very important factor in worm propagation is target selection. Sometimes a target may be several versions of the same vulnerable program. In these cases, the worm must find common hooks in the code it is overflowing, since the environment where the worm gains control may change with each release. The program might even run on multiple operating systems; in which case the worm code might need to be radically different in order to execute on each platform.
The more a worm has to adapt to fit different versions, the more code it must contain. This bloat is detrimental to the rapid propagation of the worm. It also requires greater expertise and a longer testing cycle. Worm writers are then more likely to look for vulnerabilities in software that is single platform and prolific in major versions. For this reason IIS and Microsoft SQL have been prime targets for more than one worm. While Apache is more widely used than IIS, it exists on so many platforms that writing a single buffer overflow exploit that would be guaranteed to work on a large enough subset of them would be extremely difficult.
Factor 4: Time
The final factor in worm development is, like any other software development project, time. A worm writer needs time to code and test the worm before releasing it in the wild. The length of time varies; however, the past four most notable worms, Code Red, Nimda, Slapper and Slammer all had a gestation period of one to six months. Below is a timeline of the development of all four worms. The timeline extends into the future, because it is a good bet that all four worms will still be alive and well at the end of 2003 and beyond.
It is important to note that the worm writer must try and release working code as soon as possible. The longer they wait, the more systems will have been upgraded or patched. There is a definite time frame in which worms are viable. We need to look back in that time frame and guess where the next attack will come from.
If we were to try and predict the next vector of worm infection, we should look at the past six months' advisories and take note of how each one fits into the typical worm mold. These are serious flaws, but are they potential sources for new worms? Applying the worm development factors to recent vulnerabilities, we can eliminate some or all of them as new worm vectors. The table above shows CERT advisories linked with the information available at the time of writing. This is of course subject to change without notice.
At the time of this writing, the only reasonable current worm vector is the DHCPD vulnerability. It fills all the criteria need for worm development. If it were to be the next worm, we believe there are enough broadband users with a Linux firewall who are running vulnerable versions of DHCPD to achieve critical mass. This doesn't necessarily mean there 'will' be a DHCPD worm. However, the elements for a DHCPD worm are present.
What can be done?
Because of the predictability of worm development, we should not be caught totally unprepared. While there is little the average sysadmins can do to mitigate the effect of a worm on the internet as a whole, they should plan for protecting their own network as best as possible. An outbreak on the internet is an inconvenience; an outbreak on your internal network is potentially devastating. Make sure you have a plan in place, because it is no longer a matter of if the next worm will strike, but when.
Steven Drew is vice president of managed security services, and Joe Stewart is a senior intrusion analyst with managed security services provider LURHQ Corporation (www.lurhq.com).
Mitigating the risk of worm attack
Here are some tips to help you fight worm attacks: