image Home       image Fowles,       image Fitzgerald,       image r04 06 (9)       image R 22MP (3)       image 45 (3)       

Linki

[ Pobierz całość w formacie PDF ]
Slammer Worm Dissection
Inside the Slammer Worm
The Slammer worm spread so quickly that human
response was ineffective. In January 2003, it packed
a benign payload, but its disruptive capacity was
surprising. Why was it so effective and what new
challenges do this new breed of worm pose?
D
AVID
M
OORE
Cooperative
Association for
Internet Data
Analysis and
University of
California, San
Diego
V
ERN
P
AXSON
International
Computer
Science
Institute and
Lawrence
Berkeley
National
Laboratory
S
lammer (sometimes called Sapphire) was the
first real-world
demonstration of a
high-speed worm’s capabilities. By comparison, Slam-
mer was two orders of magnitude faster than the Code
Red worm, which infected more than 359,000 hosts on
19 July 2001,
2
and had a leisurely 37 minutes of popula-
tion doubling time.
While Slammer had no malicious payload, it caused
considerable harm by overloading networks and disabling
database servers. Many sites lost connectivity as local
copies of the worm saturated their access bandwidths. Al-
though most backbone providers appeared to remain sta-
ble throughout the epidemic, there were several reports
of Internet backbone disruption. For a single snapshot of
the activity, see www.digitaloffense.net/worms/mssql
_udp_worm/internet_health.jpg. Additionally, Tim
Griffin of AT&T Research, has plotted Internet routing
data (an overall view of Internet routing behavior) that
shows a substantial perturbation in network connectivity
resulting from Slammer’s spread, (www.research.att.
com/~griffin/bgp_monitor/sql_worm.html).
If the worm had carried a malicious payload, attacked a
more widespread vulnerability, or targeted a more popular
service, its effects would likely have been far more severe.
For more on how we tracked Slammer, see the “Net-
work telescope operations” sidebar.
fastest computer worm in history. As it began
spreading throughout the Internet, the worm
infected more than 90 percent of vulnerable
hosts within 10 minutes, causing significant disruption to
financial, transportation, and government institutions
and precluding any human-based response. In this article,
we describe how it achieved its rapid growth, dissect por-
tions of the worm to study some of its flaws, and look at
our defensive effectiveness against it and its successors.
Slammer began to infect hosts slightly before 05:30
UTC on Saturday, 25 January 2003, by exploiting a
buffer-overflow vulnerability in computers on the Inter-
net running Microsoft’s SQL Server or Microsoft SQL
Server Desktop Engine (MSDE) 2000. David Litchfield
of Next Generation Security Software discovered this un-
derlying indexing service weakness in July 2002; Mi-
crosoft released a patch for the vulnerability before the
vulnerability was publicly disclosed (www.microsoft.
com/security/slammer.asp). Exploiting this vulnerability,
the worm infected at least 75,000 hosts, perhaps consider-
ably more, and caused network outages and unforeseen
consequences such as canceled airline flights, interference
with elections, and ATM failures (see Figure 1).
Slammer’s most novel feature is its propagation speed.
In approximately three minutes, the worm achieved its full
scanning rate (more than 55 million scans per second),
after which the growth rate slowed because significant
portions of the network had insufficient bandwidth to ac-
commodate more growth.
Although Stuart Staniford, Vern Paxson, and
Nicholas Weaver had predicted rapid-propagation
worms on theoretical grounds,
1
Slammer provided the
S
TEFAN
S
AVAGE
University of
California,
San Diego
C
OLLEEN
S
HANNON
Cooperative
Association
for Internet
Data Analysis
S
TUART
S
TANIFORD
Silicon
Defense
N
ICHOLAS
W
EAVER
Silicon
Defense and
University of
California,
Berkeley
How Slammer
chooses its victims
The worm’s spreading strategy uses random scanning—it
randomly selects IP addresses, eventually finding and in-
fecting all susceptible hosts. Random-scanning worms
initially spread exponentially, but their rapid new-host
33
PUBLISHED BY THE IEEE COMPUTER SOCIETY
1540-7993/03/$17.00 © 2003 IEEE
IEEE SECURITY & PRIVACY
  Slammer Worm Dissection
