Hackers Toolkit 2.0/Hackers_Toolkit_v2.0.iso/HTML/archive/Texts/hacking/wily_hacker.txt

Text File | 1999-11-04 | 45.4 KB | 706 lines

-----------------------------------------------------------------------------

Title:     Stalking the wily hacker. (includes related articles on the

           definition of hackers, Intruder versus Tracker, legal constraints

           and ethics, and computer security resources)

Journal:   Communications of the ACM  May 1988 v31 n5 p484(14)

           * Full Text COPYRIGHT Assn. for Computing Machinery, Inc. 1988.

Author:    Stoll, Clifford.

HTML:      Markus Hⁿbner

Summary:   The experience of the Lawrence Berkeley Laboratory in tracking an

           intruder suggests that any operating system is insecure when

           obvious security rules are ignored. How a site should respond to

           an intrusion, whether it is possible to trace an intruder trying

           to evade detection, what can be learned from tracking an intruder,

           what methods the intruder used, and the responsiveness of the

           law-enforcement community are also discussed.

-----------------------------------------------------------------------------

STALKING THE WILY HACKER

In August 1986 a persistent computer intruder attacked the Lawrence
Berkeley Laboratory (LBL). Instead of trying to keep the intruder out, we
took the novel approach of allowing him access while we printed out his
activites and traced him to his source. This trace back was harder than we
expected, requiring nearly a year of work and the cooperation of many
organizations. This article tells the story of the break-ins and the trace,
and sums up what we learned. We approached the problem as a short,
scientific exercise in discovery, intending to determine who was breaking
into our system and document the exploited weaknesses. It became apparent,
however, that rather than innocuously playing around, the intruder was
using our computer as a hub to reach many others. His main interest was in
computers operated by the military and by defense contractors. Targets and
keywords suggested that he was attempting espionage by remotely entering
sensitive computers and stealing data; at least he exhibited an unusual
interest in a few, specifically military topics. Although most attacked
computers were at military and defense contractor sites, some were at
universities and research organizations. Over the next 10 months, we
watched this individual attack about 450 computers and successfully enter
more than 30. LBL is a research institute with few military contracts and
no classified research (unlike our sister laboratory, Lawrence Livermore
National Laboratory, which has several classified projects). Our computing
environment is typical of a university: widely distributed, heterogeneous,
and fairly open. Despite this lack of classified computing, LBL's
management decided to take the intrusion seriously and devoted considerable
resources to it, in hopes of gaining understanding and a solution. The
intruder conjured up no new methods for breaking operating systems; rather
he repeatedly applied techniques documented elsewhere. whenever possible,
he used known security holes and subtle bugs in different operating
systems, including UNIX, VMS, VM-TSO, EMBOS, and SAIL-WAITS. Yet it is a
mistake to assume that one operating system is more secure than another:
Most of these break-ins were possible because the intruder exploited common
blunders by vendors, users, and system managers. Throughout these
intrusions we kept our study a closely held secret. We deliberately
remained open to attacks, despite knowing the intruder held system-manager
privileges on our computers. Except for alerting management at threatened
installations, we communicated with only a few trusted sites, knowing this
intruder often read network messages and even accessed computers at several
computer security companies. We remained in close touch with
law-enforcement officials, who maintained a parallel investigation. as this
article goes to press, the U.S. FBI and its German equivalent, the
Bundeskriminalamt (BKA), continue their investigations. Certain details are
therefore necessarily omitted from this article. Recently, a spate of
publicity surrounded computer break-ins around the world [23, 33, 37]. With
a few notable exceptions (e.g., [24, 36]), most were incompletely reported
anecdotes [7] or were little more than rumors. For lack of substantive
documentation, system designers and mangers have not addressed important
problems in securing computers. Some effrts to lighten security on common
systems may even be misdirected. We hope that lessons learned from our
research will help in the design and management of more secure systems. How
should a site respond to an attack? Is it possible to trace the connections
of someone trying to evade detection? What can be learned by following such
an intruder? Which security holes were taken advantage of? How responsive
was the law-enforcement community? This article addresses these issues, and
avoids such questions as whether there is anything intrinsically wrong with
browsing through other people's files or with attempting to enter someone
else's computer, or why someone would wish to read military databases.
Nonetheless, the author holds strong opinions on these subjects.

DETECTION

