How Can You Defend Against a Superworm?

Give an exploit to script kiddies, and they'll hit every vulnerable host in weeks. Build a worm with it, and it could take days. How long would a superworm take? Try 30 seconds. Brandon Wiley explains superworms and some possible self-defense tools.

Linux administrators see log files full of failed attack attempts when some other platform is subject to a worm attack. Dumb worms might be a nuisance and a waste of bandwidth. But what if worms were a little smarter about which hosts to attack, when to attack and with what exploit? What if a worm developer could update all the running worms, on the fly, with a new exploit?

At South By Southwest, we talked with Brandon Wiley, coordinator of the Tristero project, about the threat of such a "superworm" and what might be done to defend against it. For those of you who didn't make it to South By Southwest, we asked him again.

Would a superworm be significantly harder to build than today's dumb worms, or is a superworm just a regular worm plus a pseudo-random number generator?

Building a superworm would not take much more craft than building a normal worm. The difference is in the cleverness of the design. Normal worms are designed without strategy in mind. Each worm pursues the limited strategy of attempting to reproduce itself immediately as much as possible, with no other considerations. The superworm, on the other hand, is designed to take strategies into account that will allow for the maximum propagation globally even if it means limiting propagation locally. This is similar to the different economic models promoted by Adam Smith vs. John Nash. Coding a worm with intelligence about game theory and a global perspective on achieving an optimal outcome is not much harder in terms of the code, but requires a more carefully thought-out design.

Randomization is one way to handle the division of labor among many worm instances. If you flip a coin to determine whether to propagate or sleep for a turn then worms will at least not be propagating at full throttle. However, randomization does not scale well. Ideally you want to have the probability of propagation for each worm be inversely proportional to the number of worms considering the attack of a particular machine. As the network becomes saturated with worms, the number of contending worms increases. So, ideally, you want to decrease the probability of attack. Unfortunately, this requires that you know the number of contending worms, which means that the worms need to coordinate with each other.

An alternative method to randomization is to divide and conquer the network according to principles similar to distributed hash table (DHT) systems. For instance, if the worms form an Achord network, each worm only has to know about approximately log2 (253^4) other worms and each worm has a portion of the network that it is dedicated to compromising. As new worms join the network, the responsibility is redivided. This way only one worm is ever attacking a particular machine and yet there is a minimal amount of coordination between the worms.

Are propagation strategies that a superworm could use already in the open literature?

Techniques for maintaining DHTs are widely published. There proceedings from the 1st International Peer-to-Peer Symposium (IPTPS) at MIT are about to be published and contain a wealth of information about DHTs. I have a paper on a DHT-based superworm called Curious Yellow that will be available at http://blanu.net/curious_yellow.html within a couple of days. Some very good optimizations for superworms have also been published as thought experiments.

The Warhol worm design suggests pre-scanning the network for vulnerable hosts and compiling a large hitlist. The hitlist is the carried by the initial worm and partitioned as the worms divide and conquer the network. This precompiled hitlist allows for the worm to achieve an initial critical mass of propagation that can then be used as a platform from which to launch large-scale attacks.

The Flash worm design optimizes further on Warhol by compiling a nearly complete list of vulnerable servers rather than just a seed list and hosting the host list on a fast, well-connected server rather than transmitting it along with the worm.

What are the best predictions for how long a superworm would take to make the Internet unusable? Days? Hours?

The estimate mentioned in the Warhol paper was 15 minutes and the estimate in the Flash paper was approximately 30 seconds to infect all known vulnerable hosts. In my estimation, though, this is just for the initial seeding of the network. There are a plethora of hosts that might be unreachable during the initial infection either because they are disconnected, they are behind firewalls, or they are not vulnerable to the attacks that the worm has at its disposal during the initial infection period. A truly advanced worm would use this initial infection as a springboard to reach previously unreachable hosts and wait for code updates that would allow infection of previously invulnerable systems. This second stage of infection could go on indefinitely until all hosts in the world are infected. How long this would take depends on how frequently usable exploits are found for various platforms.