Sat Jan 25 06:00:00 2003 (UTC)
www.caida.org
Number of hosts infected with Slammer: 74, 855
Copyright © 2003 UC Regents
Figure 1. The geographical spread of Slammer in the 30 minutes after its release. The diameter of each circle is a function of
the logarithm of the number of infected machines, so large circles visually underrepresent the number of infected cases in
order to minimize overlap with adjacent locations. For some machines, we can determine only the country of origin rather
than a specific city.
with its scans, and bandwidth consumption and network
outages caused site-specific variations in its observed
spread. Figure 3 shows a data set from the Distributed In-
trusion Detection System project (Dshield; www.dshield.
org) compared to an RCS model. The model fits ex-
tremely well up to a point where the probe rate abruptly
levels out. Bandwidth saturation and network failure (some
networks shut down under the extreme load) produced
this change in the probe’s growth rate.
250,000
200,000
150,000
100,000
50,000
Why Slammer was so fast
While Slammer spread nearly two orders of magnitude
faster than Code Red, it probably infected fewer ma-
chines. Both worms use the same basic scanning strategy
to find vulnerable machines and transfer their exploitive
payloads; however, they differ in their scanning con-
straints. While Code Red is latency-limited, Slammer is
bandwidth-limited, enabling Slammer to scan as fast as a
compromised computer can transmit packets or a net-
work can deliver them. Slammer’s 376 bytes comprise a
simple, fast scanner. With its requisite headers, the pay-
load becomes a single 404-byte user diagram protocol
(UDP) packet. Contrast Slammer’s 404 bytes with Code
Red’s 4 Kbytes or Nimda’s 60 Kbytes.
Previous scanning worms, such as Code Red, spread
via many threads, each invoking
connect()
to open a
TCP session to random addresses. Consequently, each
thread’s scanning rate was limited by network latency.
After sending a
TCP SYN
packet to initiate the connection,
each thread must wait to receive a corresponding
SYN/ACK
packet from the target host or time-out if no re-
0
0
2
4
6
8
10
12
14
16
18
20
H
our
of the day
actual number of scans
predicted number of scans
Figure 2. The Code Red worm was a typical random-scanning worm.
This graph shows Code Red’s probe rate during its re-emergence on 1
August, 2001, as seen on one Internet subnetwork, matched against
the random constant spread worm behavior model.
infection slows as the worms continually retry infected or
immune addresses. Thus, as with the Code Red worm
shown in Figure 2, Slammer’s infected-host proportion
follows a classic logistic form of initial exponential
growth in a finite system.
1,2
We label this growth behav-
ior a
random constant spread
(RCS) model.
Slammer’s spread initially conformed to the RCS
model, but in the later stages it began to saturate networks
34
IEEE SECURITY & PRIVACY
JULY/AUGUST 2003
  Slammer Worm Dissection
