A week into Code Red. The worm has reached saturation of its vulnerable population — about 359,000 distinct compromised hosts at peak, by the eEye Digital Security analysis and other public assessments. The DDoS phase against Whitehouse.gov is scheduled for tomorrow.
Time for a more careful analytical post.
The technical analysis
The worm's actual code is short. About 4 kilobytes of x86 shellcode, embedded directly in the HTTP request. The structure:
Initial code stub. Sets up the working environment within the compromised IIS process. Patches itself into specific memory locations to ensure persistence within the running process.
Worker thread spawn. Spawns 100 threads that each scan random IP addresses for vulnerable IIS servers. Each scanning thread sends the full exploit-and-payload to the next target.
Defacement logic. On English-language hosts, modifies the in-memory representation of the default web page.
DDoS scheduler. Watches the system date; switches between scanning, defacement, and DDoS phases based on day-of-month.
State machine. Coordinates the threads, handles errors, manages the scanning IP-generation algorithm.
The IP-generation algorithm is interesting. Code Red uses a linear congruential generator with a fixed seed. The same seed across all instances means every infected host scans the same IP space in the same order. This is structurally inefficient — many addresses are scanned by hundreds of different hosts simultaneously — but it produces aggressive coverage of the address space.
The propagation arithmetic
From my model:
- Vulnerable population: approximately 360,000 IIS servers (this is the eventual saturation number).
- Per-host scan rate: 100 IPs per second.
- Scan-to-compromise hit rate: roughly 1 in 30,000 (the fraction of scanned IPs that are vulnerable IIS servers).
- Effective propagation rate β: 100 / 30,000 = ~0.003 successful infections per host per second = ~10 per hour.
With β = 10/hour and N = 360,000, the saturation time is roughly 4-5 hours from initial seeding. The actual saturation took longer because the worm had visible periods of low activity due to IP-generator collisions.
The model is approximately right. The actual data fits the logistic curve I sketched in May 2000.
What this confirms
Three things that I had been hypothesising rather than knowing.
Sub-hour saturation is real. The math suggested it; the data confirms it. A worm targeting a large vulnerable population with appropriate β can saturate in hours, not days.
Reactive defence is too slow. Code Red was patched in mid-June; the worm appeared on 13 July; saturation by 19 July. Operators who patched in early June were safe; operators who patched after 13 July were too late.
Memory-resident worms are a category. Code Red writes nothing to disk; it lives only in the running IIS process. Reboot removes it; reinstall is unnecessary. This is operationally simpler for the attacker (no persistence engineering) and harder for the defender (the defender's natural response — reboot — produces a clean host that is then immediately re-infected).
What is happening with the DDoS phase
The scheduled DDoS against www.whitehouse.gov starts tomorrow (the 20th, by the worm's date logic). The site has reportedly already changed its IP address to mitigate; the DNS will be redirected to a new address before the worm's hardcoded IP becomes the target.
This is a competent operational response and is, on the available evidence, going to defeat the worm's DDoS phase entirely. The worm cannot adapt — its hardcoded IP is in the binary; the new whitehouse.gov IP is not the target.
This is a small win. The worm's authors clearly did not anticipate this kind of countermeasure.
What I expect next
Three predictions.
A Code Red variant within days. The current worm has structural weaknesses (memory-resident, hardcoded DDoS target, single seed). Variants that fix these are straightforward to write. Probability: 90%. Deadline: 31 August 2001.
The total Code Red population continues to refresh. Operators reboot; re-infection happens; the cycle continues until the patch is universally applied. Months of cleanup ahead. Probability: 95%. Deadline: end of year.
A more sophisticated IIS worm before year-end. The Code Red technique is now public; better implementations will follow. Probability: 80%. Deadline: 31 December 2001.
What I am doing
For my own infrastructure: nothing direct (I do not run IIS). The collateral scan traffic is real but bounded by my upstream rate-limit.
For friends running IIS: confirming patch status. Most are patched; one is not and is being chased.
For my Snort sensor: the .ida exploit signatures are firing thousands of times per day. I have aggregated the alerts into hourly counters; the actual data point is more useful as a time-series than as individual alerts.
For my structured logs: the Code Red traffic is large enough that it has been my first real test of the new database backend. The database is handling the volume well; the analysis queries are tractable.
More as the worm continues.