Example: The Internet Worm
On the evening of 2 November
1988, a worm was released to the Internet, causing serious damage to the
network. Not only were many systems infected, but also when word of the problem
spread, many more uninfected systems severed their network connections to
prevent themselves from getting infected. Spafford and his team at Purdue
University [SPA89] and Eichen and
Rochlis at M.I.T. [EIC89] studied the
worm extensively, and Orman [ORM03] did
an interesting retrospective analysis 15 years after the incident.
The perpetrator was Robert T.
Morris, Jr., a graduate student at Cornell University who created and released
the worm. He was convicted in 1990 of violating the 1986 Computer Fraud and
Abuse Act, section 1030 of U.S. Code Title 18. He received a fine of $10,000, a
three-year suspended jail sentence, and was required to perform 400 hours of
community service. (See Denning [DEN90b]
for a discussion of this punishment.)
What It Did
Judging from its code, Morris
programmed the Internet worm to accomplish three main objectives:
Determine where it could spread to.
Spread its infection.
Remain undiscovered and undiscoverable.
What Effect It Had
The worm's primary effect was
resource exhaustion. Its source code indicated that the worm was supposed to
check whether a target host was already infected; if so, the worm would
negotiate so that either the existing infection or the new infector would
terminate. However, because of a supposed flaw in the code, many new copies did
not terminate. As a result, an infected machine soon became burdened with many
copies of the worm, all busily attempting to spread the infection. Thus, the
primary observable effect was serious degradation in performance of affected
machines.
A second-order effect was the
disconnection of many systems from the Internet. System administrators tried to
sever their connection with the Internet, either because their machines were
already infected and the system administrators wanted to keep the worm's
processes from looking for sites to which to spread or because their machines
were not yet infected and the staff wanted to avoid having them become so.
The disconnection led to a
third-order effect: isolation and inability to perform necessary work.
Disconnected systems could not communicate with other systems to carry on the
normal research, collaboration, business, or information exchange users
expected. System administrators on disconnected systems could not use the
network to exchange information with their counterparts at other installations,
so status and containment or recovery information was unavailable.
The worm caused an estimated
6,000 installations to shut down or disconnect from the Internet. In total,
several thousand systems were disconnected for several days, and several
hundred of these systems were closed to users for a day or more while they were
disconnected. Estimates of the cost of the damage range from $100,000 to $97
million.
How It Worked
The worm exploited several
known flaws and configuration failures of Berkeley version 4 of the Unix
operating system. It accomplishedor had code that appeared to try to
accomplishits three objectives.
Determine where to spread.
The worm had three techniques for locating potential machines to victimize. It
first tried to find user accounts to invade on the target machine. In parallel,
the worm tried to exploit a bug in the finger program and then to use a trapdoor
in the sendmail mail handler. All three of these security flaws were well known
in the general Unix community.
The first security flaw was a
joint user and system error, in which the worm tried guessing passwords and
succeeded when it found one. The Unix password file is stored in encrypted
form, but the ciphertext in the file is readable by anyone. (This visibility is
the system error.) The worm encrypted various popular passwords and compared
their ciphertext to the ciphertext of the stored password file. The worm tried
the account name, the owner's name, and a short list of 432 common passwords
(such as "guest," "password," "help,"
"coffee," "coke," "aaa"). If none of these
succeeded, the worm used the dictionary file stored on the system for use by
application spelling checkers. (Choosing a recognizable password is the user
error.) When it got a match, the worm could log in to the corresponding account
by presenting the plaintext password. Then, as a user, the worm could look for
other machines to which the user could obtain access. (See the article by
Robert T. Morris, Sr. and Ken Thompson [MOR79]
on selection of good passwords, published a decade before the worm, and the
section in Chapter 4 on passwords people
choose.)
The second flaw concerned
fingerd, the program that runs continuously to respond to other computers'
requests for information about system users. The security flaw involved causing
the input buffer to overflow, spilling into the return address stack. Thus,
when the finger call terminated, fingerd executed instructions that had been
pushed there as another part of the buffer overflow, causing the worm to be
connected to a remote shell.
The third flaw involved a
trapdoor in the sendmail program. Ordinarily, this program runs in the background,
awaiting signals from others wanting to send mail to the system. When it
receives such a signal, sendmail gets a destination address, which it verifies,
and then begins a dialog to receive the message. However, when running in
debugging mode, the worm causes sendmail to receive and execute a command
string instead of the destination address.
Spread infection. Having
found a suitable target machine, the worm would use one of these three methods
to send a bootstrap loader to the target machine. This loader consisted of 99
lines of C code to be compiled and executed on the target machine. The
bootstrap loader would then fetch the rest of the worm from the sending host
machine. An element of good computer securityor stealthwas built into the
exchange between the host and the target. When the target's bootstrap requested
the rest of the worm, the worm supplied a one-time password back to the host.
Without this password, the host would immediately break the connection to the
target, presumably in an effort to ensure against "rogue" bootstraps
(ones that a real administrator might develop to try to obtain a copy of the
rest of the worm for subsequent analysis).
Remain undiscovered and
undiscoverable. The worm went to considerable lengths to prevent its discovery
once established on a host. For instance, if a transmission error occurred
while the rest of the worm was being fetched, the loader zeroed and then
deleted all code already transferred and then exited.
As soon as the worm received
its full code, it brought the code into memory, encrypted it, and deleted the
original copies from disk. Thus, no traces were left on disk, and even a memory
dump would not readily expose the worm's code. The worm periodically changed
its name and process identifier so that no single name would run up a large
amount of computing time.
What Was Learned
The Internet worm sent a shock wave through the
Internet community, which at that time was largely populated by academics and
researchers. The affected sites closed some of the loopholes exploited by the
worm and generally tightened security. Some users changed passwords. Two
researchers, Farmer and Spafford [FAR90],
developed a program for system administrators to check for some of the same
flaws the worm exploited. However, security analysts checking for site
vulnerabilities across the Internet find that many of the same security flaws
still exist today. A new attack on the Internet would not succeed on the same
scale as the Internet worm, but it could still cause significant inconvenience
to many.
The Internet worm was benign
in that it only spread to other systems but did not destroy any part of them.
It collected sensitive data, such as account passwords, but it did not retain
them. While acting as a user, the worm could have deleted or overwritten files,
distributed them elsewhere, or encrypted them and held them for ransom. The
next worm may not be so benign.
The worm's effects stirred
several people to action. One positive outcome from this experience was
development of an infrastructure for reporting and correcting malicious and
nonmalicious code flaws. The Internet worm occurred at about the same time that
Cliff Stoll [STO89] reported his problems in
tracking an electronic intruder (and his subsequent difficulty in finding
anyone to deal with the case). The computer community realized it needed to organize. The
resulting Computer Emergency Response Team (CERT) at Carnegie Mellon University
was formed; it and similar response centers around the world have done an
excellent job of collecting and disseminating information on malicious code
attacks and their countermeasures. System administrators now exchange
information on problems and solutions. Security comes from informed protection
and action, not from ignorance and inaction.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.