sponse is received. During this time, the thread is blocked
and cannot infect other hosts. In principle, worms can
compensate for this latency by invoking a sufficiently large
number of threads. In practice, however, operating system
limitations, such as context-switch overhead and kernel
stack memory consumption, limit the number of active
threads a worm can use effectively. So, a worm like Code
Red quickly stalls and becomes latency limited, as every
thread spends most of its time waiting for responses.
In contrast, Slammer’s scanner is limited by each com-
promised machine’s Internet bandwidth. Because a single
packet to UDP port 1434 could exploit the SQL server’s
vulnerability, the worm was able to broadcast scans without
requiring responses from potential victims. Slammer’s
inner loop is very small, and with modern servers’ I/O ca-
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.
In principle, an infected machine with a 100-Mbps
Internet connection could produce more than 30,000
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-
net-wide average of approximately 4,000 scans per sec-
ond per worm during its early growth phase.
Slammer’s scanning technique is so aggressive that it
quickly interferes with its own growth. Subsequent in-
fections’ contribution to its growth rate diminishes be-
cause those instances must compete with existing infec-
tions for scarce bandwidth. Thus, Slammer achieved its
maximum Internet-wide scanning rate in minutes.
Any simple-loop approach creates a bandwidth-
limited UDP scanner, so any future single-packet UDP
worm probably would have the same property unless its
author deliberately limited its spread. While a TCP-based
worm, such as Code Red, also could use a bandwidth-
limited scanner by sending
TCP SYN
s at maximum rate
and responding automatically to any replies in another
thread, this would require more effort to implement cor-
rectly, as it requires crafting raw TCP packets instead of
simply using existing system calls.
1,100
1,000
900
800
700
600
500
400
300
200
100
0
1,760
1,770
1,780
1,790
1,800
1,810
1,820
Seconds after 5:00 a.m. UTC
DShield data
K = 6.7m, T = 1808.7s, Peak = 2050, Const. 28
Figure 3. The early moments of the Distributed Intrusion Detection
System (Dshield) data set, matched against the behavior of a
random-scanning worm.
represents the range of the result, and
a
and
b
are carefully
chosen constants. Linear congruent generators are very
efficient and, with appropriate values of
a
and
b
have rea-
sonably good distributional properties (although they are
not random from a sequential standpoint). Typically, you
“seed” a generator’s initial value with a source of high-
quality random numbers to ensure that the precise se-
quence is not identical between runs.
Slammer’s author intended to use a linear congruent
parameterization that Microsoft popularized,
x
' = (
x
×
214013 + 2531011) mod 2
32
. However, we found two
implementation mistakes. First, the author substituted a
different value for the 2531011 increment value: hex
0xFFD9613C. This value is equivalent to –2531012
when interpreted as a twos-complement decimal. So, it
seems likely that the conversion to a negative number was
an error (the author seems to have forgotten that creating
a negative number in twos complement requires invert-
ing and adding 1, not simply inverting), and probably that
the author intended to use the
SUB
instruction to com-
pensate for the resulting negative number, but mistakenly
used
ADD
instead. The negative constant would be more
desirable in the code, as this would eliminate any null (all-
zero) characters from the worm’s code. The result is that
the increment is always even.
The author’s second mistake was to misuse the
OR
in-
struction, instead of
XOR
, to clear an important register.
This error left the register’s previous contents intact. As a
result, the increment inadvertently
XOR
s with the con-
tents of a pointer contained in SqlSort’s import address
table (IAT). This “salt” value differs, depending on the
SqlSort DLL’s version, although two common values we
observed are 0x77F8313C and 0x77E89B18. eEye Digi-
What Slammer’s author did wrong
For a random-scanning worm to be effective, it needs a
good source of random numbers to select new attack tar-
gets. Slammer’s random-number generator has some in-
teresting deficiencies that make our analysis difficult and,
perhaps, have implications for future worms. Several dis-
assembled versions of the worm’s source code are avail-
able at the URLs shown in the “Worm guts” sidebar.
Slammer uses a linear congruent, or power residue,
pseudo random number generation (PRNG) algorithm.
These algorithms take the form:
x
' = (
x
a
+
b
) mod m,
where x' is the new pseudo random number to be gener-
ated,
x
is the last pseudo random number generated, m
×
35
http://computer.org/security/
IEEE SECURITY & PRIVACY
 Slammer Worm Dissection