We firt suspented a break-in when one of LBL's computers reported an
accounting error. A new account had been created without a corresponding
billing address. Our locally developed accounting program could not balance
its books, since someone had incorrectly added the account. Soon
afterwards, a message from the National Computer Security Center arrived,
reporting that someone from our laboratory had attempted to break into one
of their computers through a MILNET connection. We removed the errant
account, but the problem remained. We detected someone acting as a system
manager, attempting to modify accounting records. Realizing that there was
an intruder in the system, we installed line printers and recorders on all
incoming ports, and printed out the traffic. Within a few days, the
intruder showed up again. We captured all of his keystrokes on a printer
and saw how he used a subtle bug in the Gnu-Emacs text editor [40] to
obtain system-manager privileges. At first we suspected that the culprit
was a student prankster at the nearly University of California. We decided
to catch him in the act, if possible. Accordingly, whenever the intruder
was present, we began tracing the line, printing out all of his activity in
real time.

ORGANIZING OUR EFFORTS

Early on, we began keeping a detailed logbook, summarizing the intruder's
traffic, the traces, our suspicions, and interactions with law-enforcement
people. Like a laboratory notebook, our logbook reflected both confusion
and progress, but eventually pointed the way to the solution. Months later,
when we reviewed old logbook notes, buried clues to the intruder's origin
rose to the surface. Having decided to keep our efforts invisible to the
intruder, we needed to hide our rcords and eliminate our electronic
messages about his activity. Although we did not know the source of our
problems, we trusted our own staff and wished to inform whoever needed to
know. We held meetings to reduce rumors, since our work would be lost if
word leaked out. Knwing the sensitivity of this matter, our staff kept it
out of digital networks, bulletin boards, and, especially, electronic mail.
Since the intruder searched our electronic mail, we exchanged messages
about security by telephone. Several false electronic-mail messages made
the intruder feel more secure when he illicitly read them.

MONITORS, ALARMS, AND TRAFFIC ANALYSIS

We needed alarms to instantly notify us when the intruder entered our
system. At first, not knowing from which port our system was being hit, we
set printers on all lines leading to the attacked computer. After finding
that the intruder entered via X.25 ports, we recorded bidirectional traffic
through that set of lines. These printouts proved essential to our
understanding of events; we had records of his every keystroke, giving his
targets, keywords, chosen passwords, and methodologies. The recording wa
complete in that virtually all of these session were captured, either by
printer or on the floppy disk of a nearby computer. These monitors also
uncovered several other attempted intrusions, unrelated to those of the
individual we were following. Off-line monitors have several advantages
over monitors embedded in an operating system. They are invisible even to
an intruder with system privileges. Moreover, they gave printouts of the
intruder's activities on our local area network (LAN), letting us see his
attempts to enter other closely linked computers. A monitor that records
keystrokes within an operating systm consumes computing resources and may
slow down other processes. In addition, such an monitor must use highly
privileged software and may introduce new security holes into the system.
Besides taking up resources, on-line monitors would have warned the
intruder that he was being tracked. Since printers and personal computers
are ubiquitous, and because RS-232 serial lines can easily be sent to
multiple receivers, we used this type of off-line monitor and avoided
tampering with our operating systems. The alarms themselves were crude, yet
effective in protecting our system as well as others under attack. We knew
of researchers developing expert systems that watch fror abnormal activity
[4, 35], but we found our methods simpler, cheaper, and perhaps more
reliable. Backing up these alarms, a computer loosely coupled into our LAN
periodically looked at every process. Since we knew from the printouts
which accounts had been compromised, we only had to watch for the use of
these stolen accounts. We chose to place alarms on the incoming lines,
where serial line analyzers and personal computers watched all traffic for
the use of stolen account names. If triggered, a sequence of events
culminated in a modem calling the operator's pocket pager. The operator
watched the intruder on the monitors. If the intruder began to delete files
or damage a system, he could be immediately disconnected, or the command
could be disabled. When he appeared to be entering sensitive computers or}
downloading sensitive files, line noise, which appeared to be network
glitches, could be inserted into the communications link. In general, we
contacted the system managers of the attacked computers, though in some
cases the FBI or military authorities made the contact. Occasionally, they
cooperated by leaving their systems open. More often, they immediately
disabled the intruder or denied him access. From the intruder's viewpoint,
almost everyone except LBL detected his activity. In reality, almost nobody
except LBL detected him. Throughout this time, the printouts showed his
interests, techniques, successes, and failures. Initially, we were
interested in how the intruder obtained system-manager privileges. Within a
few weeks, we noticed him exploring our network connections--using ARPANET
and MILNET quite handily, but frequently needing help with lesser known
networks. Later, the monitors showed him leapfrogging through our
computers, connecting to several military bases in the United States and
abroad. Eventually, we observed him attacking many sites over Internet,
guessing passwords and accounts names. By studying the printouts, we
developed an understanding of what the intruder was looking for. We also
compared activity on different dates in order to watch him learn a new
system, and inferred sites he entered through pathways we could not
monitor. We observed the intruder's familiarity with various operating
systems and became familiar with his programming style. Buried in this
chatter were clues to the intruder's location and persona, but we needed to
temper inferences based on traffic analysis. Only a complete trace back
would identify the culprit.

