3. Slammer Worm Dissection
sponse is received. During this time, the thread is blocked 1,100
and cannot infect other hosts. In principle, worms can 1,000
Probes in a two-second sample
compensate for this latency by invoking a sufficiently large 900
number of threads. In practice, however, operating system 800
limitations, such as context-switch overhead and kernel 700
stack memory consumption, limit the number of active 600
threads a worm can use effectively. So, a worm like Code 500
Red quickly stalls and becomes latency limited, as every 400
thread spends most of its time waiting for responses. 300
In contrast, Slammer’s scanner is limited by each com- 200
promised machine’s Internet bandwidth. Because a single 100
packet to UDP port 1434 could exploit the SQL server’s 0
vulnerability, the worm was able to broadcast scans without 1,760 1,770 1,780 1,790 1,800 1,810 1,820
requiring responses from potential victims. Slammer’s Seconds after 5:00 a.m. UTC
inner loop is very small, and with modern servers’ I/O ca- DShield data K = 6.7m, T = 1808.7s, Peak = 2050, Const. 28
pacity to transmit network data at more than 100 Mbits per
second, Slammer frequently was limited by Internet access
bandwidth rather than its ability to replicate copies of itself. Figure 3. The early moments of the Distributed Intrusion Detection
In principle, an infected machine with a 100-Mbps System (Dshield) data set, matched against the behavior of a
Internet connection could produce more than 30,000 random-scanning worm.
scans per second. In practice, bandwidth limitations and
per-packet overhead limit the largest probe rate we di-
rectly observed to 26,000 scans per second, with an Inter- represents the range of the result, and a and b are carefully
net-wide average of approximately 4,000 scans per sec- chosen constants. Linear congruent generators are very
ond per worm during its early growth phase. efficient and, with appropriate values of a and b have rea-
Slammer’s scanning technique is so aggressive that it sonably good distributional properties (although they are
quickly interferes with its own growth. Subsequent in- not random from a sequential standpoint). Typically, you
fections’ contribution to its growth rate diminishes be- “seed” a generator’s initial value with a source of high-
cause those instances must compete with existing infec- quality random numbers to ensure that the precise se-
tions for scarce bandwidth. Thus, Slammer achieved its quence is not identical between runs.
maximum Internet-wide scanning rate in minutes. Slammer’s author intended to use a linear congruent
Any simple-loop approach creates a bandwidth- parameterization that Microsoft popularized, x' = (x ×
limited UDP scanner, so any future single-packet UDP 214013 + 2531011) mod 232. However, we found two
worm probably would have the same property unless its implementation mistakes. First, the author substituted a
author deliberately limited its spread. While a TCP-based different value for the 2531011 increment value: hex
worm, such as Code Red, also could use a bandwidth- 0xFFD9613C. This value is equivalent to –2531012
limited scanner by sending TCP SYNs at maximum rate when interpreted as a twos-complement decimal. So, it
and responding automatically to any replies in another seems likely that the conversion to a negative number was
thread, this would require more effort to implement cor- an error (the author seems to have forgotten that creating
rectly, as it requires crafting raw TCP packets instead of a negative number in twos complement requires invert-
simply using existing system calls. ing and adding 1, not simply inverting), and probably that
the author intended to use the SUB instruction to com-
What Slammer’s author did wrong pensate for the resulting negative number, but mistakenly
For a random-scanning worm to be effective, it needs a used ADD instead. The negative constant would be more
good source of random numbers to select new attack tar- desirable in the code, as this would eliminate any null (all-
gets. Slammer’s random-number generator has some in- zero) characters from the worm’s code. The result is that
teresting deficiencies that make our analysis difficult and, the increment is always even.
perhaps, have implications for future worms. Several dis- The author’s second mistake was to misuse the OR in-
assembled versions of the worm’s source code are avail- struction, instead of XOR, to clear an important register.
able at the URLs shown in the “Worm guts” sidebar. This error left the register’s previous contents intact. As a
Slammer uses a linear congruent, or power residue, result, the increment inadvertently XORs with the con-
pseudo random number generation (PRNG) algorithm. tents of a pointer contained in SqlSort’s import address
These algorithms take the form: x' = (x × a + b) mod m, table (IAT). This “salt” value differs, depending on the
where x' is the new pseudo random number to be gener- SqlSort DLL’s version, although two common values we
ated, x is the last pseudo random number generated, m observed are 0x77F8313C and 0x77E89B18. eEye Digi-
http://computer.org/security/ I IEEE SECURITY & PRIVACY 35
4. Slammer Worm Dissection
90 terpreted as a big-endian IP address (the most significant
80 value in the sequence is stored at the lowest storage ad-
dress), this ensures that the 25th and 26th bits in the scan ad-
70
Packets per second (millions)
dress (the upper octet) remain constant in any worm exe-
60 cution instance. Similar weaknesses extend to the 24th bit
of the address, depending on the uncleared register’s value.
50 Moreover, with the incorrectly chosen increment, any
40 particular worm instance cycles through a list of addresses
significantly smaller than the actual Internet address space.
30 Thus, many worm instances will never probe our moni-
20 tored addresses because none of them are contained in the
worm’s scan cycle. Combined with the size of our moni-
10 tored address space,3 these mistakes prevent us from accu-
0 rately measuring the number of infected hosts during the
0 1 2 3 4 5 first minutes of the worm’s spread.
Minutes after initial outbreak Slammer will or will not include entire /16 address
blocks (large contiguous address ranges) in a cycle, because
Figure 4. Slammer’s early progress as measured at the University of the last two bits of the first address byte never change. We
Wisconsin Advanced Internet Lab (WAIL) tarpit, an unused network were able to assemble lists of the address blocks in each cycle
that logs packet traffic. Scanning rate is scaled to estimate the for each value of the salt (cycle structure depends on salt
Internet-wide scanning rate. (A transient data-collection failure value). Fortunately, the probability of choosing a particular
temporarily interrupted this data set approximately two minutes cycle is directly proportional to the size of the cycle if the
and 40 seconds after Slammer began to spread.) initial seed is selected uniformly at random. If we looked at
many randomly seeded worms, it is likely that all Internet
addresses would be probed equally. Thus, we can accurately
70 estimate the worm’s scanning rate during the infection
process by monitoring relatively small address ranges. We
60 can estimate the percentage of the Internet that is infected
because the probing will cover all Internet addresses.
Packets per second (millions)
50 If not for the higher-quality numbers in the initial
seed, these flaws would prevent the worm from reach-
40 ing large portions of the Internet address space, no mat-
ter how many hosts were infected. For the same reason,
these flaws also could bias our measurements because
30
even though our data come from several different net-
works, there is a small chance that those particular net-
20
works were disproportionately more or less likely to be
scanned. However, the worm uses an operating system
10 service, GetTickCount, to seed each generator with
the number of milliseconds since a system booted,
0 which should provide sufficient randomization to en-
0 1 2 3 4 5 6 7 8 9 10 11 12
Hours after initial outbreak sure that across many instances of the worm, at least one
host will probe each address at some point in time. We
Figure 5. The response to Slammer during the 12 hours after its feel confident that the risk of bias in our measurements
release, measured in several locations. Scanning rate is scaled to is similarly minimized. Additionally, the “best” random
estimate the Internet-wide scanning rate. bits produced by GetTickCount are in the least-sig-
nificant bits, which determine which cycle is selected
for a given salt.
tal Security (www.eeye.com/html/Research/Flash/ An interesting feature of this PRNG is that it makes it
sapphire.txt) also reports seeing 0x77EA094C, which is difficult for the Internet community to assemble a list of
what the register value needs to be to get what eEye says is the compromised Internet addresses. With earlier worms,
their result. we could collect a list of all addresses that probed into a
These mistakes significantly reduce the generator’s dis- large network. With Slammer, we would need to monitor
tribution quality. Because b is even and the salt is always 32- networks in every cycle of the random-number generator
bit aligned, the least-significant two bits are always zero. In- for each salt value to have confidence of good coverage.
36 IEEE SECURITY & PRIVACY I JULY/AUGUST 2003
5. Slammer Worm Dissection
What did we learn about Slammer’s author? See the Table 1. Slammer’s geographical distribution.
“Who wrote Slammer?” sidebar.
COUNTRY PERCENT VICTIMS
How the Internet responded
By passively monitoring traffic (either by sniffing or United States 42.87
sampling packets or monitoring firewall logs) on a set South Korea 11.82
of links providing connectivity to multiple networks, Unknown 6.96
each responsible for about 65,000 IP addresses, we China 6.29
were able to infer the worm’s overall scanning behav- Taiwan 3.98
ior over time. Canada 2.88
We obtained the most-accurate Slammer early- Australia 2.38
progress data from the University of Wisconsin Advanced United Kingdom 2.02
Internet Lab (WAIL), which logs all packet traffic into an Japan 1.72
otherwise unused network, a “tarpit” (see Figure 4). Be- Netherlands 1.53
cause this data set represents a complete trace of all pack-
ets to an address space of known size, it lets us accurately Table 2. Slammer’s top-level domain distribution.
extrapolate the worm’s global spread. Unfortunately, a
transient failure in data collection temporarily inter- TOP-LEVEL DOMAIN PERCENT VICTIMS
rupted this data set approximately 2 minutes and 40 sec-
onds after Slammer began to spread. Our other sampled Unknown 59.49
data sets are not sufficiently precise for accurate evaluation .net 14.37
over short durations. .com 10.75
In general, people responded quickly to Slammer. .edu 2.79
Within an hour, many sites began filtering all UDP pack- .tw 1.29
ets with a destination port of 1434 via router or firewall .au 0.71
configuration changes. Slammer represents the idealized .ca 0.71
situation for network-based filtering: its signature easily .jp 0.65
distinguishes it, it is readily filterable on current hardware, .br 0.57
and it attacked a port that is not generally used for critical .uk 0.57
Internet communication. Thus, almost all traffic blocked
by these filters represents worm-scanning traffic. If the
worm had exploited a commonly used service vulnerabil- Why Slammer caused problems
ity (for example, DNS at UDP port 53 or HTTP at TCP Although Slammer did not contain an explicitly malicious
port 80), filtering could have caused significant disruption payload, there were widely reported incidences of disrup-
to legitimate traffic, with resulting denial of service (DoS) tion, including failures of Bellevue, Washington’s 911 emer-
more harmful than the worm itself. Figure 5 illustrates the gency’s data-entry terminals and portions of Bank of Amer-
results of filtering. ica’s ATM network. The 911 and ATM failures were widely
Regardless of the optimal filter efficacy conditions in reported: Aaron Davis, “Computer Worm Snarls Web”
this instance, we must recognize that while filtering con- (www.bayarea.com/mld/mercurynews/ 5034748.htm);
trolled the unnecessary bandwidth consumption of in- Robert Lemos, “Slammer Attacks May Become Way of Life
fected hosts, it did nothing to limit the worm’s spread. for the Net” (http://news. com.com/2009-1001-983540.
The earliest filtering began long after Slammer had in- html?tag=fd_lede2_hed); and Robert O’Harrow Jr., “In-
fected almost all susceptible hosts. ternet Worm Unearths New Holes” (www.securityfocus.
We recorded all distinct infected IP addresses seen by com/news/2186). Likewise, many routers and switches
our monitors in the first 30 minutes of worm spread. We crashed under the load, including several layer-2 and layer-3
noticed 74,856 distinct IP addresses, spread across a wide switches in the University of California, Berkeley’s Com-
range of domains and geographic locations. Slammer in- puter Science department.
fected most of these machines in the first few minutes, but Inadvertent internal DoS attacks caused the large major-
monitoring limitations prevent us from telling precisely ity of these disruptions: as one or more infected machines
when they were infected. We cannot observe all infected sent out packets at their maximum possible rates. This traf-
machines due to the flaws in Slammer’s PRNG, but we fic either saturated the first shared bottleneck or crashed
can document a lower bound on the number of compro- some network equipment. The bottleneck effects are obvi-
mised machines based on the IP addresses we have ous, as a site’s outgoing bandwidth is usually significantly less
recorded—the actual infection is undoubtedly larger. Ta- than a Slammer’s instance can consume. Thus, the worm’s
bles 1 and 2 summarize these distributions. packets saturated Internet links, effectively denying connec-
http://computer.org/security/ I IEEE SECURITY & PRIVACY 37
6. Slammer Worm Dissection
Network telescope operations
W e tracked Slammer’s spreading behavior via a network
telescope technique—a large address range, which is mon-
itored for unusual activity.1 Ideally, these address ranges are
size and distribution, we can estimate the amount of Internet scanning
occurring and the worm’s early growth rate. With this scanning-rate
information, we can estimate the fraction of the vulnerable machines
unused but routed, which eliminates all normal activity, but they that would be infected.
can contain actual machines if the normal traffic can be excluded This technique has some limitations. We cannot determine
from further analysis. Because Slammer’s behavior was highly when a particular machine became infected, because the tele-
anomalous, intrusion detection system logs and other sources scopes only detect an infected machine when it first probes a
provided excellent telescopes, even when gathered from active telescope. Furthermore, our telescopes were more limited than we
networks. desired because of relatively small monitored region plus some
David Moore, Geoffrey Volkier, and Stefan Savage developed data set subsampling. As a result, we effectively monitored 1/214
network telescope technology to understand distributed denial-of- of the complete Internet address space, enough to monitor the
service attacks, which generate a considerable amount of worm’s behavior and discover most infected machines but not
“backscatter,” or responses to packets with randomly forged source enough to reveal the initial point of infection.
addresses.2 By monitoring these responses, we can quantify the
scope of Internet denial of service activity, including targets and References
estimated traffic rates. This technique’s sensitivity depends on the 1. D. Moore, “Network Telescopes: Observing Small or Distant Security
size and distribution of the monitored address ranges; larger ranges Events,” Invited presentation at the 11th Security Symp. (SEC ‘02),
are significantly more precise while distributed ranges are more www.caida.org/outreach/presentations/2002/usenix_sec/.
likely to detect attacks that contain biases in address selection. 2. D. Moore, G. Voelker, and S. Savage, “Inferring Internet Denial-of-Service
We tracked Slammer by monitoring the worm’s probes to address Activity,” Proc. 10th Security Symp. (SEC ‘01), Usenix, Aug. 2001, pp. 9–22,
ranges scattered around the Internet. Combined with address range www.caida.org/outreach/papers/2001/BackScatter.
Who wrote Slammer? havior. Because these are “normal” UDP packets, special
privileges (such as root or system administrator abilities)
are not required. Instead, they need only the ability to ex-
A fter our study, we found very few clues about Slammer’s author’s
identity, location, or motive. No one has claimed authorship and the
code does not contain identifying signatures or comments. There also are
ecute the attacker’s program. Thus, critical networks
should employ traffic shaping, fair queuing, or similar
no variable names in the code, making it impossible to determine the techniques, to prevent a few machines from monopoliz-
author’s native tongue. ing network resources.
Similarly, the author has decent, but not remarkable, x86 coding skill;
much of the code was borrowed from a published exploit, the additional
code is not very complicated, and the author made three minor mistakes
in the random-number generator.
Finally, no one has discovered patient 0, the initial point of infection.
A lthough some had predicted the possibility of high-
speed worms,1 Slammer represents the first super-fast
worm released into the wild. Microsoft’s SQL Server vul-
Thus, it is impossible to determine where the worm was released, in hopes nerability was particularly well suited for constructing a fast
of tracing the release back to the author. worm (because the exploit could be contained in a single
UDP packet). However, techniques exist to craft any
worm with a reasonably small payload into a bandwidth-
tivity for all computers at many infected sites. limited worm similar to Slammer. Thus, we must not view
Equipment failures tended to be a consequence of Slammer’s extreme speed as an aberration of the exploit’s
Slammer’s traffic patterns generated by infected machines, nature or the particular protocol used (UDP versus TCP).
although any given equipment’s failure details varied. One implication of this worm’s emergence is that
Slammer’s scanner produced a heavy load in three ways: a smaller susceptible populations are now more attractive to
large traffic volume, lots of packets, and a large number of attacks. Formerly, attackers did not view small popula-
new destinations (including multicast addresses). We feel tions (20,000 machines or less on the Internet) as particu-
this combination probably caused most network-equip- larly vulnerable to scanning worms because the probabil-
ment failures by exhausting CPU or memory resources. ity of finding a susceptible machine in any given scan is
If attackers can control a few machines on a target net- quite low. However, a worm that can infect 75,000 hosts
work, they can perform a DoS attack on the entire local in 10 minutes could infect 20,000 hosts in under an hour.
network by using a program that mimics Slammer’s be- Thus, vulnerabilities of less popular software present a vi-
38 IEEE SECURITY & PRIVACY I JULY/AUGUST 2003
7. Slammer Worm Dissection
able breeding ground for new worms.
Because high-speed worms are no longer a theoretical Worm guts
threat, we need to automate worm defenses; there is no
conceivable way for system administrators to respond to
threats of this speed.1,4 Human-mediated filtering provides
no benefit for actually limiting the number of infected ma-
Y ou can inspect some disassembled versions of Slammer’s source code
at the following URLs:
chines. While the filtering could mitigate the overhead of • www.nextgenss.com/advisories/mssql-udp.txt
the worm’s continuing scan traffic, a more sophisticated • www.boredom.org/~cstone/worm-annotated.txt
worm might stop scanning once the entire susceptible pop- • www.eeye.com/html/Research/Flash/sapphire.txt
ulation was infected, leaving itself dormant on more than
75,000 machines to do harm at some future point. Had the is a computer science PhD candidate at the University of Califor-
worm’s propagation lasted only 10 minutes, it would likely nia, San Diego. His research interests are high-speed network mon-
have taken hours or days to identify the attack, and many itoring, denial-of-service attacks and infrastructure security, and
compromised machines might never have been identified. Internet traffic characterization. Contact him at dmoore@caida.org.
Thus, it is critical that we develop new techniques and tools
Vern Paxson is a senior scientist with the International Com-
that automatically detect and respond to worms. puter Science Institute (ICSI) Center for Internet Research (ICIR),
Though very simple, Slammer represents a significant a non-profit research institute in Berkeley, Calif. He is also a staff
milestone in the evolution of computer worms. It is computer scientist at the Lawrence Berkeley National Labora-
tory (LBNL). He received a PhD in computer science from the
sobering that worms such as Slammer preclude human- University of California, Berkeley. His research focuses on net-
time response and, to date, deter attribution and prosecu- work intrusion detection, Internet attacks, and Internet mea-
tion. It clearly demonstrates that fast worms are a reality surement. He serves on the editorial board of IEEE/ACM
and we should consider them as standard tools in an at- Transactions on Networking, and as chair of the Internet
Research Task Force, as well as program co chair of ACM SIG-
tacker’s arsenal. COMM 2002, program chair of Usenix Security 2003, and on
the steering committee of the Internet Measurement Workshop.
Acknowledgments Contact him at vern@icir.org.
We thank Dave Plonka (University of Wisconsin-Madison and the
Wisconsin Advanced Internet Lab), Pat Wilson and Brian Kantor Stefan Savage is an assistant professor of computer science and
engineering at the University of California, San Diego. He
(University of California, San Diego), and Johannes Ullrich and the received a PhD from the University of Washington. In addition
SANS Institute for contributing data sets for our analysis. Thanks also to network security, he is interested in the design, implementa-
to Lea Kissner (Carnegie-Mellon University) and David Wagner tion, and evaluation of networks and distributed systems. He is
program chair of the 2003 ACM Workshop on Rapid Malcode
(University of California, Berkeley) for help with the pseudo random
(WORM) and coprogram chair of the 2004 ACM Symposium
number generator. We are grateful to Ryan Koga (CAIDA) and Jeffrey on Networked Systems Design and Implementation (NSDI).
Brown (University of California, San Diego) for geographically map- Contact him at savage@cs.ucsd.edu.
ping the worm’s spread. The US National Science Foundation, Silicon
Defense, Cisco Systems, AT&T, US National Institute of Standards Colleen Shannon is a staff researcher at the Cooperative Asso-
ciation for Internet Data Analysis (CAIDA). Her research interests
and Technology, the Defense Advanced Research Projects Agency, and focus on network security, including traffic measurement, char-
CAIDA members provided support for this work. acterization, and network application identification. She recently
completed a study of the prevalence and characteristics of IP
References packet fragmentation, the results of which were published in
IEEE Transactions on Networking in December 2002. Contact
1. S. Staniford, V. Paxson, and N. Weaver, “How to Own the Inter-
her at cshannon@caida.org.
net in Your Spare Time,” Proc. 11th Security Symp. (SEC 02),
Usenix Assoc., 2002, pp. 149–167. Stuart Staniford is founder and president of Silicon Defense,
2. D. Moore, C. Shannon, and J. Brown, “Code-Red: A Case Study which focuses on Internet security research and commercial prod-
ucts. He received an MSc in Computer Science and a PhD in
on The Spread and Victims of an Internet Worm,” Proc. 2nd ACM
physics from the University of California, Davis. His research inter-
Internet Measurement Workshop, ACM Press, 2002, pp. 273–284. ests include worm containment, intrusion correlation, and intru-
3. D. Moore, “Network Telescopes: Observing Small or Distant sion detection. Contact him at stuart@silicondefense.com.
Security Events,” Invited presentation at the 11th Usenix Secu-
rity Symp. (SEC 02), Aug. 2002, www.caida.org/outreach/ Nicholas Weaver is currently completing his PhD at the Uni-
versity of California, Berkeley, having previously completed a BA
presentations/2002/usenix_sec.
in Computer Science and Astrophysics at Berkeley. His primary
4. David Moore et al., “Internet Quarantine: Requirements for Con- research areas are field-programmable gate array (FPGA) archi-
taining Self-Propagating Code,” to appear in Proc. 2003 IEEE Info- tectures, applications, and tools, as well as computer security.
com Conf., IEEE Press, Apr. 2003. His FPGA work, which forms the core of his dissertation, is a
novel FPGA architecture which supports fast routing, pipelined
interconnect, and fixed-frequency operation. His security work
David Moore is a principal investigator and assistant director of focuses on Internet scale attacks and potential automatic
the Cooperative Association for Internet Data Analysis (CAIDA). He defenses. Contact him at nweaver@cs.berkeley.edu.
http://computer.org/security/ I IEEE SECURITY & PRIVACY 39