terpreted as a big-endian IP address (the most significant
value in the sequence is stored at the lowest storage ad-
dress), this ensures that the 25th and 26th bits in the scan ad-
dress (the upper octet) remain constant in any worm exe-
cution instance. Similar weaknesses extend to the 24th bit
of the address, depending on the uncleared register’s value.
Moreover, with the incorrectly chosen increment, any
particular worm instance cycles through a list of addresses
significantly smaller than the actual Internet address space.
Thus, many worm instances will never probe our moni-
tored addresses because none of them are contained in the
worm’s scan cycle. Combined with the size of our moni-
tored address space,
3
these mistakes prevent us from accu-
rately measuring the number of infected hosts during the
first minutes of the worm’s spread.
Slammer will or will not include entire /16 address
blocks (large contiguous address ranges) in a cycle, because
the last two bits of the first address byte never change. We
were able to assemble lists of the address blocks in each cycle
for each value of the salt (cycle structure depends on salt
value). Fortunately, the probability of choosing a particular
cycle is directly proportional to the size of the cycle if the
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
estimate the worm’s scanning rate during the infection
process by monitoring relatively small address ranges. We
can estimate the percentage of the Internet that is infected
because the probing will cover all Internet addresses.
If not for the higher-quality numbers in the initial
seed, these flaws would prevent the worm from reach-
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
even though our data come from several different net-
works, there is a small chance that those particular net-
works were disproportionately more or less likely to be
scanned. However, the worm uses an operating system
service,
GetTickCount
, to seed each generator with
the number of milliseconds since a system booted,
which should provide sufficient randomization to en-
sure that across many instances of the worm, at least one
host will probe each address at some point in time. We
feel confident that the risk of bias in our measurements
is similarly minimized. Additionally, the “best” random
bits produced by
GetTickCount
are in the least-sig-
nificant bits, which determine which cycle is selected
for a given salt.
An interesting feature of this PRNG is that it makes it
difficult for the Internet community to assemble a list of
the compromised Internet addresses. With earlier worms,
we could collect a list of all addresses that probed into a
large network. With Slammer, we would need to monitor
networks in every cycle of the random-number generator
for each salt value to have confidence of good coverage.
90
80
70
60
50
40
30
20
10
0
0
1
2
3
4
5
Minutes after initial outbreak
Figure 4. Slammer’s early progress as measured at the University of
Wisconsin Advanced Internet Lab (WAIL) tarpit, an unused network
that logs packet traffic. Scanning rate is scaled to estimate the
Internet-wide scanning rate. (A transient data-collection failure
temporarily interrupted this data set approximately two minutes
and 40 seconds after Slammer began to spread.)
70
60
50
40
30
20
10
0
0
1
2
3
4
5
6
7
8
9
10
11
12
Hours after initial outbreak
Figure 5. The response to Slammer during the 12 hours after its
release, measured in several locations. Scanning rate is scaled to
estimate the Internet-wide scanning rate.
tal Security (www.eeye.com/html/Research/Flash/
sapphire.txt) also reports seeing 0x77EA094C, which is
what the register value needs to be to get what eEye says is
their result.
These mistakes significantly reduce the generator’s dis-
tribution quality. Because
b
is even and the salt is always 32-
bit aligned, the least-significant two bits are always zero. In-
36
IEEE SECURITY & PRIVACY
JULY/AUGUST 2003
  Slammer Worm Dissection