Many Linux users say that the diversity of software and configuration on Linux systems makes them relatively safe from worm attacks even when exploits are discovered. Can a superworm's propagation be smart enough to find rare vulnerable configurations or daemons?

While the overall diversity of hosts helps protect against worms, the diversity found in individual Linux systems will not generally be helpful in protecting against worms. While Linux systems are highly customized, exploits used by worms are generally in a widely used package with a homogeneous codebase, such as sshd, fingerd, or ftpd. While there are a few versions of finger and ftp daemons available now, one daemon implementation generally has the largest market share and thus acts as a propagation vector for the majority of Linux systems. For instance, few people are running customized implementations of the GNOME or KDE daemons. All that is required for a system to be vulnerable is for it to be running a single service which has a published exploit.

Are superworms a threat to well-administered Linux systems? Can a superworm outrace news of the exploit it uses?

The most effective superworm would use drop-in 0 day exploits for propagation. A network could already be in place using a Warhol/Flash-style prescanned hitlist for seeding. When a new exploit is found it could then be sent to the worms already in place. This means that the window in which the administrator can harden his system from the worm is between when the vulnerability is discovered and when the worm author writes the code to exploit it. The distribution network for patches to fix the vulnerability will generally be slower than the worm exploit distribution network, which can propagate patches to all worms in 30 seconds. Hence the only way to be fully protected against the worm is to install software very similar to the worm itself that does quick distribution of security patches. At that point it becomes a race between the authors or exploit code and the authors of security patches.

Since a superworm could help perpetuate itself by DoSing sites that provide worm-fighting software and patches, what can sites that want to help people fight worms, but might be silenced by a worm, do to help their users when the attack comes? Should we be applying superworm math to an emergency superworm warning system?

Since the worm network already moves faster than the patch distribution and warning system, there it would not be worth it to DoS patch sites. It would in fact be a liability as the security site would be able to record the IPs of infected nodes. However, if a threat was ever posed to the worm network, the author would be able to coordinate all of the worms within 30 seconds to take arbitrary action as encoded in patches sent to the entire network. While this could be used to DoS the Pentagon or CNN.com, it would most likely be used primarily for shutting down Slashdot and EFnet.

The only effective attack against a well-designed superworm is to have a decentralized network for security patch propagation that can distribute patches before exploits can be distributed. This would be a useful service in general as it would keep all participating systems patched up to the minute with the latest security fixes, thus making them invulnerable not only to superworms, but also to lesser worms and to hacking attempts based on published exploits. The network of nodes could also act as a distributed intrusion detection system, monitoring the progress and acting as an early warning system against hacking attempts, worm infections, and denial of service attacks. This project would be an excellent public service endeavor if funding could be found for its development and deployment. The only project I know of in this area is Austin-based company Invisisoft, whom I spoke to after my superworms panel at SXSW. I don't know what the status of that project is, however.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: How Can You Defend Against a Superworm?

Anonymous's picture

There are many insightful comments to me article. The points presented here are mostly dealt with in my longer paper on superworms.

The main comment that people seem to have is that my solution, the rapid patch distribution network, is a terrible idea which can be subverted as a tool for infection. This is quite true. Unfortunately, it is also true that the normal way that patch distribution takes place cannot keep up with a superworm like Flash that takes 30 seconds to propagate once an exploit is written. Since security updates take longer than a worm infection, the worm infection wins. Without a rapid patch distribution network faster than the worm, the worm will always win. My solution comes with its own problems, which are covered in my paper.

Another common misintepretation seems to be that secure computing practices can stop superworms. Secure computing practices do not in fact help at all. Superworms rely on exploitable vulnerabilities in software packages, not badly deployed security. The defense against them is to have software without vulnerabilities. Protecting the system files is irrelevant as superworms do not need superuser access or to modify system files

