In a recent very ingenious analysis, Nick Weaver at UC Berkeley proposed the possibility of a Warhol Worm that could spread across the Internet and infect all vulnerable servers in less than 15 minutes (much faster than the hours or days seen in Worm infections to date, such as Code Red).

In this note, we observe that there is a variant of the Warhol strategy that could plausibly be used and that could result in all vulnerable servers on the Internet being infected in less than thirty seconds (possibly significantly less). We refer to this as a Flash Worm, or flash infection.

We have run out of hyberbolic adjectives to describe how seriously vulnerable the Internet is to security disruptions, so we won't comment further on the social implications of this.

The recent Code Red worm operated by probing random addresses on the Internet in the CRv2 version. The later Code Red II worm used a mixture of random probing of local subnets, and probing the entire Internet randomly.

The Warhol worm would first use a list of 50,000 or so sites to start the infection from (this list would be built by scanning in advance), and then use a clever co-ordinated scanning technique to scan and infect the rest of the Internet. In simulations, Weaver estimated such a worm could infect one million vulnerable servers in significantly less than 15 minutes, using plausible estimates of the scan rate a worm could achieve.

The nub of our observation is that it is reasonable to think that a determined attacker could have obtained a list of all or almost all servers with the relevant service open to the Internet in advance of the release of the worm. This could be done in a number of ways:

Straight scanning from a single site

For the well funded three-letter agency with an OC12 connection to the Internet, we believe a scan of the entire Internet address space can be conducted in a little less than two hours (we estimate about 750,000 syn packets per second can be fit down the 622Mbps of an OC12, allowing for ATM/AAL framing of the 40 byte TCP segments. The return traffic will be smaller in size than the outbound. Faster links could scan even faster.

Distributed scanning

For the hacker community, it will be more feasible to scan the Internet from a platform of a few thousand zombies similar to what they have assembled from time-to-time for DDOS attacks. Distributed scanning has been seen in the wild.

Stealthy scans

Portscans are so common and so widely ignored that even a fast scan of the entire Internet would be unlikely to attract law enforcement attention or more than mild comment in the incident response community. However, for attackers wishing to be especially careful, a randomized stealthy scan taking several months would be very unlikely to attract much attention as most intrusion detection systems are not currently capable of detecting such scans (but see Spade/Spice).

DNS searches

Using widely available spam mail lists, a list of domains can be assembled. The DNS can then be searched for the IP addresses of mail-servers (via MX records), or web servers (by looking for www.domain.com).

Spiders

For web server worms (like Code Red), it would be possible to use web-crawling techniques similar to search engines in order to produce a list of most Internet connected web sites (some sites with no links from other sites would be missed). This would be unlikely to attract serious attention.

Given that an attacker has the determination and foresight to assemble a list of all or most Internet connected addresses with the relevant service open, a worm can spread most efficiently by simply attacking addresses on that list. There are about 12 million web servers on the Internet (according to Netcraft), so the size of that particular address list would be 48MB, uncompressed. The initial copy of the worm can be programmed to divide the list into n blocks, and then to find and infect the first address in each block (or an especially chosen high-bandwidth address in that block), and then hand the child worm the list of addresses for that block. That copy of the worm can then re-iterate the process to infect everything in its block. A threaded worm could begin infecting hosts before it had received the full host list from its parent to work on, to maximize the parallelization process, and it could start work on looking for multiple children in parallel.

A related design would call for most of the address list to be located in pre-assigned chunks on one or a number of high-bandwidth servers that were well-known to the worm. Each copy of the worm would receive an assignment from its parent, and then fetch the address list from there.

This process will result in relatively little wasted effort. For example, if the worm had a list of web servers, and a zero-day IIS vulnerability, about 26% of the list would be vulnerable. No server would be probed twice. If n were 10, then the infection tree for the 3 million vulnerable servers would be just 7 layers deep.

The spread rate of such a worm would likely be constrained by one of two things. The worm itself is likely to be small (CRv2 was about 4k, and the hypothetical Warhol worm is 100K to allow for more malicious payload code). Thus the address list is much larger than the worm itself at the start of the list. Thus the propagation of the worm could literally be limited by the time required to transmit the host list out of the initial infection site or servers were it was stored. Since all the children of the infection will have much smaller lists to transmit, they are less likely to limit the worm spread (unless a first generation child has less than 1/n of the initial copy's bandwidth available to it). The exact time required to transmit the list will depend on the bandwidth of the storage sites, and the amount of traffic there. For some examples, however, we point out that the 48MB of address list could be pushed down an otherwise empty T1 line in just over 4 minutes. It could be pushed down an OC12 link in less than a second. Thus starting the worm on a high-bandwidth link is desirable for the attacker, and bandwidth is probably a concern at the next layer also. Compression of the list could make the list delivery much faster.

The other possible limitation is simply the latency required to infect each new layer in the tree. Given that probes can be issued in parallel, and substantially more threads can be spawned than n (the number of children), we do not have to add up the time required for a given copy to cycle through its list, but simply take the maximum infection latency. Weaver hypothesizes 1 second for this latency, but with an n=10, it perhaps might take a little longer to get 10 copies of the worm through a given sites link. However, not much longer - if a 5KB worm can get 50% utilization through a 256k DSL uplink, it can transmit ten copies of itself in three seconds. That leads to a sub thirty second limit on the total infection time (given an infection tree seven layers deep and a design were the new worm children go to a server for their addresses).