TRACE BACKS

Tracing the activity was challenging because the intruder crossed many
networks, seldom connected for more than a few minutes at a time, and might
be active at any time. We needed fast trace backs on several systems, so we
automated much of the process. Within seconds of a connection, our alarms
notified system managers and network control centers automatically, using
pocket pagers dialed by a local modem [42]. Simultaneously, technicians
started tracing the networks. Since the intruder's traffic arrived from an
X.25 port, it could have come from anywhere in the world. We initially
traced it to a nearby dial-up Tymnet port, in Oakland, California. With a
court order and the telephone company's cooperation, we then traced the
dial-up calls to a dial-out modem belonging to a defense contractor in
McLean, Virginia. In essence, their LAN allowed any user to dial out from
their modem pool and even provided a last-number-redial capability for
those who did not know access codes for remote systems. Analyzing the
defense contractor's long-distance telephone records allowed us to
determine the extend of these activities. By cross-correlating them with
audit trails at other sites, we determined additional dates, times, and
targets. A histogram of the times when the intruder was active showed most
activity occurring at around noon, Pacific time. These records also
demonstrated the attacks had started many months before detection at LBL.
Curiously, the defense contractor's telephone bills listed hundreds of
short telephone calls all around the United States. The intruder had
collected lists of modem telephone numbers and then called them over these
modems. Once connected, he attempted to log in using common account names
and passwords. These attempts were usually directed at military bases;
several had detected intruders coming in over telephone lines, but had not
bothered to trace them. When we alerted the defense contractor officials of
their problem, they tightened access to their outbound modems and these
were no more short connections. After losinig access to the defense
contractor's modems, the still undeterred intruder connected to us over
different links. Through the outstanding efforts of Tymnet, the full X.25
calling addresses were obtained within seconds of an attack. These
addresses pointed to sources in Germany: universities in Bremen and
Karlsruhe, and a public dial-up modem in another German city. When the
intruder attacked the university in Bremen, he acquired system-manager
privileges, disabled accounting, and used their X.25 links to connect
around the world. Upon recognizing this problem, the university traced the
connections to the other German city. This, in turn, spurred more tracing
efforts, coordinating LBL, Tymnet, the university, and the German
Bundespost. Most connections were purposely convoluted. Figure 1 summarizes
the main pathways that were traced, but the intruder used other connections
as well. The rich connectivity and redundant circuits demonstrate the
intruder's attempts to cover his tracks, or at least his search for new
networks to exploit. Besides physical network traces, there were several
other indications of a foreign origin. When the intruder transferred files,
we timed round-trip packet acknowledgments over the network links. Later,
we measured the empirical delay times to a variety of different sites and
estimated average network delay times as a function of distance. This
measurement pointed to an overseas origin. In addition, the intruder knew
his way around UNIX, using AT&T rather than Berkeley UNIX commands. When
stealing accounts, he sometimes used German passwords. In retrospect, all
were clues to his origin, yet each was baffling given our mind-set that "it
must be some student from the Berkeley campus."

A STINGER TO COMPLETE THE TRACE

The intruder's brief connections prevented telephone technicians from
determining his location more precisely than to a particular German city.
To narrow the search to an individual telephone, the technicians needed a
relatively long connection. We baited the intruder by creating several
files of fictitious text in an obscure LBL computer. These files appeared
to be memos about how computers were to support research for the Strategic
Defense Initiative (SDI). All the information was invented and steepest in
governmental jargon. The files also contained a mailing list and several
form letters talking about "additional documents available by mail" from a
nonexistent LBL secretary. We protected these bogus files so that no one
except the owner and system manager could read them, and set alarms so that
we would know who read them. While scavenging our files one day, the
intruder detected these bogus files and then spent more than an hour
reading them. During that time the telephone technicians completed the
trace. We celebrated with milk shakes made with homegrown Berkeley
strawberries, but the celebration proved premature. A few months later, a
letter arrived from someone in the United States, addressed to the
nonexistent secretary. The writer asked to be added to the fictitious SDI
mailing list. As it requested certain "classified information," the letter
alone suggested espionage. Moreover, realizing that the information had
traveled from someone in Germany to a contact in the United States, we
concluded we were witnessing attempted espionage. Other than cheap novels,
we have no experience in this arena and so left this part of the
investigation to the FBI.