It was an honor to be dissed by the infamous Rick Moen, who suggests that the superworm is at most a one day annoyance for system administrators. This is also true. The annoying part is most of the Internet going down for a day every time an exploit is discovered. As far my comments about Gnome/KDE, I didn't not mean to imply that there are remote exploits waiting to be used in Gnome/KDE services. I was just trying to convey that if there were, all of the various Linux distributions running Gnome/KDE would be equally vulnerable and so the diversity of Linux systems is a red herring. A much better example would have been sshd, which has had published exploits in the past. I was unsuccessfully attempting to be accessible.

Brandon Wiley, Superworm Pundit

Re: How Can You Defend Against a Superworm?

Anonymous's picture

The best first step towards defending against such
attacks is implementing a Mandatory Access Control
security system similar to NSA Security Enhanced
Linux.

A system protected by a properly configured MAC
system will not allow most daemons to do anything
destructive if they are attacked. The only problematic
daemon is sshd which (by it's nature) needs to allow
changing to any security context (including the
system administrator). But for really secure systems
you would block port 22 at the router anyway...

Russell Coker
russell@coker.com.au

Re: How Can You Defend Against a Superworm?

Anonymous's picture

Of course, there is a more effective defense against a running

superworm network. It's called 'offense'.

How? Simple. Subvert the patch distribution system. As this is a 'live' worm network there will be uncompromised hosts able to observe traffic from and to the worms. The method to distribute patches will most likely be vulnerable to some type of attack, be it directly hacking into the central node, spoofing or rewriting the raw tcp stream. Insert a malware exploit that instead will disable any worm that recieves it. Done. Bye worm net.

Of course the worm author can build a few defenses to protect his worms but any such effort will cause his trojan binary to gain weight fast and therefore slow down his distribution curve.

Don't forget, once such a worm is 'in the wild' it will be the single attacker against the security community. Guess who has more eyeballs? Not the attacker ..

Floris

Re: How Can You Defend Against a Superworm?

scottwimer's picture

The proposed defense against the superworm is inane. As several other posters have pointed out, having "patching worms" is an impractical and bad idea at best. At worst, they form a trusted trojan deployment network.

The intelligent defence against worms (not just the mythical superworm) is not to see just how fast we can chase vulnerabilities and exploits. Software will always contain vulnerabilities -- it's written and designed by humans after all. Truly preventative techniques must accept the fact that software is vulnerable and establish mechanisms for mitigating the impact of any arbitrary vulnerability.

Host based behavioral and access control can prevent a worm from infecting a host. Use behavioral control to identify when a running process is exploited, and then kill or suspend (SysAds choice) the exploited process. Use access control on the system to prevent the exploited process from being able to touch system files before the behavioral control system shuts it down. In multiprocessing environments, you have to have overlapping protection to help keep subtle and customized attacks from slipping through.

For more on preventative security go to:

Freshmeat Article

Regards,

scottwimer

Re: How Can You Defend Against a Superworm?

Anonymous's picture

That would make it very easy to DoS your site. Just tickle it in the most obnoxious way you can think of.

Re: How Can You Defend Against a Superworm?

Anonymous's picture

other then the noted issues stated above consider a more important set of issues on the production side: as the programmer of this worm. they state that I would have to be able to do the following:

1: get access to 0 - day vulns.

2: get a large list of 'puters with those vulns.

3: use some of the public code base to create my worm engine.

4: give the worms a server that they can get their patches/updates from.

5: give the worm advanced platform guessing/detection routines.

6: give the worm a semi intelligent stragegy engine that helps this thing evade detection while propegating.

7: have this same engine help divide the labor so that they don't mass attack only one machine.

8: encrypt this worm so as to foil easy fixes when spotted.

9: devlop a massive data base on the server and supply multiple attacks for the various vulns, so as to disguise the attack/target profile.

10: hone the code so as not to trip the heuristic scans on most AV software.

11: release it and maintain it in a very hidden way.

12: maintain it as above.

13 some how manage to code it in such a way that the file size is not important. Or in such a way that the file is small and easily distributed.

along with the apocalyptic future warnings, this article is a bit misleading on just how easy it can be done.

I think that it will be done however...

Re: How Can You Defend Against a Superworm?

Anonymous's picture

"Software will always contain vulnerabilities -- it's written and designed by humans after all."

True. So what we need is some software that can write better software than humans... This will be, naturally, be written by... oh, yeah. A human. ;-)

