1
Table of Contents
1 - Introduction
1.1 Background 3
1.2 Purpose 3
1.3 Scope 3
1.4 Relationship of Incident Handling Guidelines to CIAC Workshop 4
1.5 Revision of Incident Handling Guidelines 4
2 - Responding to Incidents
2.1 Definitions 5
2.2 Causes of Incidents 5
2.3 Avenues of Attacks 5
2.4 Effects of an Attack 6
2.5 Incentives for Efficient Incident Handling 6
2.6 Priorities in Incident Handling 7
2.7 Stages /Steps of Incident Handling 7
2.7.1 Protection 7
2.7.2 Identification 8
2.7.3 Containment 9
2.7.4 Eradication 9
2.7.5 Recovery 10
2.7.6 Follow-up 10
2.8 Division of Responsibility 10
2.9 Reporting of Incidents 11
2.10 CIAC's Charter and Role 15
3 - Responding to Viruses
3.1 Introduction 16
3.2 Definition of Computer Virus 16
3.3 Overview of Virus Actions 17
3.4 History of Viruses 17
3.5 Basic Mechanisms of Viruses 18
3.6 Common Viruses and their Symptoms 19
3.7 How Viruses Work 25
3.8 Virus Weaknesses 27
3.9 Virus Platforms 30
3.10 Responding to a Virus Infection 30
3.10.1 Protection 31
3.10.2 Identification 33
3.10.3 Containment 37
3.10.4 Eradication 37
3.10.5 Recovery 38
3.10.6 Follow-up 38
4 - Responding to Worm Attacks
4.1 Introduction 39
4.2 Definition of Worm 39
4.3 A Brief History of Worms 39
4.4 Considerations in Worm Attacks 39
4.5 Basic Mechanisms of Worms 41
4.6 Recommended Steps for Responding 42
4.6.1 Protection 42
4.6.2 Identification 43
4.6.3 Containment 43
4.6.4 Eradication 44
4.6.5 Recovery 44
4.6.6 Follow-up 45
4.7 Final Words about Worm Attacks 46
5 - Responding to Hacker/Cracker Attacks
5.1 Introduction 47
5.2 Division of Responsibility 47
5.3 Recommended Steps for Responding 47
5.3.1 Protection 47
5.3.2 Identification 49
5.3.3 Containment 50
5.3.4 Eradication 51
5.3.5 Recovery 52
5.3.6 Follow-up 52
5.4 Automated Hacker/Cracker Attacks 52
5.5 More on Passwords 53
6 - Vulnerabilities
6.1 Introduction 55
6.2 Types of Vulnerabilities 55
6.3 UNIX Vulnerabilities 56
6.4 VM Vulnerabilities 56
6.5 VMS Vulnerabilities 57
6.6 MVS Vulnerabilities 57
6.7 File Protections 57
6.8 Concluding Comments 57
7 - Incident Handling Tools
7.1 Types of Tools Available 59
7.2 System Security Tools 60
7.3 Authentication Tools 60
7.4 Intrusion Detection Tools 61
8 - Exercises and Scenarios 62
References 67
1 - Introduction
1.1 Background
Responding to computer security incidents is generally not a simple matter. This
activity requires technical knowledge, communication and coordination among staff
responding to the incident, and adherence to applicable Department of Energy (DOE)
orders on computer security (i.e., DOE Orders 1360.2A and 5637.1 for unclassified and
classified computing, respectively). Incidents over the last few years indicate
that, if anything, responding to incidents is increasingly more complex. There have
been, for example, not one, but three largescale worm attacks since 1988. Intrusions
into machines are a serious concern, and increasing sophistication and collaboration
among network attackers poses considerable threat to the integrity of computing
resources. Viruses continue to infect MS-DOS and Macintosh computers, despite
widespread availability of virus detection and eradication software.
1.2 Purpose
These incident handling guidelines repeatedly mention the importance of establishing
and following written procedures for handling incidents. There are several reasons
for developing such guidelines:
1. The procedures in these guidelines will help site computer security personnel
develop more complete and effective contingency response procedures.
2. There is usually some degree of confusion during an incident. Written
procedures for handling incidents minimize confusion.
3. During times of increased stress (e.g., during a fast-moving incident),
people's attention usually becomes more narrow, and memory is more prone to
failure. Without a written procedure, the likelihood that someone responding
to an incident will respond ineffectively increases.
4. Written procedures can help computer security personnel understand and consider
the legal aspects of responding to attacks on computer systems.
1.3 Scope
These guidelines do not comprise an exhaustive set of incident handling procedures.
A lengthy set of guidelines would be too intimidating to read and to incorporate into
site contingency response plans. The discipline of responding to incidents is also
very much in its infancy. Because so much is yet to be learned about handling
incidents, this version of these guidelines will necessarily lack some degree of
sophistication and detail. In addition, it is impossible to specify specific
technical procedures for responding to the many types and versions of computer
systems within DOE. This guidelines document contains basic information about
responding to incidents which can be used, regardless of hardware platform or
operating system. For specific technical details necessary to implement many of the
recommendations in these guidelines, consult your system administrator or vendor.
NOTE: These guidelines are written for someone who has a working knowledge of the
field of computer science. The beginner in computer science will do well to refer to
an introductory text in this area to understand many of the computer science concepts
(e.g., functionality of operating systems) mentioned but not explained in these
guidelines.
1.4 Relationship of Incident Handling Guidelines to CIAC Workshop
Since its inception in early 1989, the DOE's Computer Incident Advisory Capability
(CIAC) team from Lawrence Livermore National Laboratory has assisted many sites in
dealing with a large variety of incidents. These guidelines reflect the corporate
experience of the CIAC team. The content of these guidelines also parallels the
content of the two-day CIAC workshop, "Responding to Incidents," and are designed to
help those unable to attend the workshop become familiar with the content of the
workshop and participate in workshop exercises. For more information about the CIAC
workshop, contact:
Thomas A. Longstaff
University of California
Lawrence Livermore National Laboratory
P.O. Box 808, L-619
Livermore, CA 94550
(415) 423-4416 or FTS 543-4416
longstaf@pantera.llnl.gov
1.5 Revision of Incident Handling Guidelines
These guidelines will periodically be revised and upgraded. Send comments and
feedback to:
E. Eugene Schultz
University of California
Lawrence Livermore National Laboratory
P.O. Box 808, L-619
Livermore, CA 94550
(415) 422-8193
gschultz@pantera.llnl.gov
__________
UNIX is a registered trademark of AT&T.
VMS and DECNET are registered trademarks of Digital Equipment Corporation.
Macintosh and Virus Rx are registered trademarks for Apple Computer Inc.
Amiga is a registered trademark for Commodore Business Machines.
PC and IBM Scan are registered trademarks for International Business Machines.
PC tools is a registered trademark for Central Point Software.
Sidekick is a registered trademark for Borland International.
Anti-Viral is a registered trademark for Softhansa of Berlin.
Anti-Virus is a registered trademark for OS Software.
Code Safe is a registered trademark of ChrisWare.
Data Physician, VIRHUNT and RESSCAN are registered trademarks for Digital Dispatch,
Inc.
Ingres is a registered trademark for Ingres Corporation.
Oracle is a registered trademark for Oracle Corporation.
Port of Entry is a registered trademark for Sector Technologies.
Virex is a registered trademark for CE Software.
VirusSafe is a registered trademark for ComNetCo.
2 - Introduction
2.1 Definitions
The title of this document includes the term incident. In its most broad sense,
incident refers to an adverse event in a computer system or the threat of such an
event occurring. Penetrations into computer systems or hoaxes, therefore, fall
within the definition of incident. However, not all incidents are of interest to the
computer security community. Damage to systems due to power outages, for example, is
not an incident within the domain of computer security. For the purpose of this
guidelines document, therefore, the term incident implies an incident related to
computer security. The term incident encompasses the following general categories
of adverse events:
1. Compromise of integrity (e.g., when a virus infects a file)
2. Denial of resource (e.g., when an attacker has set a system to single user
mode, locking out all other users)
3. Penetration (e.g., when a worm has breached a system)
4. Misuse (e.g., when an intruder makes unauthorized use of an account, or insider
incidents)
5. Damage (e.g., when a virus scrambles a file or makes a hard disk inoperable)
6. Intrusions (e.g, hacker/cracker incidents)
In contrast, an event is any noticeable occurrence in a system. A system crash and
an unusual graphic display are both events. Events may lead personnel to determine
that an incident is occurring, although closer investigation of events may or may not
indicate that something adverse from the standpoint of computer security is
occurring.
2.2 Causes of Incidents
There are at least four generic causes of computer security incidents. The first is
malicious code, such as viruses, worms, trojan horses, time bombs, and pests.
(Viruses, worms, etc. will be explained in detail shortly.) The second is called
procedural failures or improper acts. Examples include transmitting information from
a classified to an unclassified system or revealing one's password to someone else.
A third cause can be called intrusions or breakins. For example, an intruder might
bypass a system's authentication procedure, might attack a system using provided
services (e.g., using UNIX commands such as sendmail, finger, or rsh), or might
"snoop" (e.g., wiretapping, network monitoring, or electronic monitoring of
terminals). Finally, an incident might be caused by an insider attack.
2.3 Avenues of Attacks
Attacks originate through certain avenues or routes. If a system were locked in a
vault with security personnel surrounding it, and if the system were not connected to
any other system or network, there would be virtually no avenue of attack. More
typically, however, there are numerous avenues of attack, including:
1. Local networks
2. Devices connected illegally, such as a non-approved connection to a local
network
3. Gateways, which allow an attack to come from outside a network
4. Attacks through communications devices, e.g., modems, telebits, and integrated
systems digital networks (ISDN's)
5. Shared disks (e.g., transmission of a virus from one machine to another)
6. Downloaded or pirated software (e.g., from an electronic bulletin board)
7. Others, including direct physical access by an attacker
2.4 Effects of an Attack
There are at least five effects of attacks which compromise computer security:
1. Denial of service--Examples include network jamming, introducing fraudulent
packets, and system crashes and/or poor system performance, in which people are
unable to effectively use computing resources.
2. Unauthorized use or misuse of computing systems--System resources are tied up
by someone who does not have permission to use the system, or are used for non-
approved purposes (e.g., playing games on a U.S. Government computer).
3. Loss or alteration of data or programs--An example would be an attacker who
penetrates a UNIX system, then modifies the wtemp program so that the intrusion will
not be detected. Another example would be an infection by the SCORES virus on
Macintosh computers resulting in loss of data (the Scores virus may cause destruction
of files).
4. Compromise of protected data--An example in a multi-level system would be
sending a classified file to an uncleared user's account.
5. Loss of trust in computing systems--Users may become hesitant to use a computing
system which is plagued by virus infections, for example.
2.5 Incentives for Efficient Incident Handling
Learning to respond efficiently to an incident is important for numerous reasons.
The most important benefit is directly to human beings--preventing loss of human
life. Some computing systems are life critical systems, systems on which human life
depends (e.g., by controlling some aspects of surgery in a hospital or assisting air
traffic controllers).
An important but often overlooked benefit is an economic one. Having both technical
and managerial personnel respond to an incident requires considerable resources,
resources which could be utilized more profitably if an incident did not require
their services. If these personnel are trained to handle an incident efficiently,
less of their time is required to deal with that incident.
A third benefit is protecting classified, sensitive, and/or proprietary information.
One of the major dangers of a computer security incident is that information may be
irrecoverably lost. The loss of classified information jeopardizes our Nation's
security. Efficient incident handling minimizes this danger.
A fourth benefit is related to public relations. News about computer security
incidents tends to be damaging to an organization's stature among current or
potential clients. Efficient incident handling minimizes the potential for negative
exposure.
A final benefit of efficient incident handling is related to legal issues. It is
possible that in the near future organizations and/or institutions may be sued
because one of their nodes was used to launch a network attack. In a similar vein,
people who develop patches or workarounds may be sued if the patches or workarounds
are ineffective, resulting in damage to systems, or if the patches or workarounds
themselves damage systems. Knowing about operating system vulnerabilities and
patterns of attacks, then taking appropriate measures is critical to circumventing
possible legal problems.
2.6 Priorities in Incident Handling
It is important to prioritize actions to be taken during an incident well in advance
of the time an incident occurs. Sometimes an incident may be so complex that it is
impossible to do everything at once to respond to it; priorities are essential.
Although priorities will vary from organization-to-organization and institution-to-
institution, the following suggested priorities serve as a starting point for
defining an organization/institution's response:
o Priority one -- protect human life and people's safety; human life always has
precedence over all other considerations
o Priority two -- protect classified and/or sensitive data; our National safety and
security is second only to protecting human life
o Priority three -- protect other data, including proprietary, scientific,
managerial and other data, because loss of data is costly in terms of resources
o Priority four --prevent damage to systems (e.g., loss or alteration of system
files, damage to disk drives, etc.); damage to systems can result in costly down
time and recovery
o Priority five -- minimize disruption of computing resources; it is better in many
cases to shut a system down or disconnect from a network than to risk damage to
data and/or systems
An important implication for defining priorities is that once human life and National
security considerations have been addressed, it is generally more important to save
data than system software and/or hardware. Although it is undesirable to have any
damage and/or loss during an incident, systems can be replaced; the loss or
compromise of data (especially classified data), however, is usually not an
acceptable outcome under any circumstances.
2.7 Stages /Steps of Incident Handling
There are at least six identifiable stages of response to a computer security
incident. Knowing about each stage can help you respond more methodically (and thus
efficiently), and can also help you develop a more complete contingency response plan
for your organization.
2.7.1 Protection
Part of handling an incident is being prepared to respond before the incident
occurs. This includes establishing a suitable level of protections, so that
if the incident becomes severe, the damage which can occur is limited.
Protection includes preparing incident handling guidelines or a contingency
response plan for your organization or site. Having written plans eliminates
much of the ambiguity which occurs during an incident, and will lead to a more
appropriate and thorough set of responses. Second, part of protection is
preparing a method of notification, so you will know who to call and what
everyone's phone number is. For example, every member of DOE's Computer
Incident Advisory Capability (CIAC) Team carries a card with every other team
member's work and home phone numbers, as well as beeper numbers. Third, your
organization or site should establish backup procedures for every machine and
system. Having backups eliminates much of the threat of even a severe
incident, in that backups preclude data loss. Fourth, you should set up
secure systems. This involves eliminating vulnerabilities, establishing an
effective password policy, and other procedures, all of which will be
explained later in this document. Finally, conducting training activities is
part of protection. It is important, for example, to conduct "dry runs," in
which your computer security personnel, system administrators, and managers
simulate handling an incident.
2.7.2 Identification
This stage involves determining exactly what the problem is. Of course, many
if not most signs often associated with virus infections, system intrusions,
etc. are simply anomalies, such as hardware failures. To assist in
identifying whether there really is an incident, it is usually helpful to
obtain and use any detection software which may be available. For example,
widely available software packages can greatly assist someone who thinks there
may be a virus in a Macintosh computer. Audit information is also extremely
useful, especially in determining whether there is a network attack. It is
extremely important to obtain a system snapshot as soon as one suspects that
something is wrong. Many incidents cause a dynamic chain of events to occur,
and an initial system snapshot may do more good in identifying the problem and
any source of attack than most other actions which can be taken at this stage.
Finally, it is important to start a log book. Recording system events,
telephone conversations, time stamps, etc. can lead to a more rapid and
systematic identification of the problem, and is the basis for subsequent
stages of incident handling.
There are certain indications or "symptoms" of an incident which deserve special
attention:
o System crashes
o New user accounts (e.g., the account RUMPLESTILTSKIN has unexplainedly been
created), or high activity on an account that has had virtually no activity for
months
o New files (usually with novel or strange file names, such as data.xx or k)
o Accounting discrepancies (e.g., in a UNIX system you might notice that the
accounting file called /usr/admin/lastlog has shrunk, something that should make
you very suspicious that there may be an intruder)
o Changes in file lengths or dates (e.g., a user should be suspicious if s/he
observes that the .EXE files in an MS DOS computer have unexplainedly grown by over
1800 bytes)
o Attempts to write to system (e.g., a system manager notices that a privileged
user in a VMS system is attempting to alter RIGHTSLIST.DAT)
o Data modification or deletion (e.g., files start to disappear)
o Denial of service (e.g., a system manager and all other users become locked out
of a UNIX system, which has been changed to single user mode)
o Unexplained, poor system performance (e.g., system response time becomes
unusually slow)
o Anomalies (e.g., "GOTCHA" is displayed on a display terminal or there are
frequent, unexplained "beeps")
o Suspicious probes (e.g., there are numerous unsuccessful login attempts from
another node)
o Suspicious browsing (e.g., someone becomes a root user on a UNIX system and
accesses file after file in one user's account, then another's)
None of these indications is absolute "proof" that an incident is occurring,
nor are all of these indications normally observed when an incident occurs.
If you observe any of these indications, however, it is important to suspect
that an incident might be occurring, and act accordingly. There is no formula
for determining with 100 percent accuracy that an incident is occurring
(possible exception: when a virus detection package indicates that your
machine has the nVIR virus and you confirm this by examining contents of the
nVIR resource in your Macintosh computer, you can be very certain that your
machine is infected). It is best at this point to collaborate with other
technical and computer security personnel to make a corporate decision about
whether an incident is occurring.
2.7.3 Containment
The third stage of incident handling, containment, should occur only if the
indications observed during stage two conclusively show that an incident is
occurring. The purpose of the containment stage is to limit the extent of an
attack. For example, if there is a virus which can damage the disk drive
after a fixed number of boots, it is important to take action to prevent this
damage from occurring. Similarly, it is important to limit the spread of a
worm attack on a network as quickly as possible. An essential part of
containment is decision making, i.e., determining whether to shut a system
down, to disconnect from a network, to monitor system or network activity, to
set traps, to disable functions such as remote file transfer on a UNIX system,
etc.). Sometimes this decision is trivial; shut the system down if the
system is classified or sensitive, or if proprietary information is at risk!
In other cases, it is worthwhile to risk having some damage to the system if
keeping the system up might enable you to identify an intruder.
The third stage, containment, should involve carrying out predetermined
procedures. Your organization or site should, for example, define acceptable
risks in dealing with an incident, and should prescribe specific actions and
strategies accordingly. Finally, notification of cognizant authorities should
occur during this stage (see Section 2.9 of this document).
2.7.4 Eradication
Once an incident has been detected, it is important to first think about
containing the incident. Once the incident has been contained, it is now time
to eradicate the cause. Software may be available to help you in this
effort. For example, eradication software is available to eliminate most
viruses which infect small systems. If any bogus files have been created,
it is time to delete them at this point. In the case of virus infections, it
is important to clean and reformat any disks containing infected files.
(Important note: if a classified system has been infected with a virus, it is
essential to follow guiadance issued by the DOE Office of Safeguards and
Security. We also strongly advise in this case that a low-level format be
performed to ensure the integrity of classified information.) Finally, ensure
that all backups are clean. Many systems infected with viruses become
periodically reinfected simply because people do not systematically eradicate
the virus from backups.
5. Recovery. Once the cause of an incident has been eradicated, the recovery
phase defines the next stage of action. The goal of recovery to to return the
system to normal. In the case of a network-based attack, it is important to
install patches for any operating system vulnerability which was exploited.
Again, there is special guidance for recovery in classified computing systems
from the DOE Office of Safeguards and Security.
6. Follow-up. One of the most important stages of responding to incidents is
also the most often omitted---the follow-up stage. This stage is important
because it helps those involved in handling the incident develop a set of
"lessons learned" to improve future performance in such situations. This
stage also provides information which justifies an organization's computer
security effort to management, and yields information which may be essential
in legal proceedings.
The most important element of the follow-up stage is performing a post-mortem
analysis. Exactly what happened, and at what times? How well did the staff
involved in dealing with the incident do? What kind of information did the
staff need sooner, and how could they have gotten that information sooner?
What would the staff do differently next time? A follow-up report is
valuable in that it provides a reference to be used in case of other, similar
incidents. Creating a formal chronology of events (including time stamps) is
also important for legal reasons. Similarly, it is also important to as
quickly as possible obtain a monetary estimate of the amount of damage the
incident caused in terms of any loss of software and files, hardware damage,
and manpower costs to restore altered files, reconfigure affected systems, and
so forth. This estimate may become the basis for subsequent prosecution
activity by the FBI, U.S. Attorney General's Office, etc.
2.8 Division of Responsibility
One of the most important strategies for responding to an incident is to divide
responsibility among the people involved. This strategy, which should be
incorporated into every organization/site's incident handling procedures, minimizes
duplication of effort, and ensures that the most important tasks will become
completed in a timely manner. In a similar vein, some responsibilities are more
appropriate for some personnel than for others. At a minimum, for example, technical
responsibilities should be assigned to technically qualified personnel. We
recommend the following division of responsibilities:
1. End users. End users should notify site computer security authorities of
problems they notice. Throughout this document end users will be called the
"eyes and ears" of computer security--they frequently notice problems before
anyone else does. End users also should be told to not shut down a system or
disconnect from a network without first consulting site authorities. It many
cases it is desirable to keep a system running to avoid subsequent damage or
to stay on a network to attempt to localize attacks to that machine instead of
risking more widespread attacks. End users should also monitor and log system
activities (at least until more personnel are available to assist in handling
the incident), and obtain a system snapshot or a copy of infected files.
Finally, end users should follow their organization/site's reporting
procedures (see Section 2.9).
There are also some "do not's" for end users. End users should not, for
instance, modify the system or application software. Not only could
modification produce damage, but it could also destroy evidence and/or
important clues about the goals of an attack as well as to encourage an
attacker to penetrate other machines. It is also important for end users to
avoid talking to the media. Anything other than a well-deliberated and
coordinated response to the media through one's public affairs office is
likely to be a public relations catastrophe--avoid this mistake.
2. Technical personnel. Technical personnel have the responsibility of
verifying that an incident is occurring. Once it is determined that an
incident is in progress, technical personnel should follow the applicable
recovery procedures which have been prepared in advance. It is important to
divide work whenever possible--avoid duplication of effort, and ensure that
the very high priority work gets done. Thus, it is important for technical
personnel to communicate among each other frequently and systematically.
Technical personnel should also log all activities (including recording time
stamps), and gather information from system logs. If an incident in a
classified system is occurring, it is the responsibility of technical
personnel to protect classified data, and to follow containment, eradication
and recovery procedures pertaining to a classified system. Finally, technical
personnel should avoid talking to the media except through a public affairs
office spokesperson.
3. Site managers. Site managers need to prepare everyone else for handling an
incident. This process includes identifying key technical personnel,
maintaining contact lists, and ensuring that effective written procedures are
written, validated through training exercises, and widely available. Site
managers also need to obtain and coordinate technical support during an
incident. This may involve arranging for "shifts," since some incidents last
for days and even weeks. Finally, site managers need to coordinate with the
organization/site's public affairs office to determine what information needs
to be released to the media.
2.9 Reporting of Incidents
DOE Orders 5637.1 and 1360.2A cover required reporting procedures for incidents in
classified and unclassified computing systems, respectively. These Orders contain
many details concerning time requirements for reporting and what must be reported.
In overview, reporting of both classified and unclassified incidents must occur
through a chain of cognizant individuals.
IMPORTANT NOTE: Information about incidents and incident handling that pertains to
classified DOE systems or may have implications for such systems is subject to the
guidance in CG-SS-2 , the soon to be released DOE Classification Guide on Safeguards
and Security. Persons who handle incident reports at DOE sites should familiarize
themselves with this guidance in order to avoid an inadvertent violation or
compromise of classified information.
For a classified incident, an end user or system manager (if there is such a person)
reports the incident to the Computer Security System Officer (CSSO). The CSSO then
works with the Computer Security Site Manager (CSSM) on initial notification to DOE
and to produce a historical report on the incident. The CSSM then notifies the
Computer Security Operations Manager (CSOM) at the applicable DOE Operations Office.
The CSOM then notifies the Computer Security Program Manager (CSPM) at DOE
Headquarters.
Suppose, for example, that a virus incident occurs in a classified MS-DOS system. If
there is a system manager, the end user would inform the system manager . The system
manager (or end user, if there is no system manager) would assess the technical
problem to determine whether there is an incident. If the MS-DOS computer is
infected with a virus, the system manager would categorize the incident as a virus
infection, then inform the CSSO. The CSSO would notify the CSSM, who, in turn, would
notify the CSOM that an incident is in progress. The CSSM and CSSO would jointly
produce a historical report. The CSOM would inform the CSPM in a quarterly report of
important and routine incidents.
For an unclassified incident, the end user notifies the site's Computer Protection
Program Manager (CPPM). The CPPM in turn notifies the Computer Protection Program
Coordinator (CPPC) at the DOE Operations Office for that site. The CPPC then
notifies the head of unclassified computer security at the Office of Computer
Security Information Resources Management (IRM) at DOE Headquarters.
For example, if a virus infected an unclassified MS-DOS system, the user would notify
the system manager (if there were one). The user or system manager would then assess
the technical problem, categorize the incident as a virus incident, and inform the
CPPM of the situation. The CPPM would notify the CPPC, who would notify IRM that an
incident is in progress. The CPPC and the head of unclassified computer security at
IRM would jointly determine support needed to deal with the virus outbreak, and would
determine how the incident would affect classified computing within DOE. The CPPC
would also advise IRM of findings, measures taken, and a plan of action.
Example of Reporting Classified Incident within DOE
Example of Reporting Unclassified Incident within DOE
2.10 CIAC's Charter and Role
CIAC is a resource for personnel at DOE sites faced with computer security incidents.
The CIAC team consists of computer scientists from the University of California's
Lawrence Livermore National Laboratory who are available to assist on a 24-hour per
day basis. This assistance might be in the form of direct technical assistance,
information, or the names of technical personnel who can help with very specialized
and complex problems. CIAC coordinates efforts by DOE sites, other Government
agencies and teams, and vendors. CIAC also alerts and advises sites about
vulnerabilities, potential attacks, and other threats. Team members have written
these guidelines, and are developing databases of vulnerabilities, viruses, known
incidents, etc. CIAC also engages in training and awareness activities, and has
developed the two-day workshop on which this document is based.
3 - Responding to Viruses
3.1 Introduction
"It seems as if you can't trust anybody these days, at least when it comes to
software for MS- DOS systems and Macintosh computers. " You have probably heard a
friend relate how his or her computer became infected with a computer virus shortly
after a new program that somebody else loaned him or her was run. Even your own
machine may, in fact, have been affected. Worse yet, so-called shrink wrap software
is sometimes infected with computer viruses, as are pre-configured computers from
manufacturers. Did the salesperson who just demonstrated software on your machine
also infect your machine? You may not have thought about this possibility, but
vendor demos are becoming an increasing problem in terms of virus infections.
Fear of computer viruses will cause otherwise rational people to take wholly
irrational actions. Their fear is understandable; there is a real, evident threat
of computer virus infections. Viruses spread quickly and are often well hidden, and
viruses can cause irreparable damage (although this is not usually the case).
However, most people do not really understand what a computer virus is, and how to
prevent, identify, contain and eradicate these fragments of harmful code. This
chapter will define what a computer virus is and will describe how most viruses work.
This chapter will also acquaint you with computer viruses on common platforms, and
will apply our computer incident handling methodology to the problem of dealing with
a computer infected by a virus.
3.2 Definition of Computer Virus
A computer virus is a segment of unwanted, self replicating code that (similar to its
biological counterpart for which it is named) spreads from one computer to another by
attaching itself to an application program or other executable system component. In
this manner the virus survives and reproduces. A computer virus has several major
characteristics, including:
o Self-replication, that is, it can make exact copies of itself
o Requires a host program to survive, and lives within the host program
o Usurps control of the host programs functions for the virus' benefit
A computer virus spreads through an infected host, usually an infected application.
The infection spreads to a new computer by executing the infected application on the
new system. An infected program can be transmitted to the target system by disk or
tape, modem or local network, or any other means and is executed on that system. The
application then becomes infected, and the next time it is run, the virus will
attempt to again replicate itself.
While the computer virus and its biological counterpart seem similar, there are
specific differences. While a biological virus is a process of nature, a computer
virus was created by some malefactor. The virus is simply a computer program written
by somebody as an academic exercise, as a form a vandalism, or possibly to gain
recognition among peers. We are familiar with the motives of conventional vandals
(e.g., those who break windows at a school) and terrorists, but creating of viruses
seems to motivate another kind of person. Virus writers appear to want a
programming challenge, but misdirect their creative ability. Many virus writers
also fail to anticipate consequences of their behavior--the disruption and even
destruction their "prank" will cause.
3.3 Overview of Virus Actions
There is no such thing as a generic or prototypic type of virus. Every virus is to
some degree unique. There is some commonality, however, in the way viruses work:
o Infection of the host and its programs
o Survival and propagation of the viral code
o Transmission of the infection to other host applications
o Possible destructive side effects caused by the virus.
Most often the virus code will search for other programs that thus far have not been
infected. The virus will then select one of these programs and append itself to it
as demonstrated below. The virus will next modify the program so that it will
execute the virus part of the code before the actual program is executed. In this
way the virus will "get a chance to live" before the actual program is run. With
many viruses the user will probably not notice anything out of the ordinary initially
because the requested program will run, and will cause no interference with the
executing program.
At this point virus action diverges broadly. A virus may replicate virtually
forever, causing no really harmful damage (as in the case of the WDEF virus on
Macintosh computers). In a few cases, the virus may be downright malicious,
damaging applications, data files, or even the operating system, as in the case of
the Disk Killer virus on MS-DOS computers. Viruses have even been created to steal
data and transmit it during non-working hours to another machine, where the virus
author can peruse the information at his/her leisure.
3.4 History of Computer Viruses
The idea of self replicating code has been around since the late 1940's (see history
shown below). John von Neuman's creating the first self-reproducing program
stimulated considerable interest in this topic. At first developing self
replicating code was an academic exercise. Then it expanded into a game in Bell
Laboratory's "core wars." When main-frames were the only computing resource, the
goal was to battle for core, the main memory of the computer. Two opponent
programmers were each given a segment of memory and allowed to launch one program.
The computer then divided compute time equally, first allowing one program to
execute, then the other (in a time-sharing manner). Each program had two goals, the
first to live, and the second to destroy the other program. Part of a successful
survival strategy was for the program to make multiple copies of itself. During the
1960's and 1970's there was also a number of books on the topic of self-replicating
code and the possibility of using this code maliciously. Interest in self-
replicating code then waned temporarily. With the increased interconnectivity
between systems and availability of powerful computers in the last decade, however,
there has been increased interest in self- replicating code, and, in particular,
viruses. As personal computers became popular, the idea naturally extended itself to
creating life across separate disconnected machines. About the same time that
personal computers were becoming numerous, the previously centralized computer was
becoming part of a growing network of available hosts. The growth of the network
allowed a third form of life to spawn, the worm (which will be covered in Chapter 5
of this document). Malicious code, both self-replicating and non self-replicating,
began to be found. An issue of Scientific American even contained an article about
viruses in 1984.
A Brief History of Computer Viruses
1949 - John von Neuman A self reproducing program in Theory and Organization of
Complicated Automata
1960 - Bell Laboratory's Core Wars
1972 - Dave Gerrold, When Harley Was One, First edition only
1975 - John Brunner:,Shockwave Rider
1977 - Thomas J. Ryan, The Adolescence of P-1
1980 - IBM Trojan. All IBM 4341's stopped at 7:30 AM on 11 April 1980. Logic bomb
planted by disgruntled employee
1984 - Scientific American, A.K. Dewdney. First article written on computer viruses
1987 - Pakistani or Brain Virus, Lehigh Virus, Jerusalem Virus, IBM Christmas Virus
1988 - Morris Worm
1990 - Many known viruses on microcomputers and mainframes.
3.5 Basic Mechanisms of Viruses
Viruses generally work through a four stage process. First, the virus must be
transmitted to the host computer through an infected application or other executable
program. Once the infected program has been executed on the host computer, the virus
enters the second stage. The virus must now try to survive and propagate through the
computer's file system. Frequently, the virus will infect both applications and the
operating system. Sometimes the virus will also become resident in memory, so that
it can infect disks when they are inserted (as in the case of WDEF) or cause side
effects, such as characters falling to the bottom of the screen, as in the case of
the Cascade virus on personal computers. The virus survives by disguising its
presence (or at least not immediately announcing its presence), and by replicating as
quickly as possible. As it replicates it also attempts to infect floppies or network
mounted file systems, etc., so that it can continue to propagate between computer
systems. This is the third stage of the virus' life, the attempt to infect other
systems by retransmission of the viral code. At some point in the life of many
viruses, they enter the fourth and final stage. Either by malicious or poor design
practices, the virus causes interruptions in the processing of data or the corruption
or destruction of data.
3.6
Common Macintosh viruses
Names
Resources
Type ID Size
Comments
ÒPeaceÓ , MacMag virus INIT 6 unknown DR First virus on the Macintosh. Displays
ÒPeace on
EarthÓ message on March 2, 1988 and removes
itself the next day. Distributed via a HyperCard
stack. An XCMD installed the INIT into the
System. Its presence did cause problems with
some programs. Remove the INIT Resource with
ResEdit.
nVIR Family of viruses
nVIRa, nVIRb, nVIRc, AIDS, Hpat,
MEV#, FLU, Jude (J-nVIR) See below for specifics This virus is named after its resources.
There
are two general variations of this virus a and b.
See below for specifics.
nVIRa nVIR infected system file:
INIT 32 366
nVIR 0 2
nVIR 1 378
nVIR 4 372
nVIR 5 8
nVIR 6 868
nVIR 7 1562
nVIR infected Application:
CODE 256 372
nVIR 1 378
nVIR 2 8
nVIR 3 366
nVIR 6 868
nVIR 7 1562 In the case of both nVIRa and nVIRb, the virus
first copies the INIT 32 resource into the
System file, there after any system restart
causes the virus to become memory resident after
which any application launched will become
infected. After a set time period nVIRa will
announce its presence by beeping or saying ÒDonÕt
PanicÓ, if MacInTalk is present .
nVIRb, Hpat, MEV#, AIDS nVIR infected system file:
INIT 32 416
nVIR 0 2
nVIR 1 428
nVIR 4 422
nVIR 5 8
nVIR 6 66
nVIR 7 2106
nVIR infected Application:
CODE 256 422
nVIR 1 428
nVIR 2 8
nVIR 3 416
nVIR 6 66
nVIR 7 2106 nVIRb is similar to nVIRa, however it doesnÕt use
MacInTalk.
To detect either strain open the suspected
application with ResEdit and look for a CODE 256
resource of size 372 or 422 for nVIRa or nVIRb
respectively.
MEV# and AIDS are identical to nVIRb, except the
resource type will read MEV# or AIDS instead of
nVIR.
Hpat is the same as nVIRb except it adds a code
of 255 instead of 256 and has a resource type of
Hpat.
Dukakis Written in HyperTalk on a HyperCard stack called
"NEWAPP.STK". Adds itself to Home Card and other
stacks. Flashes a message saying, "Dukakis for
President in 88, Peace on Earth, and have a nice
day." This virus can be eliminated by using the
Hypertalk editor and removing the well commented
virus code.
Scores, NASA Scores infected system files:
INIT 6 772 1, 2, 3
INIT 10 1 020 0, 1, 4
INIT 17 480 1, 3
atpl 128 2410 0, 1, 4
DATA 400 7026 0, 1
Corresponding system files are:
0 = Desktop, 1 = System
2 = Note Pad, 3 = Scrapbook Files
4 = Scores
Scores infected applications:
CODE n+1 7026
Where n = the id of the first unused
CODE resource. Most virulent of the known viruses. Written by a
disgruntled employee of EDS. Replicates rapidly
and can cause unpredictable behavior. Looks for
files of Creator VULT, TYPE ERIC. (Note the
desktop is ERIK, not ERIC)These files were
internal projects of EDS and not actual programs.
Does not intentionally do damage, but causes
problems in other programs by being present.
Sexy Ladies Trojan Not a virus, but a Trojan Horse. Given away at
1988 San Fransisco MacWorld Expo;erased whatever
hard disk or floppy disk it was on when it was
launched.
INIT29
INIT29 infected system files:
INIT 29 712
INIT29 infected applications:
CODE n+1 712
Where n = the id of the first unused
CODE resource. Infects disks the moment they are inserted into a
Mac with an infected system. Its sole purpose is
to replicate itself , but has the unfortunate
side effect of obliterating any legitimate INIT
29 in any file it infects. It will infect any
file with resources. This makes it the only
virus (so far) which will attack documents as
well as applications.
WDEF-A, WDEF-B1 Infects the Desktop. Need not run an
application to be infected, but can
spread on disk insertion. Cases both the Macintosh IIci and the portable to
crash, severe performance problems on AppleTalk
networks with AppleShare servers, frequent
crashes when users try to save files in
applications under MultiFinder, problems with the
proper display of font styles (the outline style
in particular), damage to disks, Macintoshes with
8 megabytes of memory to crash, Erratic system
behavior due to incompatibility with the
"Virtual" INIT from Connectix.
MDEF, Garfield virus Virus Detective DA, search string:
Resource MDEF & Name "Garfield"
Resource MDEF & ID = 5378
MDEF or Garfield spreads through system and
application files, causes serious damage to the
menu system. Causes both the Macintosh 128K and
512K to crash. On the Macintosh IIci and IIfx,
the MDEF virus spreads from infected applications
to uninfected system files, but does not
propagate from infected systems to uninfected
applications. Vaccine will inform the user that
the system file has been infected, but is only
partially effective in preventing this virus from
infecting the system file, this may damage the
system.
Steroid trojan horse
QuickDraw Accelerator
TYPE: INIT
CREATOR: QDAC
Code Size: 1080
Data Size: 267
ID: 148
Name: QuickDraw Accelerator
File Name: " Steroid" (First 2
characters are ASCII 1)
The purported purpose of Steroid is to make
QuickDraw run faster on computers with 9 inch
screens. Steroid is actually an INIT that
contains malicious code to check for the system
date and to erase all mounted disks if this date
is July 1, 1990 or afterwards. Examine system
folder; if Steroid is there, save a copy and then
drag the icon to the trash folder and empty
trash, restart the Mac.
Common Macintosh Viruses
Common MS-DOS Viruses
Name Strains Mode of Infection,
Attributes Size
Potential Damage Comments
Pakistani Brain, Ashar, Shoe 8 RES,FDB Boot
(7K) BOT,RUN,DAT,FMT Some variations corrupt File
Allocation Table. Infects
Floppies Only.
Merritt, Alameda, Yale,
Golden Gate 8 RES,FDB Boot
(1K) BOT Golden Gate variation will
reformat drive C: after n
infections. Infects Floppies
Only.
South African, Friday 13 the
COM 2 COM 512 PRG Deletes host program if run on
Friday the 13th
Lehigh 1 RES,CC OVER PRG,FMT
Vienna, 648, Lisbon, Vienna-B,
Austrian, Dos-62, Unesco 12 COM 648 PRG 62-B variant deletes infected
files. Program errors cause
file fatalities.
Jerusalem, New Jerusalem,
Jerusalem-B, Payday, Black
hole, Blackbox 13 RES, COM,EXE,OVR 1808 RUN,PRG
April-1-COM, Suriv-01 1 RES,COM, 897 RUN,PRG Message: ÒAPRIL 1ST HA HA HA HA
YOU HAVE A VIRUSÓ , Deletes
host file.
APRIL-1-EXE, Suriv-02 1 RES,EXE 1488 RUN,PRG Same message, but causes system
lock-up instead of deleting
host file.
Suriv-03 1 RES,COM,EXE,OVR RUN,PRG
Ping-Pong,Bouncing Ball,
Italian 3 RES,FDB Boot RUN,BOT Bouncing dot appears on screen.
No other intentional damage.
Ping-Pong-B RES,FDB,HDB Boot RUN,BOT same as Ping-Pong
Marijuana, Stoned,New Zealand,
Australian 2 RES,FDB,HDP Boot
(1K) RUN,BOT,FAT Message: ÒYour computer is now
stoned. Legalize Marijuana.Ó
Affects partition record on
hard disk. No intentional
damage is done.
Agiplan, 1536, Zero Bug,
Palette 1 RES,COM 1536 RUN,PRG
1701,Cascade, Autumn,
Blackjack, Falling Leaves 7 ENC,RES,COM 1701 RUN,PRG Characters fall to the bottom
of the screen. Both 1701 and
1704 versions are also known
as: Autumn, Blackjack, Falling
Leaves
1704,Cascade-B ENC,RES,COM 1704 RUN,PRG
1704 Format ENC,RES,COM 1704 RUN,PRG,FMT
Oropax, Music, Musician 1 RES,COM 2756+ RUN,PRG Plays musical melodies
repeatedly. File size varies
from 2756 to 2860
DenZuk, Venezuelan, Search 6 RES, FDB Boot RUN,BOT Displays a purple DENZUK
graphic on a CGA, EGA or VGA
screen. Overwrites FAT. SYS
variation modifies the SYS
command to preserve viral code
against destruction. Infects
Floppies Only
Dbase 1 RES, COM 1864 DAT,RUN,PRG
DataCrime, 1280 4 COM,ENC 1280 PRG,FMT/FAT Attempts to format the disk, on
some systems this will fail,
but the attempt to format will
destroy the FAT or worse. Will
require a low level format to
repair.
DataCrime-B COM,ENC 1168 PRG,FMT/FAT Same as above
DataCrime II COM,EXE,ENC 1514 PRG,FMT/FAT Same as above
DataCrime II-B ENC,CC,COM,EXE 1917 PRG,FMT
405 1 COM Over PRG
FuManchu 1 RES,COM,EXE,OVR 2086 RUN,PRG
Ohio 1 RES,FDB Boot BOT
Icelandic, Disk-eating virus 3 RES,EXE 642 RUN,PRG Marks hard disk clusters as
bad
Icelandic II RES,EXE 632 RUN,PRG
Saratoga RES,EXE 661 RUN,PRG
December 24th RES,EXE 848-863 RUN,PRG infects one out of every ten
.EXE files run. If an infected
file is run on December 24th it
will stop any other program run
later, displaying the message
"Gledileg jol" (Merry
Christmas)
Israeli Boot, Swap 1 RES,FDB Boot BOT Reverses order of letters typed
creating typographical errors.
Typo 1 RES,FDB,HDB Boot BOT,RUN
Traceback, 3066 1 RES,COM,EXE 3066 PRG
Disk Killer 1 RES,FDB,HDB Boot BOT,RUN,PRG,DAT,FMT
Vacsina 1 RES,COM,EXE,OVR 1206 RUN,PRG
Mix1 1 RES,EXE 1618 RUN,PRG
Syslock, 3551 1 COM,EXE,ENC 3551 PRG,DAT Some claim this is 3555 bytes
in size.
Pentagon 1 FDB Boot BOT
Dark Avenger 1 RES,CC,COM,EXEOVR 1800 FAT,RUN,PRG, Infects every executable file
that is opened.
AIDS 1 COM Over PRG
2930 1 RES,COM,EXE 2930 PRG
Yankee Doodle 1 RES,COM,EXE 2885 RUN,PRG
Alabama 1 RES,EXE 1560 FAT,RUN,PRG
Ghost 2 COM 2351 BOT,PRG
Ghost - Boot RES,FDB,HDB Boot BOT,RUN
Typo/Fumble 1 RES,COM 867 RUN,PRG
Sunday 1 RES,COM,EXE,OVR 1636 RUN,PRG
Do-Nothing 1 COM 608 PRG
Sylvia/Holland 1 RES,COM 1332 PRG
Amstrad 1 COM 847 PRG Adds code to front of any .COM
file in the current directory.
The virus contains an
advertisement for Amstrad
computers.
Devil's Dance 1 RES,COM 941 RUN,PRG,DAT,FAT
4096 1 RES,CC,COM,EXE,OVR 4096 RUN,PRG,DAT,FAT Infects every executable file
that is opened.
Chaos 1 RES,FDB,HDB Boot BOT,RUN,PRG,FAT
W13 2 RES,COM 534 PRG
RES,COM 507 PRG A virus from Poland. Infected
programs are padded so their
length becomes a multiple of
512 bytes. Then the virus adds
637 bytes to the end of the
file. It will also intercept
any disk write and change it
into a disk read.
Vcomm 1 RES,EXE 637 PRG,
Perfume (alias 765 or "4711") 1 RES,COM,CC 765 PRG,RUN May ask a question, won't run
infected file unless the answer
is
"4711" (the name of a perfume).
In a common variant, the
questions have been overwritten
with garbage.
Virus-90 1 RES,COM 857 PRG
The Columns
Name: List the most common name of the virus and any
aliases. Also lists direct mutations of the virus.
Size: The infected file will increase in size by this
number of bytes. Note some viruses are not as
consistent as others. See the comments. Over: means
that the virus overwrites the application and does not
add its code to the application.
No. of known strains: List the number of known
relatives in this family of viruses. Since people
mutate viruses frequently this number is not guaranteed
to be accurate Comments: Notes on unique characteristics of the
virus.
Mode of infection: Attributes: Describes the modus
operandi of the virus:
EXE Infects .EXE files
COM Infects .COM files
OVR Infects program overlay files
FDB Infects Floppy disk boot sectors
HDB Infects Hard disk boot sectors
HDP Infects Hard disk partition table Potential Damage: Describes what kind of damage the
virus will attempt to do when it strikes.
BOT Overwrites (corrupts) the boot sector
RUN Interferes with application while running
PRG Corrupts program or overlay files
DAT Corrupts data files
FMT Attempts to format the hard disk
FAT Corrupts file linkage or the FAT table
RES Memory resident
Comments: Notes on unique characteristics of the
virus.
Common MS-DOS viruses
3.7 How Viruses Work
An overview of virus mechanisms has already been presented. In review, once a
computer virus is transmitted to a new host via an infected application, it can then
infect the new system. After infecting the new system, the virus will generally
attempt to stay hidden by employing a variety of strategies. At some point the virus
may activate and can cause damage to the host. This section is designed to help you
understand in far greater detail how viruses work, including how virus actions are
based on assumptions made about the host.
1. Transmission. Computer viruses are programs. They may enter a computer
by any route used to transfer a computer program. The most commonly used
route is via a floppy disk. Viruses can also be transmitted via a modem or a
local area network. We are aware of at least one computer manufacturer from
Taiwan that even shipped computers infected with the Disk Killer virus-- quite
a time saver! Shrink wrap software is becoming increasingly unsafe in terms
of risk of virus infection, and public domain and shareware software always
carries a risk.
The source of infection can vary. Some people's machines become infected when
someone borrows their computer for "just a minute to print a report," or "to
show you something very quickly." Others become infected when they purchase
shrink-wrap software. Even software houses are not immune from infection.
These distributors can pass software on to unsuspecting buyers, or (more
commonly)will take back used or demo'd software and repackage it, complete
with a new shrink-wrap outer coating. The disk may look as good as new, but
the previous user's machine may have been infected with a virus. You may
innocently use software from a shared file server that has been infected, or
use a shared computer connected to a central resource such as a laser-printer
that has been infected.
2. Infection. Once an infected program is copied to the hard disk or onto
one of the floppy disk drives, the target machine is usually not infected yet.
In most cases the user must actually run the infected software to release the
virus on that machine.
3. Execution. When an infected program is run, the computer virus interrupts
the normal execution of the program. The virus quickly takes control,
executes its viral code, then returns execution to the original program.
Most viruses execute so quickly that a user will not notice the delay.
Knowing about the structure of a program helps in understanding how a delay
may not be detectable. A program consists of a linear list of machine op-
codes that the computer will execute one at a time (see figure on next page)
When a virus infects an executable, it often adds the viral code to the bottom
of the program. This increases the program's length and changes its cyclic
redundancy check (CRC), or in unused stack space, only changes the CRC. The
virus must then patch the first line of the program with a jump statement to
the first line of the viral code. Finally, the last line of the viral code is
modified to return execution to the original program.
Computer virus infection
4. Masquerading. Once a virus infects a system it must try to survive both
accidental encounters with the operating system or the user as well as
purposeful search and destroy operations the user may attempt. To accomplish
this the virus may use several tactics. The first is to lay dormant. A
biological virus that kills its host immediately has little chance to spread;
the same principle applies to computer viruses. A computer virus may wait
for some specific trigger point, e.g., a designated number of boots on the
infected machine to occur before it causes any destructive or disruptive
effects to occur. This gives the virus time to spread throughout the host
system as well as to other systems with which the host has had contact before
someone is likely to notice the virus and eradicate it.
Viruses often employ some form of encryption to make them harder to discover.
For example, the DataCrime (Columbus Day) virus is almost completely encrypted
except for a small section of code that decrypts the rest of the program. A
search program could easily miss this viral code. Besides trying to hide from
detection programs, viruses can actively fight detection by modifying common
detection programs. Viruses also find innovative ways to hide, such as in the
stack space of other programs, or by marking disk sectors as bad and storing
the virus code in these sectors.
5. Activation. The activation mechanism checks for the occurrence of a
specific event. Not all viruses have an activation mechanism. If the virus
has one and the specific event occurs, however, the virus will try to
accomplish the objective of its author. A virus may activate based on two
major types of events. If the activation mechanism checks for a specific date
and time, the virus is called a time bomb. Examples of viruses which have
time bomb mechanisms are DataCrime (the Columbus Day) virus and the Jerusalem
virus on MS-DOS computers. If the virus checks for specific circumstances,
such as the number of system boots, then the virus is called a logic bomb. An
example of a logic bomb is the Lehigh-2 virus, which counts the number of
infections that have occurred. Unfortunately, viruses can activate on the
basis of either logic or a time bomb, or both, depending on the skill and
motives of the virus author. Other viruses are never intended to do
intentional harm. An example is the WDEF virus for the Macintosh computers.
However, even these programs can create real havoc such as slowing down or
disrupting a computer system, or can even result in loss of data.
6. Damage. The actual damage a computer virus may do is extremely variable.
Many viruses try to damage the data on the host's hard disk. Remember from
Chapter 2 that losing data on a computer system generally is more of a loss
than damage to the system itself and/or its hardware. If there are no
backups, any data loss can be permanent. Other viruses are intended to damage
specific targets. For example, the Scores virus was written by a disgruntled
employee who was searching for a specific program used only internally within
a particular company. The program looks for the files of creator VULT and of
type ERIC. Theoretically, Scores should not affect other computers, but due
to incompatibilities on systems infected by Scores, Scores can damage files.
Other viruses accidently do damage due to bugs/programming errors. No
matter what the damage, however, a computer virus will steal cycles, that is,
it takes away time and memory that other programs should have.
3.8 Virus Weaknesses
Viruses may be a formidable challenge, but they are not undefeatable for three
reasons. First, viruses must make assumptions about their hosts. If these
assumptions fail, the computer will crash due to system incompatibilities, the virus
may be easily detected, and/or the virus will fail to spread. Second, a virus may
try to masquerade its presence, but it can never disguise itself perfectly, because
viruses need a place to live and a time to run. Many viruses increase the original
file size of the hosts they infect. In addition, they usually modify the CRC, a
special code used to check the integrity of files, leaving viruses prone to
detection. Finally, the third virus weakness is that because a small portion of
virus code must remain constant, viruses leave fingerprints, i.e., observable
characteristics that allow them to be identified and subsequently eradicated.
Most anti-viral software takes advantage of one of these three weaknesses. The most
common scanning software looks for fingerprints within all system executables by
searching all mounted media for a specific binary pattern for each known virus. The
problem with scanners is that they only work for known viruses. Another class of
anti-viral software uses the other two weaknesses of viruses to detect changes in the
file size or file CRC. Even unknown viruses will probably have to modify one of
these two file characteristics. If the viruses do, they can be detected.
NOTE: You can implement some anti-viral protection without using anti-viral
software. Since most viruses affect file size, you can keep a record of original
files sizes, then can compare current file size if you ever suspect that something
is amiss.
3.9 Virus Platforms
We will look at two platforms that have been the most common target for computer
viruses, MS-DOS based computers, and the Apple Macintosh computers. In addition we
will look at the possibility of computer viruses infecting multi-user computers, such
as UNIX- or VMS-based machines.
1. MS DOS computers. Computers running the MS-DOS platform present a
tempting target to the virus author. One major weakness of the MS-DOS machine
and its non-compatible cousins such as the Atari and Macintosh is that these
types of machines run in a single state. Running in a single state means that
the operating system is not protected from its applications by the hardware,
as is the case with UNIX and other multi-user operating systems. In a single-
state machine, for example, when an application gets control, as signified by
the program counter pointing to the application code, it never has to give the
program counter back. In multi-user machines, a particular application may
try to keep the program counter, but the operating system can take it back,
giving the user or software a chance to kill the errant process.
Since any application can take control of the personal computer at any point,
MS-DOS is susceptable to infection in any of the following:
o boot record
o system files
o application files
Boot infectors attach viral code to the boot record or even replace the boot
record altogether. The boot record exists on every single MS-DOS disk, and
contains just enough information for the computer to load the rest of the
operating system. If one of these boot sector viruses infects a machine, the
virus will take control when the machine is initially booted, and will control
the machine from that point on. These programs often stay in memory and
infect other programs as well as possibly disrupting the system substantially.
A virus that stays in memory is very similar to a memory resident utility such
as Sidekick or PCtools. This type of virus uses one of the many ways a
program can terminate and stay resident (TSR) to stay active and control the
program counter and the interrupts. A resident virus can monitor all
interrupts and trap all system events. If the virus is monitoring a system,
it can be programmed to take a number of sophisticated measures to accomplish
its task. For example, it can hide if it appears that a detection program is
being run. It can modify or destroy data, or create havoc with system
activities and performance.
System infectors infect the operating system (which is actually a very
special application). Examples in the PC arena include IBMDOS.COM,
IBMBIOS.COM and in the case of the IBM version of PC-DOS, COMMAND.COM . Many
are not familiar with the first two files mentioned. When you format a disk
with the /s option, as in:
FORMAT A: /S
IBMDOS.COM, IBMBIOS.COM are created on the new disk as hidden files. Some
viruses specialize in infecting these three special files. Most often, if the
hidden system files or the equally hidden boot record is infected, the virus'
effects will not be noticeable to the user. Because IBMDOS.COM and
IBMBIOS.COM are hidden files, most users will not recognize if the size of
these files grows. Just as with boot infectors, the system infectors can
monitor all system activity, look for new disks to infect, and even take total
control of the systems activities.
Application infectors can infect any application program. The first viruses
infected only .COM files because the code was somewhat more simple to write.
Later some viruses were modified (or mutated, to use the analogy of biological
viruses) to infect only .EXE files. The next extension of this malicious work
was evidenced by newer viruses that could infect both .EXE and .COM files.
The code for infecting both .EXE and .COM files was even more complicated. An
example of this is the DataCrime (Columbus Day) virus.
DataCrime, 1280 4 COM,ENC 1280 PRG,FMT/FAT Attempts to format the disk, on some
systems this will fail, but the
attempt to format will destroy the
FAT or worse. Will require a low
level format to repair.
DataCrime-B COM,ENC 1168 PRG,FMT/FAT Same as above
DataCrime II COM,EXE,ENC 1514 PRG,FMT/FAT Same as above
DataCrime II-B ENC,CC,COM,EXE 1917 PRG,FMT
The DataCrime Virus Family
DataCrime was originally written as a .COM infector. Later it was mutated to
become both a .COM and .EXE infector. We call slightly different viruses by
the same family name if the code is substantially the same. In the case of
the DataCrime virus, the major infectious and destructive portions of the code
remained the same. Only the method of attaching the code was changed by
determining if the file was a .EXE or .COM file, then branching to the
appropriate routine to cause the infection. Because the code is fundamentally
similar, if your computer were infected by DataCrime, the outward symptoms of
the infection would be virtually indistinguishable. However, close analysis
would reveal whether .EXE or .COM or both types of files were infected, and,
thus, the particular family member which infected your machine.
2. Macintosh computers. The operating system of the Macintosh is
fundamentally different in architecture from MS-DOS machines. Nevertheless,
Macintosh computers are also especially vulnerable to virus infections because
they also have single-state execution. In fact, the application structure of
Macintosh programs and the event queue structure of the operating system
greatly facilitate adding a virus to a Macintosh application. An application
on the Macintosh can be infected by adding viral code to the resource bundle
of the application. The virus can then have itself scheduled in the event
queue. In this manner the virus can obtain a certain portion of central
processing unit (CPU) time for its own malicious activities.
In the case of the nVIR virus, for example, the virus adds a CODE resource
#256. The virus then patches the jump table so that it will get executed
first. After infecting the computer, the virus returns control to the
application, so the user is not aware of the infection. After the viral code
is executed, nVIR first copies the INIT 32 resource into the system file.
Now any system restart causes the virus to become memory resident, after
which any application launched will become infected. After a set time
period, nVIRa announces its presence by beeping or, if MacInTalk is present,
saying ÒDonÕt Panic.Ó
Similar to the boot record of a MS-DOS PC, the Macintosh has a hidden file
called the desktop. However, the function of the desktop is to remember the
position of all the files, and the windows of that disk. The desktop is a
program and its run anytime something that affects the desktop is changed,
e.g., opening a folder or disk, or moving a file. The WDEF virus takes
advantage of this operation. Even if you only accept data-disks from other
people, and even if you never run unsafe software, your machine can
nevertheless get WDEF. WDEF spreads from sharing floppy disks, including any
Macintosh disk containing data or applications. If an infected disk is
inserted into a machine and the desktop is run, e.g., by copying a file, other
desktops on the machine, e.g., the hard-disk desktop, will be infected.
3. Mainframe computers. Larger computers, such as those running UNIX or VMS,
can also in theory be infected. However, although several claims of virus
infections of mainframe computers have been made periodically, no mainframe
viruses have as yet been detected and publically verified. If a mainframe
virus were to be released, it could reproduce itself in three possible ways,
namely by:
o Modifying source code
o Patching executable code
o Infecting data files
The first method would involve modifying the source code of an application.
Since programs are often shared as source, a virus could be written to modify
the source of other source programs on the computer. An especially ripe
target would be the compiler itself, such as cc (the C compiler).
Another method would be to infect executable applications, much as PC viruses
do, by adding executable code to an application binary. Fortunately, some
link editors in UNIX and VMS make code unrelocateable, making this method of
infecting a mainframe computer nearly impossible.
Another possible avenue of attack would be to modify a data file. Many data
files contain executable meta-commands that are interpreted by a pre-
processor. If a preprocessor or screen formatting process such as curses is
interpreting data, it could be vulnerable to attack.
Because mainframe viruses do not appear to exist outside of the closed,
laboratory environment at this time, greater detail about these viruses is not
warranted. Fortunately, because mainframes are not single-state machines and
because their operating and file systems are more complex, mainframes make
difficult targets for viruses. As mentioned above, executable code is often
unrelocateable on a mainframe. In addition, code usually cannot be executed
in a data segment. Finally, to be modified, files must have write access by
the program . The built-in safeguards of these operating systems provides
some protection against the ravages of potential viruses.
3.10 Responding to a Virus Infection
Some primary considerations for handling a computer virus infection include:
o Determining that your machine has actually been infected
o Containment and isolation of the infected host(s)
o Evaluation of the actual virus, and forming an eradication plan
o Cleaning up all media with which the infected host had contact
o Notifying all computer users that have had contact with the system
Dealing with a virus will be greatly aided by your using a notebook. You should
start your notebook by recording your current system configuration. List any network
services you use as well. Then jot down symptoms that your computer experienced
before and after you suspected a virus infection. Also create a list of media or
network contact that you may have made recently. If you use scanning software,
include printouts from the scanner with your notebook. If you are running more
advanced, database-driven virus software, include any warning messages, or printouts
displayed.
The first thing you should remember when you suspect that your computer has been
infected by a virus is that errors in applications, misconfigurations, or
interactions between hardware and software can create pseudosymptoms of viruses. For
example, you may load your applications from a shared file server for execution on
your local machine. Often an advantage to this system is that the application can be
upgraded for all users at one time. Unfortunately, the reverse side is that the
upgrade may not be compatible with your particular machine. If you are not aware of
software upgrades and new incompatibilities created by the software, you may be
experiencing a psuedosymptom of a computer virus. Another psuedosymptom frequently
observed is due to media, especially hard disks, approaching capacity. Some
applications do not have a fail soft mechanism for a full hard disk. Defective
media, again especially hard-disks, can also cause data corruption. Ironically,
people have had to deal with scrambled file allocation tables (FATs) on hard-disks
and floppies long before computer viruses were a problem!
We recommend that you maintain a curious and somewhat skeptical mind-set while
exploring the symptoms you are experiencing. First, compare your symptoms to the
known symptoms listed in the appendix of this document. Do the observed symptoms
match those of any known virus? If not, your computer may still have a virus,
because new viruses are being discovered almost every month. Contrawise, your
machine may not have a virus. It may pay to pursue other strategies as well. This
chapter will help you understand more about handling a computer virus incident, and
how to apply these methods to arrive at a valid answer.
3.10.1 Protection
The first and most important stage of computer virus incident handling is to
as much as possible avoid becoming infected in the first place. At the same
time, it is important to be prepared if your computer does become infected by
a virus.
Backups of all of your valuable programs and data are the best insurance you
can purchase for a speedy recovery from a virus infection. Backups help in
three ways. First, if a virus destroys the data on your hard-disk, you may
lose many months if not years of work. Why risk your labor to a faulty
mechanical drive, or a computer virus? If data or information is important
to you, back-it up. Secondly, backups help you return your machine to an
earlier state. If you suspect that a virus has erased your hard-disk, it is
too late to make a determination after it happens . A backup (even if
infected) will allow you to restore your machine for additional analysis.
Finally, even if your backup is infected, all viruses known to date do not
infect data, so you can still restore the infected back-up. Copy the data to
clean media, then reformat the disk. (Note: with this procedure, you cannot
save your applications).
Some programs can restore an application after the application has become
infected. However, it can be risky trusting an application that has been
repaired by a virus-tool, especially with PCs. A better approach is to
protect (write-protect) your distribution disks, and make backup copies of
every application when you take it out of its box. Except when there are
certain copy protection schemes, their is absolutely no reason why you should
insert a write-enabled disk into a computer to copy an application to your
hard-disk. Every application that you insert in your machine should be write-
protected. No known virus can circumvent the hardware that does write
protection, so if it is write-protected, it is safe!
This suggests procedures that are similar to a good insurance plan. First,
always write- protect your applications as soon as you get them. Then make a
backup copy from the write-protected original. Next periodically backup your
data. With your applications safely protected on write-protected media, you
don't necessarily need to backup all of your applications. If you back-up
only data with an incremental back-up, it will take very little time or
effort.
Virus protection programs can also be very useful. A whole new software
market has been created by the need for anti-viral software products. One of
the first types of products is a guardian program that warns users when an
application tries to write to the hard disk. While useful in analysis, this
kind of software is usually not good for day-to-day operation because it tends
to generate a large number of false alarms (false detections). Consequently,
the user may bypass this package with the result that there may be no
protection against virus infections. The next class of anti-viral software to
come on the market recently is the scanner. A virus scanner or hunter quickly
examines each byte of every application on the media you are examining. The
scanner has a database of virus signatures. If this type of product finds the
signature (e.g., an identifying string) embedded in an application, it gives a
warning, and (usually) some option to remove the virus. For example, a
fictitious scanner might display the following:
Anti-vir 23.3 running...........
Black-hole virus found in the application runme
Do you want to remove this virus? (y/n) y
Black-hole removed
Scanning software can make your job easier. However, it is dangerous to
depend on such a product, because scanning software has many pitfalls. One
problem (possibly the most critical one) is that scanning software can find
only the viruses it knows about. If a new virus or one of which the author of
the scanning program was not aware infects your machine, the scanner will pass
it by without a warning. A second class of software actually watches for
changes to your file system. This kind of software will detect new viruses,
since it does not depend on file signatures. Examples of commercially
available software in this class includes Data Physician by Digital Dispatch
Inc. and CodeSafe by ChrisWare.
Some Common Anti-Viral Software Packages
¥PC Prevention Programs
flushot+
DDI Data Physician
Chris Ware CodeSafe
¥MAC Prevention Programs
Virex
Dukakis Vaccine
GateKeeper/Gatekeeper Aid
RWatcher
Vaccine
VirusWarning INIT
When installing new applications, do not take unnecessary chances. Whether
you download software or purchase it shrink-wrapped, you should now know that
you should suspect this software. Examine the software before you load it.
Look at the application package. Does it look professionally prepared, and is
the documentation typeset? Read the license and at least some of the
introductory text. Is this software suspicious?
For example here is a portion of a license agreement from a disk that purports
to be an information package about the AIDS disease:
``In case of your breach of this license, PC Cyborg reserves the right to
take any legal action necessary to recover any outstanding debts payable to
the PC Cyborg Corp. and to use program mechanisms to insure termination of
your use of these programs. The mechanisms will adversely affect other
programs on your microcomputer.''
Does this look suspicious? It should. This is the license agreement that was
enclosed with the PC Cyborg AIDS trojan. If loaded and executed, this trojan
would hide all of your computer's files, and then would demand a payment to
get them back. The message you would see after this malicious code had hidden
the files would ask you to send a $387 fee to a Panama City address.
If you are an extra careful type of person, you might consider rigorously
examining a working copy of a new application with something such as Norton or
Mace Utilities. Look at the messages in the software. While you may not
always be able to obtain conclusive evidence, this procedure will help you
spot many viruses that use unencrypted message strings.
Before actually installing the program, you should use a virus scanning
program to check the media. Another optional step is to use an isolated test
machine, if you have one at your disposal. You should consider exercising the
package on the test machine for at least 30 days before you install it on your
operational computer. Before running the package, record the original file
sizes and the CRCs, then compare them to current values.
To summarize, when you install new software onto your system you should take
the following actions:
o Back-up the computer
o Write protect the original disks
o Examine the software package
o Run an anti-viral scanner on the distribution media
o Install the software on a test machine
o Install the package
3.10.2 Identification
Even if you follow the prevention strategy above, we cannot guarantee that
you will never get a virus. If you suspect that your machine has become
infected by a computer virus, the next step is to identify the problem. As
discussed previously, not all problems (e.g., anomalies, poor performance)
that you encounter with your computer will be a virus. In fact, polls in the
industry suggest that the probability of becoming infected by a computer virus
is only about four percent.
Before you proceed any further, you may want to create a fresh back-up of your
system. This ensures that if you or the virus actually damage any data, you
can return to a known state. Do not overwrite your old backup, but create a
new one. Remember, even if your back-up is infected, you probably can recover
the data files.
To identify the virus or problem,you should first record in your notebook the
symptoms you have observed in the past and are observing now. Then you should
look at the list of viruses and their symptoms (see Section 3.6) to determine
if the symptoms you are currently observing in your computer match those of
any given virus. If they do and you have eliminated other reasons for unusual
system behavior, then you should proceed to the next step, containment.
Virus identification tools
Virus identification tools (see figure above) have become so useful that they
are almost indispensable in the modern anti-viral arsenal. While tools are
not absolutely necessary, they can make dealing with a virus considerably
easier. Identification tools are not foolproof, since they can only identify
the viruses that they are programmed to identify. For such viruses, however,
these tools give almost positive proof that your machine is indeed infected.
Many of the programs listed above can also help eliminate the virus and repair
damage as well.
Let's look at a hypothetical example. Let's suppose you are about to use the
shared MS-DOS computer in your office when you notice characters falling from
their position on the screen, onto a heap at the bottom of the screen. You
suspect something is amiss. Upon inspecting the tables in Section 3.6 of this
document, you find the entry:
1701,Cascade, Autumn, Blackjack,
Falling Leaves 7 ENC,RES,COM 1701 RUN,PRG Characters fall to the bottom of the
screen. Both 1701 and 1704 versions
are also known as: Autumn, Blackjack,
Falling Leaves
You now strongly suspect that your PC has the 1701 or Cascade virus. You also
notice as you press the return key that the screen returns to normal, and you
are in the middle of an application. You quit the application (e.g.,
Interleaf) and return to the DOS prompt. Just to be sure, you decide to try
your trusty, if a little bit rusty, virus scanning program. You take the
program and write-protect the disk so that it will not become infected. You
now insert the disk into the A: drive and execute it. The drive whirls; you
get reassuring words that its working; but upon completion the program
indicates the machine is clean.
What can this mean? You look at the documentation for the scanning program.
You find that the program detects the 1701 virus, so what could be wrong? Two
things could be happening. First, this could be a mutant of the 1701 virus
that your scanning tool is not programmed to detect. Second, you may not have
a virus. Some screen-saving programs, such as the one in Interleaf, can have
virtually the same behavior as some viruses. It pays to be careful, but in
this case what appeared to be a virus infection was actually just the normal
action of a program.
The previous example probably best illustrates why virus identification is
still a "black-art." The best way to attack the problem of identification is
with appropriate knowledge and procedures for dealing with viruses. You
should know your platform, your applications, and how platforms and
applications interact. Note strange behavior on your system and develop
hypotheses to be tested.
Another example actually happened to a CIAC team member while he was getting
an estimate to repair his car. The clerk was looking up some part numbers and
availability of these parts on a Macintosh IIx. The CIAC team member noticed
that the machine was slower than should be the case for a CPU such as the
Macintosh IIx, and was also aware that the WDEF virus was becoming very
prevalent in the San Francisco Bay Area. He asked the clerk if it would be
o.k. to check the Macintosh for viruses. Using Disinfectant (a Macintosh
virus detection tool), the CIAC team member found the WDEF-A virus on the
machine, as well as all the rest of the Macintoshes in the immediate work
area.
To repeat, software tools are very useful. Remember, however, that knowledge
and good analysis procedures are at least as important in identifying and
dealing with viruses.
3.10.3 Containment
A virus is not fundamentally like a worm that replicates independently of
what users do. Responding to a virus, therefore, is not as dependent on the
speed of your reaction (except, perhaps, when a virus attacks something such
as a central file server machine). If you suspect your machine has a virus,
do not automatically reach for the off switch on your computer. Turning your
machine off is extremely unlikely to solve any problems. We recommend that
unless you know it is better to turn your machine off, leave it on. If a
virus has infected your computer and the virus counts the number of boots
(waiting for the count to reach a certain number), your action might push the
count over, causing it to attack your machine the next time you turn it on.
For example, in the case of the Disk Killer virus it is actually better to let
the virus finish its actions before you do anything. After the virus finishes
damaging the data on your hard disk, Disk Killer actually writes information
about what it affected . Some anti-viral utilities, therefore, can actually
restore the disk. There are a few other viruses, however, for which the best
response is to turn off your machine as fast as possible. This will give you
a chance to recover the entire disk. Again, being familiar with viruses and
their actions is a critical component of dealing with viruses.
When you suspect a computer virus has infected a computer, you should
immediately establish a quarantine. Disconnect the infected machine from any
network, then display a sign to caution people against using the computer.
Once you have verified the infection, tighten the quarantine--do not let
anyone use the computer until it is verifiably clean.
3.10.4 Eradication
Eradication is the process of removing a computer virus from your system.
The surest way to recover from a computer virus is to start with a clean
system again. A clean system is one in which the memory (both RAM and EEPROM)
is clear, and the hard-disk has been low-level formatted. Since some viruses
hide in the partition table or other specific portions of the disk, to fully
recover it is important to erase the entire disk (including system-
and hardware-specific areas such as the partition table).
Since a low-level format is completely destructive of all data on your disk,
you will want to first make a full back-up of your data files. Some viruses,
such as the Dukakis virus (which infects Hypercard stacks), actually infect
data-files . This is, however, a rare case. In most cases data cannot be
infected from currently known viruses. For the most part, therefore, you are
safe from reinfection if you restore your data from an infected disk.
However, the applications must come from clean source disks, not your hard
disk if you wish to be safe.
It is important to be careful how you reformat your disk. You cannot simply
issue the reformat command while the virus is in memory. You must power down
the system, and then reboot from some trusted source, perhaps a diskette if
the diskette boots first. Then issue the formatting instructions from that
trusted diskette or other clean source.
Some anti-viral products will also remove known viruses from applications.
Usually on Macintosh computers it is safe to allow these utilities to work.
This is because the process of adding code in a Macintosh application is quite
clean, and so is the removal. On the MS-DOS machines, however, automated
recovery has mixed results. If you are unsure, check the documentation. Most
anti-viral vendors are very straightforward in describing the particular
viruses for which their products are effective.
NOTE: If a classified system has become infected by a virus, it is essential
to follow guidance issued by the DOE Office of Safeguards and Security. In
addition, we strongly recommend doing a low-level format on your classified
system's hard disk.
3.10.5 Recovery
Recovery is the process of returning to normal operation. Once you have clean
hardware, you can begin restoring your system. Take out your original write-
protected applications disks and rebuild your file structure. If you have
scanning software, scan your hard disk to ensure that none of the original
disks were infected. Then carefully copy the data disk back to the hard disk.
Don't allow any executable that might have found its way to the back-up disks
to be copied onto the hard disk.
Scan one more time to make sure no infected applications made it back on the
hard disk. You have now returned the file system to a clean state. If you
practiced a good backup strategy, you should have all of your files and data
as clean as new. If you are exhausted from all the work, you can take comfort
that at least your hard disk is not fragmented. Loading all software over
reduces hard disk fragmentation considerably.
There is one more recovery issue. Remember to check all backup floppy disks
for virus infections! In many cases massive reinfections of a virus occur
because someone forgets to disinfect backups. Any floppy disk which contains
a virus should be erased and reformatted before it is used again. If this is
not possible, use a dependable eradication program to remove or repair
infected files.
NOTE: Again, if a classified system is involved, follow the guidance issued
by the DOE Office of Safeguards and Security to ensure that classified data
are not compromised.
3.10.6 Follow-up
Just because your system is now clean does not mean that all the work is over.
What about all the other people with whom your system has had contact (e.g.,
vendors or clients)? People who may have mailed you an infected disk, and
your co-workers should be told. If you don't practice this important follow-
up, then the virus will probably spread more, and your system is very likely
to become infected again. Inform others that you had a computer virus on
your machine and that they should check theirs. Tell them how you discovered
it, what the symptoms are, and how you recovered.
Now might be a good time to review your virus procedures and tighten scanning
of all disks entering machines in the area, at least until the "coast is
clear." How did the virus infection start? How adequate was the anti-virus
software that you used? How many person-hours did this effort require? Was
adequate technical assistance available? These questions must be answered and
any open issues must be resolved before your follow-up activity is complete.
4 - Responding to Worm Attacks
4.1 Introduction
Imagine thousands of computers connected to a communication network suddenly all
screeching to a halt. This actually happened in November, 1988, and the cause was a
worm-- the Internet (Morris) worm. Public awareness of a relatively unknown computer
threat jumped to a high level, with national news coverage and front page newspaper
articles. From this point in time onwards, computer worms have been a major concern
of all computer users connected to networks.
This section will concentrate on computer worms. Worms will be defined, and a brief
history of worm attacks will be given. The remainder of the section will outline a
methodology for handling a worm event as it happens. The handling of a worm event
follows the same pattern as other computer system attacks, and may be characterized
by the six stages of incident handling described in the overview section above. This
model will be used in describing the methodology for handling a worm attack.
4.2 Definition of Worm
A computer worm is a computer program in the category of malicious code with the
following characteristics:
o Is self-replicating
o Infects hosts rather than programs (unlike a virus)
o Attacks using automated hacking techniques to penetrate a host and begin
execution
o Exists as an autonomous process or set of processes
In general, a worm is very much like a virus, but with the primary distinction that a
worm will infect a host rather than an application. A worm will spread using
communication channels between hosts such as phone lines, networks, or gateways to
access services on another host. The worm will then use these offered services to
copy itself to the victim host and begin execution. The services used by the worm
will vary, depending on the specific worm, but may include electronic mail, remote
login, and remote file service.
The ability of worms to threaten thousands of computers is a direct result of the use
of network communication between these computers. When computers were mostly
isolated, worms could not easily jump between hosts. Today, the trend is for more
and more computers and networks to be interconnected to provide easy access and
distributed services. Worms take advantage of these advances in computer science to
threaten the worldwide computing environment.
Once a worm has penetrated a system and begins execution, it may alter the operating
system for its own use, cause damage, or simply access information and pass it back
to the wormÕs creator. Previously known worms have stolen user accounts and
passwords, installed trojan horse programs in the infected host, and caused denial of
service by utilizing all of the available computing resources. To date, only the
worms with relatively small disruptive potential have been released.
4.3 A Brief History of Worms
While the Morris Worm is the best known network based worm, it was not the first or
only network worm. Because it is the best known, however, other worms are dated in
relation to this one (see figure below).
A Chronology of Worms
The first recognized network-based worm was launched at Christmas time, 1987 and was
known as the Christmas Card Worm. This worm attacked IBM mainframe computers running
the VM/CMS operating system. It spread using the electronic mail system. When this
ÒChristmas cardÓ arrived at a person's account, it would exploit a feature that would
automatically forward itself to everyone in the person's mailing list. This resulted
in a denial of service over a large section of the internal BITNET of IBM due to the
large number of these ÒChristmas cardsÓ around the net. It did spread to the
external BITNET, but was not successful due to the loose coupling outside of the IBM
Corporation.
The Morris Worm has already been mentioned. It was released in November, 1988, and
spread through a nationwide TCP/IP network known as Internet. Several operating
systems, all variants of the UNIX operating system (such as BSD and Sun OS), were
successfully attacked by this worm. Four vulnerabilities in UNIX services were
exploited to spread the worm. One involved the electronic mail system (sendmail),
two more involved an authentication bypass mechanism (.rhosts and hosts.equiv), and
still another vulnerability involved a utility to find out who the users of a system
are (finger). The worm would also attempt to guess passwords on a penetrated system
and spread using the passwords it successfully guessed. The result of the Morris
Worm was a tremendous slowdown of all successfully penetrated systems due to a bug in
the code that caused the worm to replicate at a faster pace than intended.
Thousands of hours of system administration nationwide was required to eradicate and
recover from this worm.
Christmas, 1988 saw the first known VMS worm released. Named Father Christmas, this
worm had many of the same characteristics as the Internet Worm, and was obviously
influenced by the Internet Worm. The worm attacked a national DECNET, the Space
Physics Analysis Network (SPAN), and used a few well-known exploitable features in
VMS to copy itself between nodes and begin execution. This worm would send any user
names and accounts to a known location for later retrieval by the author. This worm
would first delete the file used to start the worm, thus leaving no trace in the file
system of the wormÕs presence. The worm would send a message to each user on a
system on Christmas Eve from ÒFather Christmas,Ó the basis for this worm's name.
In 1989, another VMS worm attacked a number of nationwide DECNET systems. Known as
the WANK/OILZ worm, this worm used many of the techniques found in other worms.
WANK/OILZ was quite complex. It would guess passwords, install trojan horses in the
penetrated system, add privileged accounts as back doors, and write annoying messages
to users of remote systems. The first variant, the WANK worm, was quickly followed
by the OILZ worm. The differences between the two was clearly intended to evade the
common scripts used to eradicate and prevent against the WANK worm. The intended
damage of this worm was severe. The worm would attempt to alter all of the
executable DCL scripts in the system to add accounts, and changed the user passwords
of all penetrated accounts.
4.4 Considerations in Worm Attacks
The major concerns in dealing with worm attacks are:
o Speed of reaction
o Indiscriminate spread
o Bugs contained in the worm code
o Reaction of worms to your incident response strategies
o Coordination between sites
The most pressing concern in reacting to a worm attack is the speed of response.
Because worms are automated attacks, they will proceed at the speed of the host
computer. In order to respond to them effectively, the worm must be quickly
identified and a correct reaction initiated to minimize the damage resulting from the
worm.
Worms usually do not follow any particular boundaries when choosing a victim machine.
Therefore, a worm will spread indiscriminately to any other host to which it can
connect and from which it can request services. In order to contain a worm, all
connections to other hosts must be discontinued. Note that simply because a
connection is not usually used (i.e., between a companyÕs computer and a Government
lab) does not change the fact that a worm could use a common network to spread along
this route.
It is difficult (if not impossible) to write error-free code, and worms are no
exception to this principle. All of the worms detected to date have had programming
errors (bugs) of one kind or another. In the most well- known case, the Morris worm,
the error in the code caused the worm to replicate itself within a host so rapidly
that no other processing on the host was possible. This caused an easy detection of
the worm, and led to a significant denial of service.
When dealing with a worm attack on a particular system, there is no need to take into
account the ÒfeelingsÓ of the worm. This is unlike a hacker attack, in which if you
respond rudely to a hacker, you may increase the possibility of damage to your
system. With a worm attack, the removal of the worm by any means at your disposal
cannot foreseeably change the reaction of the worm. The worm can neither adapt nor
react to your incident response strategies.
While it is always important to coordinate with other sites during an incident, the
nature of worms makes this coordination essential to a favorable resolution to a worm
incident. Because worms spread along network and other intra-site connections,
failure to coordinate your response with other sites will prevent complete recovery
to the worm attack. Worm attacks must be dealt with on the level of the
interconnections between the hosts. In the case of a worm on the Internet, the
entire Internet community must cooperate to completely eradicate the worm.
4.5 Basic Mechanisms of Worms
The basic mechanism of a worm is a two stage process. First, the worm must copy
itself to the victim host, and secondly, the worm must begin an execution of the copy
on the remote machine. To copy itself to another machine, the worm makes use of
services provided by the victim computer that are designed to accept information from
the attacking machine. These are services that both have proved useful to users and
are widespread (e.g., electronic mail, remote file service, ÒtalkÓ or ÒphoneÓ
services, and ÒfingerÓ services that will allow information about the users of a
system to be provided).
In order to complete the process, the attacking worm must be able to start the
execution of the worm on the victim machine. This is accomplished by exploiting
other services that are provided for this purpose. Examples include rsh (remote
shell execution for UNIX) or batch job submission. Other services not intended for
remote execution may contain bugs or features that allow remote execution without
authentication as well. Such bugs exist in many services such as sendmail, finger,
and network file systems. Each operating system has its own set of services that
may be exploited. This usually means that a worm is specific to a particular
operating system, or a set of systems providing common services.
4.6 Recommended Steps for Responding
This section will apply the methodology introduced in Chapter 2 to handling a
network-based worm attack. In review, this methodology includes the following
actions:
o Protection
o Identification
o Containment
o Eradication
o Recovery
o Follow-up
Each of these will be discussed in detail below.
4.6.1 Protection
Protecting against worm attacks involves a number of issues, but the primary
goal in protection is to assume that sometime you will experience a worm
attack in which your system will be penetrated. Given this assumption, a
worst-case scenario may be described, and countermeasures may be prepared.
This is not to say that prevention is impossible. All of the known worm
attacks to date could have been prevented if principles of good system
administration were followed, including:
o Sound password management
o Closing known vulnerabilities and installing provided patches
o Running the latest version of the operating system
o Assuring that the systems had been properly configured
In addition, good system administration practice will aid in the process of
recovery from a worm attack. Preparing for a worm attack includes:
o Preparing a set of procedures applicable to a worm attack
o Following a regular backup schedule
o Monitoring the system activity for unusual behavior
This methodology will aid in preparing a set of procedures for handling a worm
attack. However, a set of procedures that take into account site specific
considerations should be prepared ahead of time. These procedures should
include the names and phone numbers of persons to contact in emergency
situations involving worm attacks (as well as other incidents described in
this document).
As in other types of incidents, procedures are more important than software
solutions. For worms, this means that you should not rely on a software
protection package to assure that you will not have to handle a worm event.
Assume that a worm will get through your software defenses and determine the
countermeasures from that point of view. Of course, this does not mean that
you should not use software tools or install security patches to the operating
system, but always consider the worst case scenario as the basis for your
procedures.
4.6.2 Identification
Identifying a worm attack will require a careful analysis of the state of your
system. Some of the things to look for are:
o Unusual names for processes on your system
o Newly created files in special directories such as system, user, and
temporary directories. This is especially true if these directories are
world writeable or in unused accounts
o New or altered accounts
o Unexplained performance problems on your systems
Be sure to document all observations. You may compare situations where no
worm was found to exist with a new anomalous situation.
Some other important considerations in the identification of a worm event are
to keep in touch with your local computer security department and CIAC. You
should get an indication of a specific symptom for which to search from these
sources if a wide-spread worm event is underway. CIAC and other coordinating
groups will use the information you provide to aid other sites in getting the
worm under control. If this is not done, the worm will be free to attack your
systems again once you finish your recovery procedures.
In addition, be sure that your user community should be well aware of your
policy concerning worm identification. Chances are that your users will
detect anomalous behavior before you get a chance to monitor the system. User
education will allow you to have a network of worm detectors available
whenever a user is logged into the system.
4.6.3 Containment
Once it has been decided that a worm incident is under way, the most important
goal of the containment stage is to stop the spread of the worm beyond the
machines in which the worm has been detected. This is an exercise in getting
the situation back under control. A controlled environment is required in
order to effectively apply the subsequent stages of incident handling.
During the containment stage, you will have to make many important decisions
and gather valuable information on the situation. Planning is essential since
you will have to react quickly,but effectively. You will need to capture the
baseline state of your system in order to save it for future analysis. It is
probably not the case that you will be able to correctly analyze the worm
before it is under your control, so you should plan to record as much
information on the state of the system as you can. If practical, begin a full
backup at this time (being careful to mark the backup tapes as infected with
worm code). List and halt all nonessential processes on the system. If
classified information is involved, be aware of and immediately deal with the
threat involving disclosure of the information across any connected networks.
In order to gain control over your system, you may want to disconnect it from
all forms of external networks. This is probably an effective way to prevent
the spread of the worm, but realize that it may limit your ability to
communicate information about the worm as well. During the attack of the
Internet Worm, those systems that disconnected themselves from the Internet
were not able to receive critical information concerning how to destroy the
worm. If you do choose to disconnect from your normal communication networks,
be sure to keep in touch via telephone, FAX, or other media to CIAC or some
other coordinating group. CIAC is dedicated to providing solutions and
technical advice during such an attack.
Finally, do not neglect your appropriate reporting procedures during a worm
attack. Quite aside from technical issues that arise during a worm event, a
widespread worm will attract the attention of the national media. Following
the proper reporting procedures and allowing your public affairs group to
handle the press will help you keep your situation under control.
4.6.4 Eradication
Once the situation is under control and contained, it is important to
eradicate all traces of the worm from your affected systems. This may be
partially accomplished by removing processes (as described in the preceding
section), but there may also be other residue left from the worm. In
particular, be sure to check for:
o New accounts added by the worm, especially privileged accounts (such as root
accounts for UNIX systems, or privileged accounts on VMS systems)
o New files added by the worm--these files may be used during a reboot of the
system to restart the worm, and should be removed
o Files for proper ownership and protections--it is common for worms to leave
back doors in a system for the author to use later
o Trojan horses added by the worm--if possible, compare all executable files
to files from a trusted source (e.g., backup tapes or distribution media)
Use any eradication scripts provided by CIAC or other trusted source to aid in
the process of completely eradicating the worm code. Be sure to document all
of your actions during this process. Not only will this allow you to describe
precisely how your system has evolved, but gives you some additional
confidence that you have left no steps out in the eradication process.
For some systems, especially those involving classified processing, it may be
appropriate to completely erase the on-line storage and recover using clean
backup tapes and the original distribution of the operating system. Be
careful in this case to not only erase the disks, but shutdown the system to
clear the internal dynamic memory. If your system uses static memory as part
of its storage system, be sure that this is cleared as well.
4.6.5 Recovery
Before you can return to operational status, you must recover the state of the
machine to before the worm attacked. During this recovery, you want to
assure that the worm is eradicated from the system, and that it cannot
reinfect the system. To accomplish this, you must plan to install security
patches to close vulnerabilities exploited by the worm . (This may involve
changing user passwords or disabling a system service.) Use your records
from the eradication and detection stages to identify any modified or deleted
files, and restore these files from an uninfected backup copy. Restore
whatever system services you can, and restart the normal user services
unrelated to the worm infection.
After you have brought your system back to normal, you may consider placing it
back on the network (assuming that it was taken off the network in the
containment stage above). Before this step, assure that the worm infection
has been eradicated from the network and that it is safe to restore network
services. Coordinate with CIAC or other computer security groups to assure
that the time has come to restore your network connection.
4.6.6 Follow-up
Once you have restored the normal operation of the system, you enter the
follow-up stage of incident handling. This is an often neglected, but very
important stage for a number of reasons described in Chapter 2. In addition,
the substantial effort used to handle the worm incident will have to be
justified to management, and information that could be used to prosecute the
author of the worm must be properly handled.
An important goal in the follow-up stage is to analyze what happened. We
recommend that you create a report detailing the chronology of the incident,
actions taken, and lessons learned. This is the time for the detailed
analysis of the specific occurrences and information taken during the
incident. If the report is completed soon after the event, information that
was not chronicled during the event may be reconstructed. This report may be
used for a number of different purposes, so it is important that it be as
complete as possible, and that it contain a true chronology of events.
If you have any indication of other specific systems attacked, be sure to
notify the appropriate system managers as soon as possible. This may not only
help save additional systems from the damage and/or inconvenience the worm may
cause, but may also lead to reconstructing a path that the worm took through
the network. This, in turn, could help trace the worm back to its point of
origin. CIAC may be of great assistance during this activity to contact sites
and coordinate between investigating agencies.
It is often the case that one of the lessons learned is that if a particular
tool had been installed, the incident would have been easier to handle, or
perhaps would not have occurred at all. The follow-up stage is the time to
evaluate these tools and to decide which ones should be installed permanently
on the system. Be aware, though, that too many invasive security tools tend
to burden the user and will degrade the day-to-day operation of your system.
Choose which tools you will install carefully, and be aware of the tradeoffs.
It is very important to remove any on-line copies of the worm from your system
at this time. It is common for hackers to break into systems known to have
been attacked by a worm with the sole purpose to find a copy of the worm and
re-release it. There are many hackers who do not have sufficient knowledge to
write a worm themselves, but may modify an existing worm to evade a common
protection mechanism. This was the case with the OILZ variant of the WANK
worm. Lock up or otherwise isolate any copies of malicious code you may
obtain.
Finally, issue an Òall clearÓ message to your user base. With all the "hype"
associated with a worm incident, there may be many users who are confused
whether they can get back to a normal usage schedule. If you are working to
coordinate a number of systems, other system managers must be notified as
well.
4.7 Final Words on Worm Attacks
Network-based worm attacks are a natural extension of malicious code to the current
trend of interconnected, trusted systems. While it is currently impossible to
prevent all future worm attacks, following an effective set of procedures will help
you to deal with a worm event in a practical fashion and without panic. The national
attention these incidents receive will make handling a worm event tricky, but
following the procedures described in this chapter should keep the disruption of the
system to a minimum.
5 - Hacker/Cracker Attacks
5.1 Introduction
The term "hacker" is in many ways a misnomer. The term "hacker" can be used to
refer to someone who constantly plays with computers. A "hacker" can also imply a
computer expert. In the context of this manuscript, "hacker" is used somewhat
inappropriately to refer to someone who breaks into one or more computer systems.
"Hacker" is nevertheless useful, in that it is a commonly used term within the world
of computer security--few computer security experts fail to agree to some extent on
what people mean when they say that a hacker broke into a system. On the other
hand, "cracker" refers to someone who breaks into a system with malicious intent
(e.g., someone who breaks in, then trashes a user's files).
Dealing with hacker and cracker attacks is a special challenge. Along with internal
sabotage, hacker/cracker attacks are the most potentially destructive form of attack
to a single system. A worm may attack a network, and it may virtually close that
network. However, a worm is nothing more than an algorithm. Once the algorithm is
understood, the worm attack can be terminated. In a hacker/cracker attack there is
an intelligent human being back of a keyboard somewhere. Although the ethics of
their activity must be seriously challenged, critics often admit that
hackers/crackers are frequently resourceful and elusive. You can shut down the
machine that is being attacked, but the attacker is likely to simply hit another
machine. Furthermore, hacker/cracker attacks are far more frequent than people
realize. Hackers/crackers are often very careful to "cover their traces," so that it
may be difficult to notice the attack at all. Finally, there are international
hacking clubs and hacker bulletin boards. Communication among hackers/crackers makes
them better organized and increases information available to them, making them more
capable of succeeding in whatever goals they have.
There are many misconceptions about hacker/cracker attacks. One misconception is
that there is a single type of hacker or cracker, usually a frail teenage male with
weak social skills. Another is that hackers/crackers usually destroy and/or steal
files. Yet another misconception is that to break into a system requires
considerable knowledge about computer systems. All of these misconceptions are far
from reality! There is no single type of hacker or cracker--some hackers/crackers
are young, and some are considerably older. Some are quite knowledgeable about
computer science, whereas others know very little and mostly rely on bulletin boards
and "word-of-mouth" to break into systems.
5.2 Division of Responsibility
Responding to a hacker/cracker attack generally requires a great deal of coordination
from users and administrators of a system. Managers must implement and fund a
security plan, and must ensure that this plan is followed. System administrators
must fix security vulnerabilities and must take the lead in installing and
maintaining security tools on their systems. Users must be aware of a security plan,
and must operate their computer in a responsible manner. This may mean, among other
things, not using all the available features/utilities of their system if some
features introduce vulnerabilities. This may also mean furnishing the system manager
with pertinent information, such as information about numerous failed login attempts
on a user's account.
5.3 Recommended Steps for Responding
5.3.1 Protection
Protection against a hacker/cracker attack requires considerable effort. Taking
protective measures can never provide absolute assurance that your system(s) will
not be attacked, however. Additionally, some protective measures may be
characterized as proactive measures to ensure that responding to a hacker/cracker
attack will go more smoothly if and when such an attack occurs. (Remember, it is
essential to avoid viewing your system as invincible, and to devote a good
portion of effort to ensure that things will go smoothly when the inevitable
happens--your networked system is attacked by a hacker!) Protective or proactive
measures include having effective password management, obtaining and installing
special purpose hardware, creating backups, eliminating security holes, obtaining
and installing monitoring tools, and developing effective procedures.
Effective password management is so important that there is a separate section
devoted to this topic at the end of this chapter. Password management is, in
fact the single most effective protection mechanism for systems connected to a
network. At the most basic level, it is essential to require the use of
passwords for logins, regardless of whether the login is coming from a terminal
connected directly to a host machine or from a remote location. In the case of
logins from a modem, it is important to require a separate password for using the
modem! At the next level, it is critical to ensure that user accounts have
effective (i.e., not easily guessed) passwords. For example, passwords such as
TOYOTA, JENNIFER, and WEENIE are very easy-to-guess passwords--ask most any
hacker!
Special purpose hardware is also useful in protecting systems against
hacker/cracker attacks. This hardware may require the users to carry and use
some hardware (e.g.,, a plastic card or authentication device) before the login
sequence appears. When properly implemented, special purpose hardware can be
effective because it can virtually eliminate the threat of intrusion from afar.
Special purpose hardware, however has some drawbacks. The hardware can be
expensive, and it is often inconvenient to use a special card or electronic
device to gain access to a system. In addition, users with many accounts must
keep track of many devices. For this reason, special purpose hardware is not
widely used. We recommend such hardware when there is sensitive and/or
proprietary information on a system, or when there is another special need for
extra security. Another example of the wise employment of this hardware is when
organizations and agencies require its use when there is an unusual threat, such
as a recent rash of hacker/cracker attacks on the network to which that
organization/agency's machines are connected, but not at other times.
File protections are important in protecting systems against hacker/cracker
attacks. In general, files need to have protections such that only the users or
programs needing access to a given file have access. In particular, assure that
file protections for system binaries and home directories are not world-
writeable, and that sensitive files are not world readable or writeable. Also,
be aware of unexpected public files and directories with world read or write
privileges, and files in a user's directory not owned by the user.
Backups are also essential. You can do many things wrong as far as computer
security goes, but if you backup your system frequently, you will at least not
lose data. If you have frequent backups off-line, any attack can damage at most
only your on-line data. (Backups are good not only for handling hacker/cracker
attacks, for also for other incidents which could lead to a loss of data.) You
need an effective backup strategy to make backups work for you. As part of this
strategy, make sure that you back up every important file, and that you perform
the backup on non-volatile media. Use long backup cycles (e.g., backup once a
month), since it may take a considerable amount to time to detect a mistake in
backing up your data. Use separate media for each backup, and take the time to
verify that your backups are correct.
Another important step in protecting against hacker/cracker attacks is
eliminating security holes. Although this topic will be covered in more detail
in Chapter 6, it is introduced here to emphasize the role of unpatched holes in
hacker/cracker attacks. Many operating systems have numerous holes, whereas
others present opportunities for hacker/cracker attacks only if they are
improperly configured. In general, it is better to run the most recent version
of an operating system unless you know that the newest release introduces new
vulnerabilities (which, unfortunately, sometimes happens). Sun OS 4.1 is
considerably more secure than is Sun OS 3.4. For the sake of system security,
upgrade to Sun OS 4.1 in this case!! Keep in touch with information about
security holes distributed through user groups, emergency response teams such as
CIAC, etc., and take appropriate action (e.g., install the patches that are
available).
Obtaining and installing monitoring tools is another important protective
measure. There is a variety of monitoring tools available, and it is wise to
have a number of these tools. (Refer to Chapter 7 for more specific
information.) Now is the time to obtain and install these tools--you may find
that once a hacker/cracker attack starts, it is impossible to quickly obtain and
install the tools you need!
Developing effective procedures for responding to hacker/cracker attacks is
essential. These procedures should include call lists, lists of people to be
contacted during an incident. These lists should include both work and home
phone numbers, since emergencies often happen at inopportune times. (CIAC team
members have a laminated card containing phone numbers of other team members, our
site computer personnel, our operations office managers, and people at DOE
Headquarters! We wear this card with our badges.) Procedures should reflect
realistic time-distance considerations. If there is a hacker/cracker attack
during non-working hours, some people who will help respond to the hacker/cracker
attack may have to travel farther than others. Procedures should have those who
are closest to the site of response coordination initially doing all the work or
the most urgent tasks. Other considerations for developing effective procedures
include specifying who users should notify, how to get information out to users,
and what to tell users. Dealing with the media is also important. How should
calls from the media be handled, and what kind of information, if any, should be
given? Procedures should address shut-downs and when a system should be taken
off a network. When to prosecute and when not to prosecute should also be
covered, as well as the types of evidence that needs to be gathered if you decide
to prosecute. Procedures should address the need for keeping timestamps,
especially since hackers and crackers may change computer records. Who keeps the
"master clock?" Finally, it is important to decide how to create, change and
distribute your incident handling procedures, and to specify the tools or other
computing resources needed to implement your procedures.
We also recommend another simple protective measure. If practical to implement,
modify your system banner to delete any words or phrases which welcome users to
your system. At the same time, warn intruders with a message such as the
following:
WARNING: Unauthorized access to this computer system is prohibited, and is
subject to criminal and civil penalties.
Changing your system banner may not deter all or even most hackers, but it is
likely to deter some hackers. In addition, removing welcome messages in your
system banner may be important in that in a court of law welcome messages may be
considered invitations to intrude into systems.
5.3.2 Identification
Identifying a hacker/cracker attack can be an immense challenge. Good
hackers/crackers are incredibly good at avoiding detection, often by writing and
planting routines to mask their presence in systems they attack. There are a few
general clues that a hacker/cracker intrusion is occurring. A general clue is
that hacker/cracker attacks often occur during the night or early morning when
few users are on the system, or when the system manager is not on the system.
Cooperative users are the "eyes and ears" of computer security--keep in touch
with them, and encourage them to report unexplained failed login attempts and
other specific evidences of a hacker/cracker attack. Finally, detection tools
(covered in Chapter 7) are available to help identify an intrusion.
There are also specific indications of a hacker/cracker attack. Look for
combinations of the following:
o New, unauthorized user accounts
o Processes owned by unfamiliar users
o New files or file modifications
o Accounting discrepancies (e.g., charges for using your system do not
coincide with compute time)
o Changes in system files (e.g., password files)
o Modified/deleted data
o Denial of service (e.g., your system suddenly goes into single user mode,
locking you out)
o Poor system performance
o Anomalies (e.g., compiling new programs in a temporary directory)
o Suspicious probes (e.g., rlogin attempts) and/or browsing (e.g., file to
file)
5.3.3 Containment
Once you have identified that there is (or probably is, in many cases) a
hacker/cracker attack, the next step is to contain the attack. Containment may
not exactly be the correct term to describe all of the goals and procedures
necessary during this stage of response. Goals, for example, include
identifying the intent of the hacker/crack attack. Is this a malicious attack,
are system files being changed, or is the intruder just browsing? During this
stage it is also appropriate to start trying to identify the intruder. Intruders
have identifiable patterns of attack, and it is important to learn about other
ongoing hacker/cracker attacks to compare the pattern of your intrusion with
others. CIAC can be very useful to you at this stage, and you should also help
CIAC help others by notifying CIAC about your current situation periodically.
(CIAC will not reveal the name of your site to others.) It is important to
gather evidence to be used against the attacker (e.g., logfiles with timestamps).
Assessing damage incurred is also important both in gathering evidence for
prosecution, but also for urgent decisions to be made (covered in next
paragraph).
The containment stage involves a critical decision. You could pull the plug to
the compromised machine, or disconnect that machine from the network. This would
immediately terminate the attack, and would at least superficially relieve your
anxiety. In some cases this is the preferred decision, especially when files are
being destroyed or your machine is being used to launch many attacks on other
systems. In many cases, however, it is not wise to turn off your machine or
disconnect from the network. If you immediately terminate the attack, for
example, you may never know what the hacker/cracker has really done to your
system. Furthermore, the intruder will probably just find another machine to
attack, perhaps even a machine in your organization or site. If you can keep the
hacker on your machine without incurring substantial damage to that machine, you
can assess damage, gather evidence to identify and prosecute the intruder, and
probably save a lot of other system managers and users a lot of grief.
When we recommend that it is generally better to monitor the intruder's
activity, we assume that you will already have created system backups, and that
you will protect sensitive files and users' data. Additionally, you should never
risk compromising classified information. If there is any reasonable probability
that classified information could be compromised, it is imperative to turn your
system off or disconnect from the network. You will also have to determine the
extent of user interruption that can be tolerated while monitoring occurs. You
may need to remove computer service from the user community, and/or to inform
users that the system is being attacked. In general, we recommend the following
monitoring strategy.--try to keep the hacker on one machine. To do this you may
have to plant "treasures," games and/or bogus but interesting files (e.g., "
Highly protected data on nuclear arsenals"). Also, while you are monitoring be
sure to check periodically for phone messages. The intruder may try to call you!
Another consideration is that sophisticated intruders often get into protected
parts of a system and redirect electronic mail (e-mail)---the intruder may be
able to read the e-mail messages you send! Finally, if you notice that an
intruder has gotten into your system, do not taunt the intruder or order that
person off your machine. Do not turn a casual attacker into a dedicated
opponent! Encourage the intruder to call you, and find out what the intruder
wants. In several cases hackers have apparently permanently ceased hacking
activity when they were politely asked to do so, and when they were informed of
the extent of the problems they had caused. These now former hackers have on
several occasions, in fact, helped several emergency response teams correctly
determine that hacking attacks were occurring and which hackers were involved.
There are a few final considerations about monitoring activity. Be sure to
document everything (keystrokes, timestamps, the actions you take, etc.). You
will need the information you record to ensure that you communicate accurate
information to others with whom you are coordinating your response to the
hacker/cracker attack. (Remember, people under considerable stress are not
particularly good at retrieving information from memory.) Your documentation
will also be critical in subsequent stages of handling the incident. If your
monitoring efforts are unsuccessful, consider contacting the hacker directly
before you take any other measures such as turning your machine off. Finally,
remember that you should deal with the media only through your public affairs
office. Your taking on the media yourself may not only be against your
organization or site's rules, but also may be an invitation for catastrophe
unless you have specific training in dealing with the media.
5.3.4 Eradication
Eradication means ending the hacker/cracker attack. As mentioned previously, you
can eradicate the attack by turning off the attacked machine or disconnecting it
from the network. Hopefully, however, you can achieve a better solution---
identification and apprehension of the attacker. A third set of outcomes is
possible, too--the hacker/cracker might get bored or suspicious and terminate the
attack. Similarly, the hacker/cracker might obtain the data or programs that he
or she wants, and might then terminate the attack. Finally, the intruder might
voluntarily agree to terminate the attack.
For eradication to be complete, you need to take additional actions. If
applicable, remove the hacker from the system login files. Also, remove any
processes left by the intruder. Backup your system again to preserve any trail
the intruder may have left. (Again, remember that many hackers/crackers are
often very adept at covering their traces.) If you have a current backup, you
may seriously want to consider performing a complete restore.
5.3.5 Recovery
The recovery means that you or the system manager will restore the attacked
system to its "normal" state after the attack has been eradicated. The first
action is to perform a final damage assessment. You should now have more time
than with the previous stages of incident handling, because the hacker/cracker
attack has been eradicated. After determining the extent of the damage, close
any security vulnerabilities that the intruder exploited. For example if the
intruder entered your system through a sendmail hole, ensure that you obtain and
install a patch for this hole. Next, restore data. An attacker may change the
date and time stamp, so doing a full restore may require a full removal of all
files and a full restore from backups. Next, restore all services, and inform
users that the system is no longer being attacked and has been returned to normal
status. Finally, determine what tools used to handle the incident you should
leave in place. In general, discontinue using tools useful mostly or only in
dealing with the particular attack that occurred, but leave in place tools which
might be able to both help you detect intrusions and capture data early in the
incident handling process without severely taxing system performance.
5.3.6 Follow-Up
The follow-up stage is critical. If law enforcement agencies are not pressing
for prosecution, it is probably appropriate at this point to debrief the attacker
(if possible). Again, it is important to politely inform the attacker of the
effort handling the intrusion has required, and to learn any additional
information which may help you (e.g., other systems in your organization/site
which may have been attacked, methods and routes of attack, etc.) Be sure to
record all of the information you learn. Alternatively, you may need to assist
in prosecution efforts. In this case you should not talk to the attacker, but
should submit your logfiles and documentation of your efforts in dealing with the
incident to law enforcement agencies which ask for evidence. Regardless of
prosecution efforts, you need to determine time and resources used as well as
damage incurred, and should produce a monetary cost estimate. This estimate is
critical in a court of law, but it is also critical in justifying the importance
of adopting appropriate security measures and having an incident response team to
your management. In addition, determine how the incident happened. You know
have a valuable set of "lessons learned" which you can incorporate into a post-
mortem report--something to which you and others can refer during training, when
you revise your incident handling procedures, or when you have a similar incident
in the future. Review and revise your protection program, including your
procedures, password management policy, and arsenal of tools. Be sure among
other things that you are not introducing new security measures purely in
reaction to the recent hacker/cracker attack. Don't introduce unduly restrictive
policies or install numerous tools which diminish system performance simply
because an attack occurred !
5.4 Automated Hacker/Cracker Attacks
Some intruders have created tools to help them break into systems. For example,
password cracker programs that attempt to match candidate passwords with actual
system passwords are rather common. Some of these programs have very large
dictionaries. The success of these programs is an important reason why effective
password management is a must (see Section 5.5). Worms, discussed extensively in
Chapter 4, are another form of automated hacker/cracker attack. There are also
programs used to find system protection problems to enable hackers/crackers to break
into that system. (Note: these tools may also be used by computer security
personnel to locate vulnerable systems and make them more secure.) There are also
network snooping programs to help intruders locate systems to attack, and programs to
check for libraries that contain old bugs. These programs can be linked into other
programs to break security.
5.5 More on Passwords
By now you have seen how important a role passwords play in allowing intruders to
break into systems. The overwhelming problem is not really so much the individual
user as much as failure on the part of management to develop and implement an
effective password policy. Unfortunately, we have found that many organizations or
sites have no password policy at all! An effective password policy should mandate
that the following types of passwords and procedures are eliminated:
o "Joe" Accounts, in which the account name and password are identical (e.g.,
WILLIAMS and WILLIAMS)
o Same passwords for one user on different machines (e.g., WILLIAMS uses the
password tsr80p on SAMVAX and on BAKVAX). Intruders into a system often realize
that same passwords are frequently used on different machines, and capitalize on
this knowledge to break into other machines once they have initially broken into
a user's account. In general, using the same password on different machines is
the greatest problem when the hosts are run by different organizations, the
hosts have different levels of security, or the hosts have different operating
systems.
o Accessible password files. At a minimum, these files must be hidden.
Unfortunately, some older systems had a publicly known reversal to the
encrypting algorithm, thus making all accounts available once a hacker stole the
password file. Remember, if the encrypting scheme is known and the password
file is accessible, guesses can be made at the convenience of the attacker!
o Easily guessed passwords, including words found in Webster's dictionary, car
names, people's names, computer jargon and nicknames, "trendy" words, etc. Your
password policy should disallow these classes of words. Make sure that your
training and awareness program gets this message to users. Also, you should
consider using software to restrict users' choices of passwords, so that users
are forced to adopt more difficult-to-guess passwords. Remember, "brute force"
attacks in which password after password is tried are now easy because of
password cracker programs.
We also recommend that your password policy include the following:
o Checking for easily guessed passwords. Checking can be done when a user
chooses a password and/or at regular intervals (e.g., once every 30 days).
You can have the system manager disallow weak passwords when users choose
passwords. You can also obtain a password checking tool. (CIAC, for example,
can help you obtain a password checker for either UNIX or VMS.) Your policy
should include procedures for finding and changing easily guessed passwords.
o Using machine-generated passwords. There are advantages and disadvantages to
machine-generated passwords. These passwords, which may be letters, numbers,
syllables, or phrases, are difficult to guess. On the other hand, they are
more difficult to remember, especially when there are multiple accounts for
one user on several machines. Users tend to write down machine-generated
passwords (see below). If you are from a DOE site, DOE Order 5637.1 requires
that machine-generated passwords be used with classified computing systems.
Also, passwords for classified computing systems are classified at the same
level as the system.
o Obtaining and installing special purpose hardware (discussed previously).
o Adopting a password aging policy. In general, it is important to require users
to change passwords on a regular basis (e.g., every month in the case of
sensitive/proprietary systems, and every four to six months otherwise). For
one thing, if an attacker steals the password file, it will take time to crack
the passwords. Changing passwords from time-to-time may foil crackers' plans.
A password aging policy can also flag and lead to the removal of dormant
accounts. One disadvantage, however, is that users who are forced to change
passwords regularly may choose easier-to-guess passwords, because the user has
to create and remember new passwords.
o Developing a policy for writing down passwords. Sites and organizations often
prohibit writing down passwords because writing down passwords leads to
increased probability that passwords will be compromised. Slips of paper
with passwords, for example, are often put in wallets, which may be lost.
Also, it is important to remember that writing down a password for a
classified system requires following your classification guidelines! On the
unclassified side of the picture, there must be a policy for protecting
written passwords if writing down passwords is allowed. Writing down
passwords has one major advantage--it allows users to have passwords which are
harder to remember and guess.
Selecting a good password requires some inconvenience on the part of users. It is
more difficult to choose and remember a more difficult-to-guess password than an
easy-to-guess password. We concur with Wood and Kochan's (1985) recommendation to
use a four letter word, then a control character, then a four letter word which is
unrelated to the first word (e.g., dust&book). Such a password is easy to remember,
but is very difficult for an intruder to crack. Another sound technique for
constructing a password is the first letter method, in which the password consists of
the first letters of each word in an easily remembered sentence. For example, "my
Country tis of thee...sweet land of liberty" becomes mctotslol, which is easy to
remember but almost impossible to crack. Again, an effective awareness program which
motivates users to choose appropriate passwords is critical.
The "bottom line" is that your organization or site needs to create a password
policy. This policy will vary, depending on requirements of users and the particular
system involved. We have found, however, that the following additional guidelines
are applicable to most sites and organizations:
o Be sure you have a policy for detecting and removing "Joe" and dormant
accounts.
o Explicitly state a policy covering the periodic, mandatory changing of
passwords.
o If your site or organization uses machine-generated accounts, have a policy
for written password management.
o Include a password policy for installing accounts and machines. Remove or
disable all demo, default and guest accounts. When adding a new user to a
system, do not allow system managers to furnish users with an initial
password which can be easily guessed--users often do not change passwords!
o Build user education into your site or organization's password policy. User
education is time-consuming, but is critical in gaining user support and
giving users sufficient knowledge to avoid giving attackers easy access to a
system through weak passwords. Your user education plan should include
actually helping users select proper words such as non-dictionary words,
initial letters from phrases, etc.
6 - Vulnerabilities
6.1 Introduction
The terms "vulnerabilities" and "holes" have by now been used dozens of times in
these guidelines. All computer systems have some features that can be exploited by
an attacker. The emphasis of this chapter is upon these features. First, let's get
our terms straight. A vulnerability is a feature or bug in a system or program which
enables an attacker to bypass security measures. For example, suppose that there is
an operating system which, unbeknown to the developers of this operating system,
allows an unprivileged user to suddenly become privileged simply by hitting
CONTROL/C at a certain point in using one of the operating system's utilities. We
consider the difference between a vulnerability and hole to be an issue of semantics,
not one of practical significance. We, therefore, define a hole as a vulnerability.
A "Joe" account, previously covered in Chapter 5, is an account in which the account
name and password are identical. A default account is an account shipped with the
system that has a default password. (Unfortunately, system managers too infrequently
change default account passwords.) A patch is a modification to a program (e.g., an
operating system) to correct a bug or vulnerability. (Note: patches may have
undesirable side effects, unfortunately, depending on how a system is configured.) A
workaround is a "kluge," a makeshift, temporary solution to a vulnerability. For
example, if there is a system utility which allows unprivileged users to read other
users' files, a workaround might be to disable that utility (which, unfortunately,
may inconvenience many users).
There is generally (but not always) a tradeoff between the amount of functionality
that a system delivers and the number of exploitable features. For example, one of
the reasons that UNIX has traditionally had more exploitable features than many other
operating systems is that UNIX offers a great amount of functionality. Networking
functions, which are built into UNIX, offer attackers opportunities to jump from UNIX
machine to UNIX machine, to steal files, etc. It is essential that you know your
system well. You need to learn about the exploitable features in your system, and to
close these features within the constrains of user needs, manpower limitations, etc.
For example, you would do well to disable a seldomly used utility with a well-known
security hole because few, if any, users would miss that utility anyway. Disabling a
frequently used utility with an obscure hole may not be as advisable. Remember, too,
that one machine in a network which has unpatched vulnerabilities can become a
"launching pad" for attacks throughout the network. Regardless of whether you are a
user or system manager, you have a responsibility not only to protect your own
machine but also to be a responsible citizen of the network!
There are many misconceptions about vulnerabilities and how a person's system can be
attacked. One of the most common misconceptions is that if one's machine runs a
particular operating system (e.g., VMS) but the network to which that machine
connects runs different communications protocols (e.g., TCP/IP), the VMS machine
cannot be exploited through that network. The truth is that common communications
protocols and applications create common vulnerabilities. Thus, sites running TCP/IP
may be exploited regardless of the particular operating system run in machines
connecting to the TCP/IP network if there is a vulnerability in TCP/IP.
6.2 Types of Vulnerabilities
Needless to say, there are many types of security vulnerabilities in computing
systems. Poor passwords (see Section 5.5) comprise by far the largest class of
vulnerabilities. Dormant accounts and orphan machines (machines which are not
currently maintained) comprise another significant class of vulnerabilities. If
dormant accounts and orphan machines also have poor passwords, this constitutes an
even greater security problem. Holes in operating systems are another type of
vulnerability. Security holes in applications are another set of vulnerabilities.
For example, Stoll (1989) gives an interesting account of a hacker attack launched
through a vulnerability in a word processing program. The main focus of this chapter
is on operating system vulnerabilities because these vulnerabilities are so
frequently exploited by attackers. (Please note that the following descriptions of
vulnerabilities include only the outcomes of exploiting each vulnerability, rather
than the actual mechanics of exploiting each vulnerability. We take this approach to
avoid disseminating information that attackers might use.)
6.3 UNIX Vulnerabilities
As discussed previously, UNIX systems generally have numerous vulnerabilities.
Because there are many flavors of UNIX (e.g., Sun OS, BSD UNIX, ULTRIX, System V,
etc.) and usually many versions of each flavor, a particular UNIX vulnerability
seldom is universal. In fact, it takes careful investigation to discover exactly
which vulnerabilities are and are not present in any given UNIX system. We recommend
that, at a minimum, you become aware of the following vulnerabilities frequently
found in UNIX systems:
o set-uid (user id) scripts - if set-uid scripts are not set set up properly, an
intruder can obtain unauthorized root access
o anonymous ftp (file transport protocol) - some versions of UNIX have bugs or
have anonymous ftp set up incorrectly, which can allow unauthorized file
modifications (e.g., unauthorized modification of /etc/passwd)
o tftp (trivial file transport protocol) - some versions of UNIX have bugs in
tftp, or tftp may not be set up correctly, allowing an attacker to steal any
publicly readable file (including /etc/passwd)
o login (the program that logs a user into a system) - susceptible to trojan
horses
o fingerd - there are several vulnerabilities, some of which enable attackers to
obtain unauthorized root access. Intruders can also use fingerd to locate
user accounts to attack.
o sendmail (the program that delivers mail to the user) - new vulnerabilities in
this function seem to be discovered frequently. Some of the vulnerabilities
include allowing an attacker to corrupt non-root owned files, or, when sendmail
is used in connection with .rhosts, allowing unauthorized root access
o uudecode - vulnerabilities in this function allow an attacker to overwrite
files (including .rhosts)
o nis (network information system, formerly yp--yellow pages) - problems in this
function make multiple attacks within a cluster of machines easier
o nfs (network file system) - problems in nfs also make multiple attacks within
a cluster of machines easier
Remember, too, that in UNIX systems there are demo, user, and guest accounts that
may have no passwords or "Joe" passwords.
6.4 VM Vulnerabilities
VM is a relatively secure operating system, and the exploitable features in VM of
which we are aware are not severe threats to system and/or network security. Some
versions of VM have an option to allow the user name and password to be displayed in
clear text on the login line. This allows someone else in the same room as the user
to view the passwords entered during logins. Some versions of VM may flag a bad
userid without asking for a password. This enables an attacker to learn which
accounts are and are not viable to attack. Finally, older releases of VM have
several additional exploitable features, including echoed passwords as they are
entered and a default password on the DURMAINT account.
6.5 VMS Vulnerabilities
Exploitable features in VMS are, for the most part, configuration problems; VMS is
reasonably secure if configured properly. Default accounts such as the default
DECNET account in pre-5.0 version releases of VMS as well as SYSTEM and SHUTDOWN
accounts on some VMS systems present a problem. Applications such as INGRES, ORACLE
and mail running on VMS systems also have default accounts which, if unchanged, allow
an easy avenue of entry. The VMS phone object does not check authorizations before
allowing someone to write to another terminal. This utility can, therefore, be used
to trojan horse an account. (The phone object has also been used by DECNET worms to
write offensive messages to users.) The Task 0 object (which allows, among other
things, functions to run remotely ) may be configured to allow users with no account
on a machine to run applications. (Note: to misuse Task 0, an intruder must first
gain access to a system. It is debatable, therefore, whether Task 0 is, in and of
itself, the real problem.)
6.6 MVS Vulnerabilities
MVS systems are seldom attacked, probably because other operating systems such as
UNIX are considerably more popular and thus well known. However, the MVS operating
system is, according to many experts, very vulnerable to attack unless C2 features
are added (RACF). In addition, DSMOM provides attackers with sensitive information
from the authorized caller table. The encryption module, SYSL2PALIB (which does RACF
encryption), can easily be broken. Finally, problems with the PARMLIB and EXAMINE
functions within RACF need to be fixed in most MVS systems.
6.7 File Protections
File protections constitute a special set of security considerations. File
protections determine who may read, write or execute a file. Simple file protection
measures can prevent many opportunities for misusing a system! Publicly writeable
binaries and system directories allow an attacker to modify the system. Protections
should be set accordingly. Readable restricted system files allow an attacker to
discover other trusted computers or other privileged information. Writeable home
directories allow trojan horses to be planted.
6.8 Concluding Comments
The information presented in this chapter is not just some theory. Taking action on
the information in this chapter will probably save you considerable time,
frustration, embarrassment, and effort, including the effort to "pick up the pieces"
after a major hacker/cracker or worm attack on your system. At any given hour of any
day there are dozens of computing systems being attacked because people have not
learned about vulnerabilities or have not done anything about them. Learning of the
vulnerabilities in your operating system and applications, then patching them is the
key to avoiding catastrophe. The CIAC team is especially anxious to lend assistance
to help anyone in the DOE community who has a question about vulnerabilities, or who
needs help obtaining and/or installing a patch. The CIAC team also needs to learn as
rapidly as possible about any vulnerabilities you may discover so that we can start
working with vendors to close these vulnerabilities as quickly as possible.
Scenario For The "Big Fall"
7 - Incident Handling Tools
Throughout this document, it has been stressed that procedures are more important
than software. This does not, however, diminish the value of software when used as
part of an incident handling procedure. There is an increasing number of prevention
and incident handling tools available. In this section, some currently available
tools will be discussed, where to find them, and their usefulness.
7.1 Types of Tools Available
Currently available tools can aid in dealing with incidents at each stage of the
incident handling model outlined previously. These stages include:
o Preventing
o Detecting
o Containing
o Eradicating
o Recovering
o Following up
There are many different types of tools available. In general these fall into the
categories of software solutions, hardware solutions, and integrated products.
Software solutions are layered software products that do not require any additional
hardware to function. These would include additional passwords for authentication,
checksums for file integrity, etc. Hardware solutions are devices that attach to
your system or network to provide some security function without affecting your
software on the system. Examples of these are network monitors that snoop your
network, or printers that attack to a dial-in port to record traffic. Integrated
products are combinations of software and hardware on your system. Hand-held
authenticators or encryption boxes are examples of integrated products.
Aside from the types of security tools that you can add to a system, there are
systems that are more inherently secure than others. Often these systems are based
on a trusted operating system (TOS). These systems are formally proven to be secure
to a particular level. In the Department of Defense, these systems are rated
according to criteria outlined in a standardized document on computer security (the
Orange Book). For the DOE, no such document exists, but security considerations are
outlined in DOE Orders 5637.1 and 1360.2A.
TOSs are useful in a number of situations including dedicated network controllers,
data base or file servers, or human safety controllers. However, TOSs are not a
panacea. TOSs are not in widespread use because of a few serious drawbacks
including:
o It can take an extensive amount of time to certify a TOS
o Security is often gained at a restricted functionality
o The assumptions used in certification cannot be applied in some situations
o There is often a unique or archaic user interface
o The application base is too small to provide off-the-shelf solutions
Anti-virus software is a category all in itself. There are many good anti-virus
packages available (see the section on viruses for more details). These packages can
save many hours of recovery time, and have proven to be useful. The main
considerations for obtaining and using a virus tool are:
o Be careful of your source
o Run the most recent version
o Never entirely trust the virus software (procedures are more important than
software)
o Maintain a good backup policy
Encryption is a useful tool for computer security. There are many tradeoffs in using
encryption however. Be aware that encryption cannot be used to solve computer
security problems in general, but may only be used in particular situations such as
virus detection, communications, and authentication. Using software to perform the
encryption can be slow and something must be trusted to do the encryption--if that
something is corrupted, the entire system is corrupted. Dedicated hardware to
perform the encryption helps, but this may be expensive and difficult to integrate
into the system.
The remainder of this section will be devoted to a listing of tools available to aid
in computer security incident handling for multi-user systems. These tools are
categorized as either system security tools providing added security features to a
system, authentication tools that specifically provide additional authentication
support, and intrusion detection tools that provide detection and identification of a
system penetration.
7.2 System Security Tools
SPI (Security Profile Inspector)
This tool aids system managers in maintaining the security and integrity of UNIX and
VMS systems. It provides password checking, file integrity checks, and checks for
correct file permissions. The VMS version adds, in addition, checks for using
identifiers and for accessibility of files based on UIC, identifier, and privileged
access.
For information on SPI/UNIX or SPI/VMS, call Doug Mansur, LLNL, (415) 422-0896 or
(FTS) 532-0896, or send e-mail to mansur@tiger.llnl.gov
COPS (Computerized Oracle and Password System)
COPS is a UNIX security checking tool. It uses configuration information in special
files to check for the read/write permissions of all important files. It will also
check for superuser access and passwords, as well as other aspects of computer
security. For information, contact Dan Farmer (412) 268-7080, or send e-mail to
df@cert.sei.cmu.edu
SecurePak
SecurePak is a commercial package for VMS systems from DEMAX software. It will check
many security features on VMS systems, and provides a much nicer interface to the
authorize function. Contact DEMAX software for more details on this package.
Matt BishopÕs password program
This is a tool that will search for easily guessed passwords based on a dictionary
search. It also may replace the passwd function on UNIX systems to restrict the
initial selection of an easily guessed password. It contains a fast DES
implementation that will improve the performance of the password functions above the
standard UNIX implementations. Contact Bill Kramer, NASA Ames, (415) 604-4600, for
additional information on this package.
7.3 Authentication Tools
Kerberos
Developed within the Athena project at MIT, this is a UNIX tool (which has been
ported to other operating systems as well) to provide authentication in a distributed
environment. This tool's goals are to provide network authentication without
sending clear text passwords across the network, or storing them on the individual
hosts. Every connection may be authenticated using kerberos, and it is designed to
be used transparently with other network services. For additional information or to
obtain the tool, contact geer@athena.mit.edu or
info-kerberos@athena.mit.edu
DES Encryption and Secure nis
Both DES encryption and secure nis are provided with the Sun operating system. These
systems aid in protecting files with a user-defined key, and protecting network
communication by encrypting the information used in the distributed authentication
provided by dns (domain name service). For more information on how to use this tool
on Sun systems, see your Sun documentation.
7.4 Intrusion Detection Tools
Haystack
This is an intrusion detection tool that will run on an IBM PC to monitor Sperry-
UNISYS mainframe computers for intrusions. It was developed by Steve Smaha of
Haystack, Inc., under contract by the Air Force. For additional information, contact
Capt. Tim Grance, AFCSC, (512) 925-2386.
Wisdom and Sense
This is an intrusion detection tool that will run on a Sun computer to monitor a VMS
system. It will layer the appropriate software on the sun to monitor DECNET traffic
and determine if there is a deviation from normal operation. For information on this
tool, contact Hank Vaccaro, LANL (FTS) 843-3382.
CSM (Computer Security Monitor)
The CSM is a rule-based monitor that will detect penetrations based on statistical
analysis of normal usage patterns. In addition to the statistical analysis,
deterministic rules may also be applied to determine if a user is performing an
unauthorized function. The rules are system dependent, and have been developed for
Sun OS 4.0 and IBM MVS systems. Rules may be developed for other platforms as well,
since the CSM is designed to be operating system generic. For information, contact
Chip Hatfield, LLNL, (415) 422-8567 or (FTS) 532-8567.
Midas
Midas is an intrusion detection based on an expert system. The system runs on a
Symbolics Lisp machine, and is used to monitor a MULTICS system. It was developed by
the National Computer Security Center (NCSC), and is based on the IDES research into
user profiles and events. It is widely recognized as one of the best intrusion
detection systems available, and is likely to be ported to other systems (e.g., UNIX)
to assist other vendors in the certification process. For additional information on
how to obtain this product, call Eric Shellhouse at (301) 859-4513.
8 - Exercises and Scenarios
Chapter Two - Overview of Incident Handling
1. Certain stages of the six stages of responding to incidents might be more
important for some types of incidents than others. Explain why.
2. Which of the six stages is most likely to be overlooked? Why is it important to
not overlook this stage?
3. Suppose you were handed a disk and were told that it contained a new virus called
SPREAD, but the routine used by the virus to replicate itself had been removed.
a) would the malicious code left on the disk best be called a virus, worm, or
trojan horse? b) How would you analyze the code on the disk, and what precautions
would you take during this process?
4. Below is a list of symptoms of three types of incidents, virus infections, hacker
attacks, and worm attacks. For each symptom determine the type of incident with
which it is most closely associated by placing a check in the appropriate box.
For example, if you think that the first symptom, system crashes, is most
indicative of a virus infection, check the first box to the right of "system
crashes" (under "virus"). If you think that system crashes are most indicative of
a hacker attack, check the second box to the right of "system crashes" (under
"hacker"), instead.
Chapter Three - Responding to Viruses
1. Suppose that your personal computer's disk crashes every third boot. How could
you determine whether your machine has a virus?
2. a) How could you assure that your virus eradication tool is not itself infected?
b) How could you know that it eradicates the virus which has infected your
machine? c) How could you know that you have the latest version of this tool?
3. You have determined that your PC has been infected by "Disk Killer." Should you
turn your machine off immediately? Explain.
4. Given a virus that masks all interrupts into the operating system, how would you
write an anti-virus code to detect/eradicate this virus?
5. Can two or more viruses infect a single machine at one time? Explain.
6. While editing a classified file on a Macintosh you notice that the file is
infected by nVIR. What procedures should you follow to recover?
Chapter 4 - Responding to Worm Attacks
1. A user who accesses a mainframe from his Macintosh discovers that his account has
been penetrated by a worm. He immediately turns his Macintosh off and calls the
system manager. What advice should his system manager give him? Now the system
manager confirms that there is a worm and turns the attacked host off. What
advice would you give the system manager?
2. Suppose that there is a worm in a classified network. What additional actions
must be taken to deal with a worm that might not have to be taken in an
unclassified network?
3. Given the PS list (below), what are the suspicious processes? Would this indicate
a worm, hacker or virus?
Chapter Five - Responding to Hacker/Cracker Attacks (Scenarios)
1. A system programmer notices that at midnight each night, someone makes 25 attempts
to guess a username-password combination. What should the programmer do next?
What is your organization/site's procedure?
Suppose that the programmer decides to do nothing. Two weeks later, the password
guessing attempts continue. The programmer checks the log and finds that each
night the same username-password combination is being used. What should you do,
based on your procedures?
2. A system programmer gets a call reporting that a major underground cracker
newsletter is being distributed from the administrative machine at his center to
five thousand sites in the U.S. and Western Europe. What do your procedures say
he should do? What should you do?
3. A user calls in to report that he cannot login to his account at 3 a.m., Saturday.
The system staffer cannot login either. After rebooting to single user mode, he
finds that the password file is empty. What should be done?
By Monday morning your staff determines that a number of privileged file transfers
took place between this machine and a local university. What should be done now?
By Tuesday morning a copy of the stolen password file is found on the university
machine along with password files for a dozen other machines. What has happened?
4. You receive a call saying that a break-in to a Government laboratory occurred from
one of your center's machines. You are requested to provide accounting files to
help track down the attacker. Do you have a policy for helping others? What
should you do?
5. You hear reports of a computer virus that paints trains on CRTs. You login to a
machine at your center and find such a train on your screen. You look in the log
and find no notation of such a feature being added. You notice that five attempts
were made to install it, each exactly one hour apart. What should you do?
6. You notice that your computer connected to the Internet has been broken into. You
find that nothing is damaged. A high school student calls up and apologizes for
doing it. What should you do?
7. A reporter calls up asking about the breakin at your center. You haven't heard of
any such incident. Three days later you learn that there was an intrusion due to
a poorly chosen password on one account. What should you do?
8. A change in system binaries is detected. Thanks to your good prevention policy,
the binaries are changed back to the original. The next day the binaries are
changed again. This repeats itself for several weeks. What should you do?
Answers to Exercises and Scenarios
Chapter 2
1. There will be a wide range of acceptable answers. For example, detection is
extremely critical (and difficult) in many hacker/cracker attacks.
2. Follow-up. This stage provides lessons learned, justification of the incident
handling activity to management, etc.
3. a) The code would best be called a trojan horse, since it is malicious code that
is not self-replicating. b) The code should be run in an isolated, backed-up
machine and its symptoms should be recorded. Tools to monitor memory or
disassemble the code may be used. Precautions must be taken to isolate the code,
since there may be more than one method of replication.
4.
Chapter 3
1. There is no 100 percent guaranteed detection procedure. Some possibilities
include: 1) check file sizes against a write-protected backup (but remember, the
backup may be infected), 2) use a virus detection package, and 3) watch for
unusual activity, such as odd disk access or disks that do not exist, unusual
graphic displays, etc.
2. a) Run the tool on itself (but be sure to use a write-protected disk) or check the
tool against a trusted source. Some manufacturers have authentication tools to
verify their product. b) Use your detection procedures after using the tool. c)
Get the tool from a trusted source, or from the originator of the tool. You could
also read Virus-L, contact CIAC, or find a knowledgeable person.
3. No. In the case of disk killer, there is information stored on completion of the
virus that will aid in the recovery of the original files.
4. Many methods exist. The important thing to realize is that if you provide the
correct vector addresses in your program, the virus could intercept them and
substitute its own values. The correct values must be computed and compared to
the actual vectors to assure that the virus is not present. Also, care must be
taken to not use interrupt services in the program.
5. Yes. nVIR A and nVIR B (Macintosh viruses) may infect the same application on a
host, and, in this case, would create a new variant, nVIR C.
6. You should save the infected application on a WELL LABELED floppy, then re-format
the disk and re-install all your applications and data from a recent backup. Then
check for the virus again.
Chapter 4
1. Turning off the Macintosh is ineffective. A worm invades the host machine, not
terminals or terminal emulators used to access the host. Notifying the system
manager is an important action, however--users are one of the most important
"detection tools." The system manager's actions are good ones. There are many
things which now should be done, among which are: a) follow the site's reporting
procedures, c) call CIAC to report the attack and to obtain
immunization/eradication scripts, c) locate or check the latest backup, d)
disconnect the system from all networks, and e) bring the system up in a
restricted (i.e., single user) mode.
2. DOE Order 5637.1 does not specifically address the problem of a worm attack.
Actions depend on whether the worm has changed the accessibility of classified
information. We generally recommend that you start from a clean backup (assured
to be worm-free). If the worm has caused any unauthorized disclosure of
classified information, all disks on a system should be purged.
3. The ftp processes should be examined. This could be a hacker or a worm.
Chapter 5
1. The fact that the same username-password combination is used repeatedly suggests
that this is not an intrusion attempt.
2. In this case, eight weeks later the authorities called to inform that the
information in one of these newsletters was used to disable 911 in a major city
for five hours. (This is a true story.) Your procedures should require that
management should be notified of the type of information in this scenario.
3. A week later you find that your system initialization files have been altered
maliciously. Recovery will be complicated, but at a minimum, passwords for all
users should be changed on any systems with stolen passwords.
4. A week later you are given a list of machines at your site which have been
compromised. Once you authenticate the caller, determine whether the caller has a
need-to-know. If so, it is important to supply the needed information.
5. This is a "false alarm." Three days later you learn that the unusual graphic
display was put up by a system administrator locally who had heard nothing about
the virus scare or about your concern.
6. There is no outcome to this scenario. We have found, however, that persuading the
hacker to meet you in person (if possible), acquainting the hacker with the
problems he or she caused, and getting him/her to promise to quit this activity
and possibly to assist you in subsequent attacks is very worthwhile. In this
case, in which the hacker initiated contact and apologizes, your following through
with law enforcement agencies is not necessarily advisable unless there is reason
to believe that the hacker has damaged other machines or caused considerable
trouble elsewhere.
7. In this case there was a breakin due to a poorly chosen password. Do not
talk directly to the reporter. It might be good to have your public relations
office contact the reporter and find out how the reporter learned the information
related to you, however.
8. This is a potentially complicated situation. You need to attempt to rule out
plausible causes for this unusual system behavior other than the work of an
intruder. In this case, there was no intrusion.
References
Stoll, C. (1989) Tracking a spy through the maze of computer espionage: The cuckoo's
egg. New York: Doubleday.
Wood, P.H., & Kochan, S.G. (1985) UNIX system security. Hasbrouck Heights, NH:
Hayden.
RESPONDING TO COMPUTER
SECURITY INCIDENTS:
GUIDELINES FOR INCIDENT HANDLING
E. Eugene Schultz, Jr.
David S. Brown
Thomas A. Longstaff
University of California
Lawrence Livermore National Laboratory
July 23, 1990
1 Must use GateKeeper Aid, Disinfectant 2.0, or other software that specifically recognizes WDEF
to
eradicate this virus.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