BREAK-IN METHODS AND EXPLOITED WEAKNESSES

Printouts of the intruder's activity showed that he used our computers as a
way station; although he could become system manager here, he usually used
LBL as a path to connect to the ARPANET/MILNET. In addition, we watched him
used several other networks, including the Magnetic Fusion Energy network,
the High Energy Physics network, and several LANs at invaded sites. While
connected to MILNET, this intruder attempted to enter about 450 computers,
trying to log in using common account names like root, guest, system, or
field. He also tried default and common passwords, and often found valid
account names by querying each system for currently logged-in accounts,
using who or finger. Although this type of attack is the most primitive, it
was dismayingly successful: In about 5 percent of the machines attempted,
default account names and passwords permitted access, sometimes giving
system-manager privileges as well. When he succeeded in logging into a
system, he used standard methods to leverage his privileges to become
system manager. Taking advantage of well-publicized problems in several
operating systems, he was often able to obtain root or system-manager
privileges. In any case, he searched file structures for keywords like
"nuclear," "sdi," "kh-11," and "norad." After exhaustively searching for
such information, he scanned for plain-text passwords into other systems.
This proved remarkably effect ive: Users often leave passwords in files
[2]. Electronic mail describing log-in sequences with account names and
passwords is commonly saved at foreign nodes, allowing a file browser to
obtain access into a distant system. In this manner he was able to obtain
both passwords and access mechanisms into a Cray supercomputer. Typical of
the security holes he exploited was a bug in the Gnu-Emacs program. This
popular, versatile text editor includes its own mail system, allowing a
user to forward a file to another user [40]. As distributed, the program
uses the UNIX Set-User-ID-to-Root feature; that is, a section of the
program runs with system-manager privileges. This movemail facility allows
the user to change file ownership and move files into another's directory.
Unfortunately, the program did not prevent someone from moving a file into
the systems area. Aware of this hole, the intruder created a shell script
that, when executed at root level, would grant him system privileges. He
used the movemail facility to rename his script to masquerade as a utility
periodically run by the system. When the script was executed by the system,
he gained system-manager privileges. This intruder was impressively
presistent and patient. For example, on one obscure gateway computer, he
created an account with system privileges that remained untouched until six
months later, when he began using it to enter other networked computers. On
another occasion, he created several programs that gave him system-manager
privileges and hid them in system software libraries. Returning almost a
year later, he used the programs to become system manager, even though the
original operating-system hole had been patched in the meantime. This
intruder cracked encrypted passwords. The UNIX operating system stores
passwords in publicly readable, but encrypted form [26]. We observed him
downloading encrypted password files from compromised systems into his own
computer. Within a week he reconnected to the same computer, logging into
new accounts with correct passwords. The passwords he guessed were English
words, common names, or place-names. We realized that he was decrypting
password filed on his local computer by successively encrypting dictionary
words and comparing the results to password file entries. By noting the
length of time and the decrypted passwords, we could estimate the size of
his dictionary and his computer's speed. The intruder understood what he
was doing and thought that he was not damaging anything. This, alas, was
not entirely true. Prior to being detected, he entered a computer used in
the real-time control of a medical experiment. Had we not caught him in
time, a patient might have been severely injured. Throughout this time the
intruder tried not to destroy or change user data, although he did destroy
several tasks and unknowingly caused the loss of data to a physics
experiment. Whenever possible, he disabled accounting and audit trails, so
there would be no trace of his presence. He planted Trojan horses to
passively capture passwords and occasionally created new accounts to
guarantee his access into computers. Apparently he thought detection less
likely if he did not create new accounts, for he seemed to prefer stealing
existing, unused accounts.

INTRUDER'S INTENTIONS

