by Rik Farrow
Like the changing of the seasons, the appearance of new worms is now an inevitable event. This year, two particularly unwelcome visitors surfaced--each with something new to offer: Slammer, the fastest spreading worm experienced so far, and MSBlaster, which affected Microsoft RPC (Remote Procedure Call), an often-ignored but omnipresent service included with every Microsoft operating system (OS) since Windows NT.
These worms showed great prowess in sweeping past the security defenses of most organizations. Firewalls, IDSes, and anti-virus software didn't prevent them from spreading. But there are very good reasons why none of these technologies can offer bulletproof defenses against worms that exploit unpatched or previously undiscovered OS and application flaws.
Although other approaches to preventing the spread of new worms have been proposed in the past, none has yet gained widespread acceptance. But a simple concept--connection rate limiting (also referred to a virus throttling)--appears to hold promise.
When the SoBig.F email virus began spreading in August 2003, many people wondered why an old, but revised, virus was having such great success. SoBig required human interaction to spread, in that the user reading email had to click on a link to the executable before it could be launched. But that didn't stop SoBig.F from becoming one of the biggest viral nuisances of 2003.
Anti-virus software offers protection against known viruses. When a new virus emerges, vendors must analyze the virus, find a signature for it, add instruction on how to clean up an infected system, and distribute that information. Individual users and organizations must download the new signature, and network managers must also distribute it to all desktops. Inevitably, there are delays involved, giving the virus plenty of time to spread.
The Slammer worm, on the other hand, required no user interaction. Its forte was its ability to spread quickly. Although the patch for Slammer had been published six months prior to its outbreak, many systems hadn't been patched. And a patch for the flaw used by MSBlaster had been released a month before that worm surfaced.
I can hardly imagine a firewall configured to permit access to the Microsoft SQL Server port used by Slammer, yet this worm penetrated many firewallprotected networks with ease. MSBlaster used another unusual port, also unlikely to be permitted by most firewall configurations. And IDSes could do nothing but announce that something really bad was happening-- and only then if a signature for the exploit existed. By the time a human had time to respond, the damage had been done, and all that was left to do was to clean up.
Security researchers have suggested other approaches to exterminating worms. One of the best ways to prevent worms and viruses from taking down entire networks is to use a diversity of OSes--an unlikely strategy these days.
Containment of potentially dangerous applications on servers, in addition to Web browsers and email readers, has also been proposed. UNIX-based servers can be run in a jail, which protects the system it's hosted upon, and can be used to limit access to the network. Some researchers, and commercial products from vendors such as Finjan Software (www.finjan.com) and Aladdin Knowledge Systems (www.ealaddin.com), use sandboxing, the isolation of part or all of a troublesome application in a contained environment.
Microsoft has even embraced this notion to a limited extent by attempting to mitigate the damage that can be done using Internet Explorer (IE) and Outlook. IE can prevent the execution of code based on zones, and Outlook restricts access to the address book.
In 2002, Matt Williamson, a researcher with HP Labs in Bristol, UK, suggested something different. In a paper based on his research (see Resources), Williamson describes experimentation with throttling, limiting the rate at which a desktop computer could make network connections. By examining network traffic, Williamson discovered that most desktop users make fewer than two network connections per second, and many of those connections are to recently visited addresses. In comparison, MSBlaster could make hundreds of connection attempts per second, and Slammer could attempt thousands.
Williamson's idea wasn't to block outgoing connections, but to delay connections as soon as their number passes a low threshold-- for example, more than a single connection per second. Multiple connections to IP addresses stored in a short list would be permitted without delay. This design works well with Web browsing, in which each page visited usually results in the downloading of many images from the same IP address. Williamson discovered that his throttling design had the most impact on Web advertising, as it came from a site other than the desired Web server. With the throttling technique, this content would still be downloaded, but after some delay.
The notion of delaying rather than blocking possibly hostile activity had been suggested in a paper in 2000 by Somayaji and Forrest (see Resources).
In the researchers' design, a Linux system profiled every running application and introduced delays when a program behaved anomalously. The delays were hardly noticeable to users, but they stopped all attempted attacks.
It's a lot more forgiving to use delays instead of simply killing a program that is behaving anomalously. IDS researchers have worked hard to incorporate anomaly detection into products, but this has resulted in unacceptably high false positive rates. Anomaly detection can stop programs or network traffic that's been falsely accusing of misbehaving, disrupting normal computer and network usage. Inserting delays has less impact on normal use, but a lot of impact on rapidly spreading worms and viruses.
Another HP Labs project has resulted in an open-source email server that implements email throttling. An email throttle looks at recently Accessed email addresses,rather than IP addresses, but is very effective at stopping email viruses such as SoBig.
Despite these recent strides, flaws--including exploitable bugs--will continue to appear in software. In the infamous CyberInsecurity paper, Dan Geer, fired from @stake for authoring this paper writes that software complexity increases at a rate proportional to the square of the size of the code. As long as systems become more complex, we can expect to see weekly bug fixes, frequent worms that exploit unpatched systems, and exploits using flaws that have never been reported to a vendor for patching.
Throttling is at best a prophylactic measure--a means of reducing the rate of infection, but not stopping it. But for those who want to slow the spread of new worms and viruses, it's worth a try.
One year after this article was published, Microsoft released SP2 for Windows XP. SP2 includes a form of connection rate limiting similar, but not identical, to that described in this article and in the HP papers.
Microsoft's SP limits the rate of new connections when the number of incomplete connections has reached a threshold. This approach makes loads of sense, as typical virus and worm behaviour includes attempting many connection attempts to often random IP addresses that will not quickly complete. So the SP2 approach is actually a bit more conservative than the HP approach to throttling new connections, only doing so when an indication appears that something more than just a large increase in the number of connections has occurred. The buildup of incomplete connections is a reliable indicator of the type of scanning used by viruses, worms, as well as network scanning tools.
Note that if you were to run a network scanning tool, like nmap (www.insecure.org) from a SP2 patched system, you may very likely trigger the throttle, and can expect to see events with event ID of 4226 in the system event log:
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#EHAA
It is certainly encouraging to see that Microsoft has embraced a technology that shows promise in slowly the spread of viruses and worms that rely on other features of Windows systems to spread.
Magazine article about behaviour blocking products: http://www.nwfusion.com/news/2002/0128antivirus.html
Dan Geer's CyberInsecurity paper:
http://www.ccianet.org/papers/cyberinsecurity.pdf
USENIX paper that first dicussed using delays and anomaly detection: http://www.usenix.org/publications/library/proceedings/sec2000/somayaji.html
HP Lab's worm throttling technique:
http://www.hpl.hp.com/techreports/2002/HPL-2002-172.html
HP Lab's email virus throttling technique: http://www.hpl.hp.com/techreports/2003/HPL-2003-118.html