What did we learn about Slammer’s author? See the
“Who wrote Slammer?” sidebar.
Table 1. Slammer’s geographical distribution.
COUNTRY
PERCENT VICTIMS
How the Internet responded
By passively monitoring traffic (either by sniffing or
sampling packets or monitoring firewall logs) on a set
of links providing connectivity to multiple networks,
each responsible for about 65,000 IP addresses, we
were able to infer the worm’s overall scanning behav-
ior over time.
We obtained the most-accurate Slammer early-
progress data from the University of Wisconsin Advanced
Internet Lab (WAIL), which logs all packet traffic into an
otherwise unused network, a “tarpit” (see Figure 4). Be-
cause this data set represents a complete trace of all pack-
ets to an address space of known size, it lets us accurately
extrapolate the worm’s global spread. Unfortunately, a
transient failure in data collection temporarily inter-
rupted this data set approximately 2 minutes and 40 sec-
onds after Slammer began to spread. Our other sampled
data sets are not sufficiently precise for accurate evaluation
over short durations.
In general, people responded quickly to Slammer.
Within an hour, many sites began filtering all UDP pack-
ets with a destination port of 1434 via router or firewall
configuration changes. Slammer represents the idealized
situation for network-based filtering: its signature easily
distinguishes it, it is readily filterable on current hardware,
and it attacked a port that is not generally used for critical
Internet communication. Thus, almost all traffic blocked
by these filters represents worm-scanning traffic. If the
worm had exploited a commonly used service vulnerabil-
ity (for example, DNS at UDP port 53 or HTTP at TCP
port 80), filtering could have caused significant disruption
to legitimate traffic, with resulting denial of service (DoS)
more harmful than the worm itself. Figure 5 illustrates the
results of filtering.
Regardless of the optimal filter efficacy conditions in
this instance, we must recognize that while filtering con-
trolled the unnecessary bandwidth consumption of in-
fected hosts, it did nothing to limit the worm’s spread.
The earliest filtering began long after Slammer had in-
fected almost all susceptible hosts.
We recorded all distinct infected IP addresses seen by
our monitors in the first 30 minutes of worm spread. We
noticed 74,856 distinct IP addresses, spread across a wide
range of domains and geographic locations. Slammer in-
fected most of these machines in the first few minutes, but
monitoring limitations prevent us from telling precisely
when they were infected. We cannot observe all infected
machines due to the flaws in Slammer’s PRNG, but we
can document a lower bound on the number of compro-
mised machines based on the IP addresses we have
recorded—the actual infection is undoubtedly larger. Ta-
bles 1 and 2 summarize these distributions.
United States
42.87
South Korea
11.82
Unknown
6.96
China
6.29
Taiwan
3.98
Canada
2.88
Australia
2.38
United Kingdom
2.02
Japan
1.72
Netherlands
1.53
Table 2. Slammer’s top-level domain distribution.
TOP-LEVEL DOMAIN
PERCENT VICTIMS
Unknown
59.49
.net
14.37
.com
10.75
.edu
2.79
.tw
1.29
.au
0.71
.ca
0.71
.jp
0.65
.br
0.57
.uk
0.57
Why Slammer caused problems
Although Slammer did not contain an explicitly malicious
payload, there were widely reported incidences of disrup-
tion, including failures of Bellevue, Washington’s 911 emer-
gency’s data-entry terminals and portions of Bank of Amer-
ica’s ATM network. The 911 and ATM failures were widely
reported: Aaron Davis, “Computer Worm Snarls Web”
(www.bayarea.com/mld/mercurynews/ 5034748.htm);
Robert Lemos, “Slammer Attacks May Become Way of Life
for the Net” (http://news. com.com/2009-1001-983540.
html?tag=fd_lede2_hed); and Robert O’Harrow Jr., “In-
ternet Worm Unearths New Holes” (www.securityfocus.
com/news/2186). Likewise, many routers and switches
crashed under the load, including several layer-2 and layer-3
switches in the University of California, Berkeley’s Com-
puter Science department.
Inadvertent internal DoS attacks caused the large major-
ity of these disruptions: as one or more infected machines
sent out packets at their maximum possible rates. This traf-
fic either saturated the first shared bottleneck or crashed
some network equipment. The bottleneck effects are obvi-
ous, as a site’s outgoing bandwidth is usually significantly less
than a Slammer’s instance can consume. Thus, the worm’s
packets saturated Internet links, effectively denying connec-
37
http://computer.org/security/
IEEE SECURITY & PRIVACY
  [ Pobierz całość w formacie PDF ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • zolka.keep.pl

    		•