Was the intruder actually spying? With thousands of military computer
attached, MILNET might seem inviting to spies. After all, espionage over
networks can be cost-efficient, offer nearly immediate results, and target
specific locations. Further, it would seem to be insulated from risks of
internationally embarrassing incidents. Certainly Western countries are at
much greater risk than nations without well-developed computer
infrastructures. Some may argue that it is ludicrous to hunt for classified
information over MILNET because there is none. Regulations [21] prohibit
classified computers from access via MILNET, and any data stored in MILNET
systems must be unclassified. On the other hand, since these computers are
not regularly checked, it is possible that some classified information
resides on them. At least some data stored in these computers can be
considered sensitive, especially when aggregated. Printouts of this
intruder's activities seem to confirm this. Despite his efforts, he
uncovered little information not already in the public domain, but that
included abstracts of U.S. Army plans for nuclear, biological, and chemical
warfare for central Europe. These abstracts were not classified, nor was
their database. The intruder was extraordinarily careful to watch for
anyone watching him. He always checked who was logged onto a system, and if
a system manager was on, he quickly disconnected. He regularly scanned
electronic mail for any hints that he had been discovered, looking for
mention of his activities or stolen log-in names (often, by scanning for
those words). He often changed his connection pathways and used a variety
of different network user identifiers. Although arrogant from his
successes, he was nevertheless careful to cover his tracks. Judging by the
intruder's habits and knowledge, he is an experienced programmer who
understands system administration. But he is by no means a "brilliant
wizard," as might be popularly imagined. We did not see him plant viruses
[18] or modify kernel code, nor did he find all existing security
weaknesses in our systeM. He tried, however, to exploit problems in the
UNIX/usr/spool/at [36], as well as a hole in the vi editor. These problems
had been patched at our site long before, but they still exist in many
other installations. Did the intruder cause damage? To his credit, he tried
not to erase files and killed only a few processes. If we only count
measurable losses and time as damage, he was fairly benign [41]. He only
wasted systems staff time, computing resources, and network connection
time, and racked up long-distance telephone tolls and international network
charges. His liability under California law [6], for the costs of the
computing and network time, and of tracking him, is over $100,000. But this
is a narrow view of the damage. If we include intangible losses, the harm
he caused was serious and deliberate. At the least, he was trespassing,
invading others' property and privacy; at worst, he was conducting
espionage. He broke into dozens of computers, extracted confidential
information, read personal mail, and modified system software. He risked
injuring a medical patient and violated the trust of our network community.
Money and time can be paid back. Once trust is broken, the open,
cooperative character of our networks may be lost forever.

AFTERMATH: PICKING UP THE PIECES

Following successful traces, the FPI assured us teh intruder would not try
to enter our system again. We began picking up the pieces and tightening
our sytem. The only way to guarantee a clean system was to rebuild all
systems from source code, change all passwords overnight, and recertify
each user. With over a thousand users and dozens of computers, this was
impractical, especially since we strive to supply our users with
uninterrupted computing services. On the other hand, simply patching known
holes or instituting a quick fix for stolen passwords [27] was not enough.
We settled on instituting password expiration, deleting all expired
accounts, eliminating shared accounts, continued monitoring of incoming
traffic, setting alarms in certain places, and educating our users. Where
necessary, system utilities were compared to fresh versions, and new
utilities built. We changed network-access passwords and educated users
about choosing nondictionary passwords. We did not institute random
password assignment, having seen that users often store such passwords in
command files or write them on their terminals. To further test the
security of our system, we hired a summer student to probe it [2]. He
discovered several elusive, site-specific security holes, as well as
demonstrated more general problems, such as file scavenging. We would like
to imagine that intruder problems have ended for us; sadly, they have not,
forcing us to continue our watch.

REMAINING OPEN TO AN INTRUDER

Should we have remained open? A reasonable response to the detection of
this attack might have been to disable the security hole and change all
passwords. This would presumably have insulated us from the intruder and
prevented him from using our computers to attack other internet sites. By
remaining open, were we not a party to his attacks elsewhere, possibly
incurring legal responsibility for damage? Had we closed up shop, we would
not have risked embarrassment and could have resumed our usual activities.
Closing up and keeping silent might have reduced adverse publicity, but
would have done nothing to counter the serious problem of suspicious (and
possibly malicious) offenders. Although many view the trace back and
prosecution of intruders as a community service to network neighbors, this
view is not universal [22]. Finally, had we closed up, how could we have
been certain that we had eliminated the intruder? With hundreds of
networked computers at LBL, it is nearly impossible to change all passwords
on all computers. Perhaps he had planted subtle bugs or logic bombs in
places we did not know about. Eliminating him from LBL would hardly have
cut his access to MILNET. And, by disabling his access into our system, we
would close our eyes to his activities; we could neither monitor him nor
trace his connections in real-time. Tracing, catching, and prosecuting
intruders are, unfortunately, necessary to discourage these vandals.

LEGAL RESPONSES

Several laws explicitly prohibit unauthorized entry into computers. Few
states lack specific codes, but occasionally the crimes are to broadly
defined to permit conviction [38]. Federal and California laws have tight
criminal statutes covering such entries, even if no damage is done [47]. In
addition, civil law permits recovery not only of damages, but also of the
costs to trace the culprit [6]. In practice, we found police agencies
relatively uninterested until monetary loss could be quantified and damages
demonstrated. Although not a substitute for competent legal advice,
spending several days in law libraries researching both the statutes and
precedents set in case law proved helpful. Since this case was
international in scope, it was necessary to work closely with
law-enforcement organizations in California, the FBI in the United States,
and the BKA in Germany. Cooperation between system managers, communications
technicians, and network operators was excellent. It proved more difficult
to get bureaucratic organizations to communicate with one another as
effectively. With many organizational boundaries crossed, including state,
national, commercial, university, and military, there was confusion as to
responsibility: Most organizations recognized the seriousness of these
break-ins, yet no one agency had clear responsibility to solve it. A common
response was, "That's an interesting problem, but it's not our bailiwick."
Overcomimng this bureaucratic indifference was a continual problem. Our
laboratory notebook proved useful in motivating organizations: When
individuals saw the extent of the break-ins, they were able to explain them
to their colleagues and take action. In addition, new criminal laws were
enacted that more tightly defined what constituted a prosecutable offense
[6, 38, 47]. As these new laws took effect, the FBI became much more
interested in this case, finding statutory grounds for prosecution. The FBI
and BKA maintained active investigations. Some subjects have been
apprehended, but as yet the author does not know the extent to which they
have been prosecuted. With recent laws and more skilled personnel, we can
expect faster and more effective responses from law-enforcement agencies.

ERRORS AND PROBLEMS

In retrospect, we can point to many errors we made before and during these
intrusions. Like other academic organizations, we had given little thought
to securing our system, believing that standard vendor provisions were
sufficient because nobody would be interested in us. Our scientists'
research is entirely in the public domain, and many felt that security
measures would only hinder their productivity. With increased connectivity,
we had not examined our networks for crosslinks where an intruder might
hide. These problems were exacerbated on our UNIX systems, which are used
almost exclusively for mail and text processing, rather than for heavy
computation. Password security under Berkeley UNIX is not optimal; it lacks
password aging, expiration, and exclusion of passwords found in
dictionaries. Moreover, UNIX password integrity depends solely on
encryption; the password file is publicly readable. Other operating systems
protect the password file with encryption, access controls, and alarms. We
had not paid much attention to choosing good passwords (fully 20 percent of
our users' passwords fell to a dictionary-based password cracker). Indeed,
we had allowed our Tymnet password to become public, foolishly believing
that the system log-in password should be our only line of defense. Once we
detected the intruder, the first few days were confused, since nobody knew
what our response ought to be. Our accounting files were misleading since
the system clocks had been allowed to drift several minutes. Although our
LAN's connections had been saved, nobody knew the file format, and it was
frustrating to find that its clock had drifted by several hours. In short,
we were unprepared to trace our LAN and had to learn quickly. We did not
know who to contact in the law-enforcement community. At first, assuming
that the intruder was local, our district attorney obtained the necessary
warrants. Later, as we learned that the intruder was out of state, we
experienced frustration in getting federal law-enforcement support.
Finally, after tracing the intruder abroad, we encountered a whole new set
of ill-defined interfaces between organizations. The investigation
stretched out far beyond our expectations. Naively expecting the problem to
be solved by a series of phone traces, we were disappointed when the
pathway proved to be a tangle of digital and analog connections. Without
funding to carry out an investigation of this length, we were constantly
tempted to drop it entirely. A number of minor problems bubbled up, which
we were able to handle along the way. For a while this intruder's activity
appeared similar to that of someone breaking into Stanford University; this
confused our investigation for a short time. Keeping our work out of the
news was difficult, especially because our staff is active in the computing
world. Fortunately, it was possible to recover from the few leaks that
occurred. At first, we were confused by not realizing the depth or extent
of the penetrations. Our initial confusion gave way to an organized
response as we made the proper contacts and began tracing the intruder. As
pointed out by others [25, 36], advance preparations make all the
difference.

LESSONS

As a case study, this investigation demonstrates several well-known points
that lead to some knotty questions. Throughout this we are reminded that
security is a human problem that cannot be solved by technical solutions
alone [48]. The almost obsessive persistence of serious penetrators is
astonishing. Once networked, our computers can be accessed via a tangle of
connections from places we had never thought of. An intruder, limited only
by patience, can attack from a variety of directions, searching for the
weakest entry point. How can we analyze our systems' vulnerability in this
environment? Who is responsible for network security? The network builder?
The managers of the end nodes? The network users? The security weaknesses
of both systems and networks, particularly the needless vulnerability due
to sloppy systems management and administration, result in a surprising
success rate for unsophisticated attacks. How are we to educate our users,
system managers, and administrators? Social, ethical, and legal problems
abound. How do we measure the harm done by these penetrators? By files
deleted or by time wasted? By information copied? If no files are
corrupted, but information is copied, what damage has been done? What
constitutes unreasonable behavior on a network? Attempting to illicitly log
in to a foreign computer? Inquiring who is currently logged in there?
Exporting a file mistakenly made world readable? Exploiting an unpatched
hole in another's system? Closing out an intruder upon discovery may be a
premature reflex. Determining the extent of the damage and cooperating with
investigations argue for leaving the system open. How do we balance the
possible benefits of tracking an intruder against the risks of damage or
embarrassment? Our technique of catching an intruder by providing bait and
then watching what got nibbled is little more than catching flies with
honey. It can be easily extended to determine intruders' interests by
presenting them with a variety of possible subjects (games, financial data,
academic gossip, military news). Setting up alarmed files is
straightforward, so this mechanism offers a method to both detect and
classify intruders. It should not be used indiscriminately, however. Files
with plaintext passwords are common in remote job entry computers, yet
these systems often are not protected since they have little computational
capability. Such systems are usually widely networked, allowing entry from
many sources. These computers are fertile grounds for password theft
through file scavenging since the passwords are left in easily read command
procedures. These files also contain instructions to make the network
connection. Random character passwords make this problem worse, since users
not wishing to memorize them are more likely to write such passwords into
files. How can we make secure remote procedure calls and remote batch job
submissions? Passwords are at the heart of computer security. Requirements
for a quality password are few: Passwords must be nonguessable, not in a
dictionary, changed every few months, and easily remembered. User-generated
passwords usually fail to meet the first three criteria, and
machine-generated passwords fail the last. Several compromises exist:
forcing "pass phrases" or any password that contains a special character.
There are many other possibilities, but none are implemented widely. The
Department of Defense recommends pronounceable machine-generated words or
pass phrases [5]. Despite such obvious rules, we (and the intruder) found
that poor-quality passwords pervaded our networked communities. How can we
make users choose good passwords? Should we? Vendors usually distribute
weakly protected systems software, relying on the installer to enable
protections and disable default accounts. Installers often do not care, and
system managers inherit these weak systems. Today, the majority of computer
users are naive; they install systems the way the manufacturer suggests or
simply unpackage systems without checking. Vendors distribute systems with
default accounts and backdoor entryways left over from software
development. Since many customers buy computers based on capability rather
than security, vendors seldom distribute secure software. It is easy to
write procedures that warn of obvious insecurities, yet vendors are not
supplying them. Capable, aware system managers with plenty of time do not
need these tools--the tools are for novices who are likely to overlook
obvious holes. When vendors do not see security as a selling point, how can
we encourage them to distribute more secure systems? Patches to
operating-system security holes are poorly publicized and spottily
distributed. This seems to be due to the paranoia surrounding these
discoveries, the thousands of systems without systems administrators, and
the lack of channels to spread the news. Also, many security problems are
specific to a single version of an operating system or require systems
experience to understand. Together, these promote ignorance of problems,
threats, and solutions. We need a central clearinghouse to receive reports
of problems, analyze their importance, and disseminate trustworthy
solutions. How can we inform people wearing white hats about security
problems, while preventing evil people from learning or exploiting these
holes? Perhaps zero-knowledge proofs [20] can play a part in this.
Operating systems can record unsuccessful log ins. Of the hundreds of
attempted log ins into computers attached to internet, only five sites (or
1-2 percent) contacted us when they detected an attempted break-in.
Clearly, system managers are not watching for intruders, who might appear
as neighbors, trying to sneak into their computers. Our networks are like
communities or neighborhoods, and so we are surprised when we find
unneighborly behavior. Does security interfere with operational demands?
Some security measures, like random passwords or strict isolation, are
indeed onerous and can be self-defeating. But many measures neither
interfere with legitimate users nor reduce the system's capabilities. For
example, expiring unused accounts hurts no one and is likely to free up
disk space. Well thought out management techniques and effective security
measures do not bother ordinary users, yet they shut out or detect
intruders.

INTERNET SECURITY

The intruder's successes and failures provide a reasonable snapshot of
overall security in the more than 20,000 computers connected to Internet. A
more detailed analysis of these attacks is to be published in the
Proceedings of the 11th National Computer Security Conference [43]. Of the
450 attacked computers, half were unavailable when the intruder tried to
connect to them. He tried to log into the 220 available computers with
obvious account names and trivial passwords. Of these 220 attempted log
ins, listed in increasing importance, * 5 percent were refused by a distant
computer (set to reject LBL connects), * 82 percent failed on incorrect
user name/passwords, * 8 percent gave information about the system status
(who, sysstat, etc.), * 1 percent achieved limited access to databases or
electronic-mail shells, * 2 percent yielded normal user privileges and a
programming environment, and * 2 percent reached system-manager privileges.
Most attempts were into MILNET computers (Defense Data Network address
groups 26.i.j.k). Assuming the population is representative of nonmilitary
computers and the last three categories represent successful penetrations,
we find that about 5 percent of Internet computers are grossly insecure
against trivial attacks. This figure is only a lower limit of
vulnerability, since military computers may be expected to be more secure
than civilian systems. Further, cleverer tactics for entering computers
could well lead to many more break-ins. Whereas the commercial sector is
more concerned with data integrity, the military worries about control of
disclosure [8]. With this in mind, we expect greater success for the
browser or data thief in the commercial world. In a different set of
penetrations [37], NASA experienced about 130 break-ins into its
nonclassified, academic computers on the SPAN networks. Both the NASA
break-in and our set of intrusions originated in West Germany, using
similar communications links and searching for "secret" information.
Pending completion of law enforcement and prosecution, the author does not
make conjectures as to the relationships between these different break-ins.
Between 700 and 3000 computers are reachable on the SPAN network (exact
figures depend on whether LANs are counted). In that incident the break-in
success rate was between 4 and 20 percent. Considering the SPAN break-ins
with the present study, we find that, depending on the methods chosen,
break-in success rates of 3-20 percent may be expected in typical network
environments.

CONCLUSIONS AND COMMENTS

Perhaps no computer or network can be totally secure. This study suggests
that any operating system will be insecure when obvious security rules are
ignored. From the intruder's widespread success, it appears that users,
managers, and vendors routinely fail to use sound security practices. These
problems are not limited to our site or the few dozen systems that we saw
penetrated, but are networkwide. Lax system management makes patching
utility software or tightening a few systems ineffective. We found this
intruder to be a competent, patient programmer, experienced in several
operating systems. Alas, some system managers violate their positions of
trust and confidence. Our worldwide community of digital networks requires
a sense of responsibility. Unfortunately, this is missing in some
technically competent people. Some speak of a "hacker ethic" of not
changing data [37]. It is astounding that intruders blithely tamper with
someone else's operating system, never thinking they may destroy months of
work by systems people, or may cause unforeseen system instabilities or
crashes. Sadly, few realize the delicacy of the systems they fool with or
the amount of systems staff time they waste. The foreign origin of the
source, the military computers entered, and the keywords searched suggest
international espionage. This author does not speculate as to whether this
actually was espionage, but does not doubt that someone took the
opportunity to try. Break-ins from abroad seem to be increasing. Probably
this individual's intrusions are different from others only in that his
efforts were noticed, monitored, and documented. LBL has detected other
attempted intrusions from several European countries, as well as from the
Orient. Individuals in Germany [37] have claimed responsibility for
breaking into foreign computers. Such braggadocio may impress an
unenlightened public; it has a different effect on administrators trying to
maintain and expand networks. Indeed, funding agencies have already
eliminated some international links due to these concerns. Break-ins
ultimately destroy the network connectivity they exploit. If this is the
object of such groups as the German Chaos Club, Data Travellers, Network
Rangers, or various contributors to 2600 Magazine, it reflects the
self-destructive folly of their apparent cleverness. Tracking down
espionage attempts over the digital networks may be the most dramatic
aspect of this work. But it is more useful to realize that analytic
research methods can be fruitfully applied to problems as bizarre as
computer break-ins. It seems that everyone wants to hear stories about
someone else's troubles, but few are willing to write about their own. We
hope that in publishing this report we will encourage sound administrative
practices. Vandals and other criminals reading this article will find a way
to rationalize breaking into computers. This article cannot teach these
people ethics; we can only hope to reach those who are unaware of these
miscreants. An enterprising programmer can enter many computers, just as a
capable burglar can break into many homes. It is an understandable response
to lock the door, sever connections, and put up elaborate barriers. Perhaps
this is necessary, but it saddens the author, who would rather see future
networks and computer communities built on honesty and trust.