-ksc

Re: How Can You Defend Against a Superworm?

scottwimer's picture

No, we don't need vulnerability free software. We need to stop thinking like computer scientists and start thinking more like engineers. Every bridge ever built was made from materials that contain defects and vulnerabilities. Through overengineering and design, we keep those defects from causing bridge failure. When we don't do this, the bridges colapse -- see all the really cool footage of the Tacoma Narrows bridge dancing itself into a heart attack.

Trying to write defect free software is a noble goal; it also happens to be unreachable for any software complex enough to have much utility. When designing an airplane, the design engineers don't go... "Well, let us assume that every nut will be perfectly torqued, each weld will be absolutely perfect, all couplings will be exactly mated, the hydraulic system will never leak..." Wrong. Why, because they KNOW that people will make mistakes, they know that the materials will become fatiqued, they know that someday the plane is going to hit a Canadian Goose at 200 MPH and it still had better land safely. They design the system to take human construction errors into account.

If we're going to be successful in the pursuit of systems that get progressively harder to compormise or break, we're going to need to get better at applying engineering principles to the construction of software.

Anybody who tells you otherwise is either lying or misguided.

scottwimer

Re: How Can You Defend Against a Superworm?

Anonymous's picture

Hmmm some of the text of this article reminds me of the 'China Syndrome' movie. A melt-down of the Imternet instead of a reactor.

Re: How Can You Defend Against a Superworm?

rickmoen's picture

While Linux systems are highly customized, exploits used by worms are generally in a widely used package with a homogeneous codebase, such as sshd, fingerd, or ftpd. While there are a few versions of finger and ftp daemons available now, one daemon implementation generally has the largest market share and thus acts as a propagation vector for the majority of Linux systems. For instance, few people are running customized implementations of the GNOME or KDE daemons.

What is this gentleman babbling about? Does his bit about "the GNOME or KDE daemons" refer to their respective CORBA brokers? If so, I'd be really surprised if there are any distributions whose ORBs that accept remote TCP connections. And when's the last time you saw finger daemons running routinely?

Of course, hypothesising that a would-be superworm author has come by the malware artist's holy grail of a zero-day, unpublicised remote exploit against a widespread network daemon (Apache, OpenSSHd), it would be at would be at worst a one-day annoyance to sysadmins who'd be obliged to take down their systems, rebuild, and bring them back up with the vulnerable software disabled until it's been patched or replaced.

And: Worms to distribute security patches? I really don't think so. The number of ways this can and would go wrong is positively staggering -- not to mention the blizzard of lawsuits that would follow.

I think perhaps Mr. Wiley has been reading too many cyberwarfare tracts from the Beltway.

Best Regards,
Rick Moen
rick@linuxmafia.com

Re: How Can You Defend Against a Superworm?

Anonymous's picture

Hmm, and what happens, if the security patch distributing network gets hacked, and start to distribute backdoors?

As you can't be sure, it is unsafe to join and trust in such networks.

Re: How Can You Defend Against a Superworm?

Anonymous's picture

This is why all patches should be signed and no patch accepted that is not signed.

Re: How Can You Defend Against a Superworm? - Debian

Anonymous's picture

Debian already does this. It has such an inferstructure in place. Though it is slower than the network described in the article, it is an inferstructure already in place for distrubution of software and security patches. They are also now comming up with a new security system which will, in theory, work better than the current one.

Re: How Can You Defend Against a Superworm?

dmarti's picture

I'd be more comfortable with the warning network would limit itself to this: when a certain number of trustworthy bug reports come in, page me and shut down.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState