2.7 New Security Holes
New security holes are always being found. There are a number of
computer mailing lists and advisory groups the follow this.
Three groups of particular interest are CERT, ZARDOZ and CIAC.
2.7.1 CERT
Cert is a DARPA sponsored group to help internet sites deal with
security problems. They may be contacted as
cert@cert.sei.cmu.edu. They also maintain a 24 hour phone number
for security problems at (412) 268-7090.
2.7.2 ZARDOZ
Neil Gorsuch moderates a computer security discussion group. He
may be contacted as zardoz!security-request@uunet.UU.NET
or security-request@cpd.com.
2.7.3 CIAC
CIAC is the Department of Energy's Computer Incident Advisory
Capability team led by Gene Schultz. This team is interested in
discovering and eliminating security holes, exchanging security
tools, as well as other issues. Contact CIAC as
ciac@tiger.llnl.gov.
2.8 Excess Services
Every extra network service that a computer offers potentially
poses an additional security vulnerability. I am emphatically
not suggesting that we remove those services that the users are
using, I am encouraging the removal of services that are unused.
If you are not getting a benefit from a service, you should not
pay the price in terms of system overhead or security risk.
Sometimes, as with rexecd under unix, the risks are not
immediately apparent and are caused by unexpected interactions
that do not include any bugs per se.
2.9 Search Paths
If a user has set his search path to include the current
directory (``.'' on Unix), he will almost always eventually have
a serious problem. There are a number of security
vulnerabilities that this poses as well as logistical ones.
Searching through the all of the users initialization files
and/or through the process table (with ps -e on unix) can detect
this problem.
2.10 Routing
Routing can provide a cheap partial protection for a computer
center. There are some machines that don't need to talk to the
outside world at all. On others, one would might like to be able
to initiate contact outward but not have any real need to allow
others to contact this machine directly.
In an academic computer when administrative computers are placed
on same network as the student machines, limiting routing is
often a very good idea. One can set up the system such that the
users on administrative machines can use the resources of the
academic machines without placing them at significant risk of
attack by the student machines.
Ideally one would wish to place the machines that need to be
protected on their own local area net with active routers to
prevent an attacker from ``listening in'' on the broadcast net.
This type of an attack is becoming increasingly popular.
2.11 Humans
In almost all technological systems, the weakest link is the
human beings involved. Since the users, the installers and the
maintainers of the system are (in the average case) all humans,
this is a serious problem.
2.11.1 Managers
Managers, bosses, center directors and other respected people are
often given privileged accounts on a variety of machines.
Unfortunately, they often are not as familiar with the systems as
the programmers and system maintainers themselves. As a result,
they often are the targets of attack. Often they are so busy
that do not take the security precautions that others would take
and do not have the same level of technical knowledge. They are
given these privileges as a sign of respect. They often ignore
instructions to change passwords or file protections
The attackers rarely show this level of respect. They break into
the unprotected managerial account and use it as a vector to the
rest of the system or center. This leads to an embarrassing
situations beyond the break-in itself as the manager is made to
look personally incompetent and is sometimes accused of being
unfit for his position.
Prevent this type of situation form occurring by giving
privileges only to people that need and know how to use them.
2.11.2 Secretaries
Secretaries are often give their bosses passwords by their
bosses. When a secretary uses his bosses account, he has all the
privileges that his boss would have and generally does not have
the training or expertise to use them safely.
It is probably not possible to prevent bosses from giving their
passwords to their secretaries. Still one can reduce the need
for this by setting up groups correctly. One might consider
giving ``bosses'' two separate accounts one for routine use and
one for privileged access with a hope that they will only share
the former with their secretary.
2.11.3 Trojan Horses
Having an ``unsupported'' or ``public'' area on disk where users
place binaries for common use simplifies the placement of Trojan
horse programs. Having several areas for user maintained
binaries and a single user responsible for each reduces but does
not eliminate this problem.
2.11.4 Wizards
Wizards and system programmers often add their own security
problems. They are often the ones to create privileged programs
that are needed and then forgotten about without being disabled.
Thinking that an account doesn't need to be checked/audited
because it is owned by someone that should know better than to
make a silly mistake is a risky policy.
2.11.5 Funders
Funders are often giving accounts on the machines that they
``paid for.'' All to often these accounts are never used but not
disabled even though they are found to be dormant by the
procedures discussed above. Again, this is a mistake to be
avoided.
2.12 Group Accounts
A group account is one that is shared among several people in
such a way that one can't tell which of the people in the group
is responsible for a given action.
Those of you familiar with Hardin's ``The Tragedy of The Common''
will understand that this is a problem in any system computer or
otherwise. Part of the problem here is with passwords.
1. You can't change the password easily. You have to find
everyone in the group to let them know.
2. If something Dumb happens you don't know who to talk to
about it.
3. If someone shares the group password with another person,
you can never find out who did or who all the people who
knew the password were.
Group accounts should always be avoided. The administrative work
to set up several independent accounts is very small in
comparison to the extra effort in disaster recovery for not doing
so.
One must not only avoid the explicit group accounts, but also the
implicit ones. This is where an individual shares his password
with dozens of people or allows dozens, perhaps hundreds of them
to use his through proxy logins or .rhosts.
2.13 .rhosts and proxy logins
Just as some people trust each other, some accounts trust each
other and some machines trust each other. There are several
mechanism for setting up a trust relationship. Among these are
hosts.equiv, .rhosts, and proxy logins.
These mechanisms essentially allow a user to login from one
machine to another without a password. There are three basic
implications to this.
1. If you can impersonate a machine, you can gain access to
other machines without having to provide passwords or find
bugs.
2. Once you get access to one account on one machine, you are
likely to be able to reach many other accounts on other
machines.
3. If you gain control of a machine, you have gained access to
all the machines that trusts it.
Various experiments have shown that by starting almost anywhere
interesting, once one has control of one medium size machine, one
can gain access to tens of thousands of computers. In my most
recent experiment, starting from a medium size timesharing
system, I gained immediate access to 150 machines and surpassed
5000 distinct machines before completing the second recursion
step.
2.14 Debugging
About one third of the security holes that I have come across
depend on a debugging option being enabled. When installing
system software, always check that all the ``debugging'' options
that you are not using are disabled.
2.15 Getting People Mad at You
It is sad but true that a small number of sites have gotten
groups of hackers angry at them. In at least two cases, this was
because the hackers had found an interesting security hole, had
tried to contact the administrators of the center and were given
a hard time when they were seriously trying to help.
When one is given a ``tip'' from someone that won't identify
themselves about a security problem, it is generally worth
investigating. It is not worth trying to trick the informant
into giving his phone number to you. It almost never works, and
it is the ``type of dirty trick'' that will probably get people
mad at you and at the very least prevent you from getting early
warnings in the future.
3 Pre-Planning your Incident Handling
3.1 Goals
Despite your best plans to avoid incidents they may very well
occur. Proper planning can reduce their serverity, cost and
inconvenience levels. There are about half dozen different goals
that one can have while handling an incident.
1. Maintain and restore data.
2. Maintain and restore service.
3. Figure out how it happenned.
4. Avoid the future incidents and escalation.
5. Avoid looking foolish.
6. Find out who did it.
7. Punish the attackers.
The order shown above is what I believe the order of priorities
generally should be. Of course in a real situation there are
many reasons why this ordering might not be appropriate and we
will discuss the whens and why of changing our priorities in the
next section.
For any given site, one can expect that a standard goal
prioritization can be developed. This should be done in advance.
There is nothing so terrible as being alone in a cold machine
room at 4 on a Sunday morning trying to decide whether to shut
down the last hole to protect the system or try to get a phone
trace done to catch the attacker. It is similarly difficult to
decide in the middle of a disaster whether you should shut down a
system to protect the existing data or do everything you can to
continue to provide service.
Noone who is handling the technical side of an incident wants to
make these policy decisions without guidance in the middle of a
disaster. One can be sure that these decisions will be replayed
an re-analyzed by a dozen ``Monday Morning Quarterbacks'' who
will explain what should have been done could not be bothered to
make up a set of guidelines before.
Let us look at each of these goals in a little more detail.
3.1.1 Maintaining and restoring data
To me, the user data is of paramount importance. Anything else
is generally replacable. You can buy more disk drives, more
computers, more electrical power. If you lose the data, though a
security incident or otherwise, it is gone.
Of course, if the computer is controlling a physical device,
there may be more than just data at stake. For example, the most
important goal for the computer in Pacemaker is to get the next
pulse out on time.
In terms of the protection of user data, there is nothing that
can take the place of a good back-up strategy. During the week
that this chapter was written, three centers that I work with
suffered catastrophic data loss. Two of the three from air
conditioning problems, one from programmer error. At all three
centers, there were machines with irreplacable scientific data
that had never been backed up in their lives.
Many backup failures are caused by more subbtle problems than
these. Still it is instructive to note that many sites never
make a second copy of their data. This means than any problem
from a defective disk drive, to a water main break, to a typing
mistake when updating system software can spell disaster.
If the primary goal is that of maintaining and restoring data,
the first thing to do during an incident needs to be to check
when the most recent backup was completed. If it was not done
very recently, an immediate full system dump must be made and the
system must be shutdown until it is done. Of course, one can't
trust this dump as the attacker may have already modified the
system.
3.1.2 Maintaining and restoring service
Second to maintaining the data, maintaining service is important.
Users have probably come to rely on the computing center and will
not be pleased if they can't continue to use it as planned.
3.1.3 Figuring how it happenned
This is by far the most interesting part of the problem and in
practice seems to take precident over all of the others. It of
course strongly conflicts with the two preceeding goals.
By immediately making a complete copy of the system after the
attack, one can analyze it at one's leisure. This means that we
don't need to worry about normal use destroying evidence of about
the attacker re-entering to destroy evidence of what happenned.
Ultimately, one may never be able to determine how it happenned.
One may find several ways that ``could have happenned''
presenting a number of things to fix.
3.1.4 Avoiding the Future Incidents and Escalation
This needs to be an explicit goal and often is not realized until
much too late. To avoid future incidents one of course should
fix the problem that first occurred and remove any new security
vulnerabilities that were added either by the attackers or by the
system staff while trying to figure out what was going on.
Beyond this, one needs to prevent turning a casual attacker who
may not be caught into dedicate opponent, to prevent enticing
other attackers and to prevent others in one's organization and
related organizations from being forced to introduce restrictions
that would be neither popular nor helpful.
3.1.5 Avoiding looking foolish
Another real world consideration that I had not expected to
become an issue is one of image management. In practice, it is
important not to look foolish in the press, an issue that we will
discuss more fully in an appendix. Also it is important for the
appropriate people within the organization to be briefed on the
situation. It is embarrising to find out about an incident in
one's own organization from a reporter's phone call.
3.1.6 Finding out who did it
This goal is often over emphasized. There is definitely a value
in knowing who the attacker was so that one can debrief him and
discourage him from doing such things in the future.
In the average case, it effort to determine the attackers
identity than it is worth unless one plans to prosecute him.
3.1.7 Punishing the attackers
This merits of this goal have been seriously debated in the past
few years. As a practical matter it is very difficult to get
enough evidence to prosecuter someone and very few succesful
prosecutions. If this is a one of the goals, very careful record
keeping needs to be done at all times during the investigation,
and solving the problem will be slowed down as one waits for
phone traces and various court orders.
3.2 Backups
It should be clear that accomplishing most of the goals requires
having extra copies of the data that is stored on the system.
These extra copies are called ``Backups'' and generally stored on
magnetic tape.
Let us consider two aspects of keeping backup copies of your
data. First, we will look at why this important and what the
backups are used for and then we will examine the charateristics
of a good backup strategy.
3.2.1 Why We Need Back Ups
Good back ups are needed for four types of reasons. The first
three of these are not security related per se, though an
insufficeint back up strategy will lead to problems with these
first three as well.
If a site does not have a reliable back up system, when an
incident occurs, one must seriously consider immediate shutdown
of the system so as not to endanger the user data.
User Errors. Every once in a while, a user delete a file or
overwrites data and then realizes that he needs it back. In
some operating systems, ``undelete'' facilities or version
numbering is enough to protect him, if he notices his
mistake quickly enough. Sometimes he doesn't notice the
error for a long time, or deletes all of the versions, or
expunges them and then wants the data back.
If there is no backup system at all, the users data is just
plain lost. If there is a perfect backup system, he quickly
is able to recover from his mistake. If there is a poor
back up system, his data may be recovered in a corrupted
form or with incorrect permission set on it.
There have been cases where back up systems returned data
files to be publically writeable and obvious problems have
ensued from it. Perhaps as seriously, there are sites that
have stored all of the back up data in a publically readable
form, including the data that was protected by the
individual user.
System Staff Errors. Just as users make mistakes, staff members
do as well. In doing so, they may damage user files, system
files or both. Unless there is a copy of the current system
files, the staff must restore the system files from the
original distribution and then rebuild all of the site
specific changes. This is an error prone process and often
the site specific changes including removing unwanted
debugging features that pose security vulnerabilities.
Hardware/Software Failures. Hardware occassionally fails. If the
only copy of the data is on a disk that has become
unreadable it is lost. Software occasionally fails. Given
a serious enough error, it can make a disk unreadable.
Security Incidents. In this document, our main concern is with
security incidents. In determining what happen and
correcting it, backups are essential.
Basically, one would like to return every file to the state
before the incident except for those that are being modified
to prevent future incidents. Of course, to do this, one
needs a copy to restore from. Naively, one would think that
using that modification date would allow us to tell which
files need to be updated. This is of course not the case.
The clever attack will modify the system clock and/or the
timestamps on files to prevent this.
In many attacks, at one the following types of files are
modified.
? The system binary that controls logging in.
? The system authorization file lists the users and their
privileges.
? The system binary that controls one or more daemons.
? The accounting and auditing files.
? User's startup files and permission files.
? The system directory walking binary.
Now that we understand why we need back ups in order to recover
3.2.2 How to form a Back Up Strategy that Works
There are a few basic rules that provide for a good backup
strategy.
? Every file that one cares about must be included.
? The copies must be in non-volitile form. While having two
copies of each file, one on each of two separate disk drives
is good for protection from simple hardware failures, it is
not defense from an intelligent attacker that will modify
both copies, of from a clever system staffer who saves time
by modifying them both at once.
? Long cycles. It may take weeks or months to notice a
mistake. A system that reuses the same tape every week will
have destroyed the data before the error is noticed.
? Separate tapes. Overwriting the existing backup before
having the new one completed is an accident waiting to
happen.
? Verified backups. It is necessary to make sure that one can
read the tapes back in. One site with a programming bug in
its back up utility had a store room filled with unreadable
tapes!
3.3 Forming a Plan
While the first major section (avoidance) contained a lot of
standard solutions to standard problems, planning requires a
great deal more thought and consideration. A great deal of this
is list making.
Calls Lists. If there a system staffer suspects security incident
is happening right now, who he should call?
And if he gets no answer on that line?
What if the people are the call list are no longer employees
or have long since died?
What if it Christmas Day or Sunday morning?
Time--Distance. How long will it take for the people who are
called to arrive?
What should be done until they get there?
This a user notices. If a user notices something odd, who should
he tell?
How does he know this?
Threats and Tips. What should your staffers do if they receive a
threat or a tip-off about a breakin?
Press. What should a system staffer do when he receives a call
from the press asking about an incident that he, himself
doesn't know about?
What about when there is a real incident underway?
Shutting Down. Under what circumstances should the center be
shutdown or removed from the net?
Who can make this decision?
When should service be restored?
Prosecution. Under what circumstances do you plan to prosecute?
Timestamps. How can you tell that the timestamps have been
altered?
What should you do about it?
Would running NTP (the network time protocal) help?
Informing the Users. What do you tell the users about all this?
List Logistics. How often to you update the incident plan?
How does you system staff learn about it?
3.4 Tools to have on hand
File Differencing Tools
Netwatcher
Spying tools
Backup Tapes
Blanks Tapes
Notebooks
3.5 Sample Scenarios to Work on in Groups
In order to understand what goal priorities you have for you
center and as a general exercise in planning, let us consider a
number of sample problems. Each of these is a simplified version
of a real incident. What would be appropriate to do if a similar
thing happenned at your center? Each new paragraph indicates new
information that is received later.
? A system programmer notices that at midnight each night,
someone makes 25 attempts to guess a username--password
combination
Two weeks later, he reports that each night it is the same
username--password combination.
? 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 US and Western Europe.
Eight weeks later, the authorities call to inform you the
information in one of these newsletters was used to disable
``911'' in a major city for five hours.
? A user calls in to report that he can't login to his account
at 3 in the morning on a Saturday. The system staffer can't
login either. After rebooting to single user mode, he finds
that password file is empty.
By Monday morning, your staff determines that a number of
privileged file transfer took place between this machine and
a local university.
Tuesday morning a copy of the deleted password file is found
on the university machine along with password files for a
dozen other machines.
A week later you find that your system initialization files
had been altered in a hostile fashion.
? You receive a call saying that breakin to a government lab
occurred from one of your center's machines. You are
requested to provide accounting files to help trackdown the
attacker.
A week later you are given a list of machines at your site
that have been broken into.
? A user reports that the last login time/place on his account
aren't his.
Two weeks later you find that your username space isn't
unique and that unauthenticated logins are allowed between
machines based entirely on username.
? A guest account is suddenly using four CPU hours per day
when before it had just been used for mail reading.
You find that the extra CPU time has been going into
password cracking.
You find that the password file isn't one from your center.
You determine which center it is from.
? You hear reports of computer virus that paints trains on
CRT's.
You login to a machine at your center and find such a train
on your screen.
You look in the log and find not notation of such a feature
being added.
You notice that five attempts were made to install it within
an hour of each before the current one.
Three days later you learn that it was put up by a system
administrator locally who had heard nothing about the virus
scare or about your asking about it.
? You notice that your machine has been broken into.
You find that nothing is damaged.
A high school student calls up and apologizes for doing it.
? An entire disk partition of data is deleted. Mail is
bouncing bouncing because the mail utilities was on that
partition.
When you restore the partition, you find that a number of
system binaries have been changed. You also notice that the
system date is wrong. Off by 1900 years.
? A reporter calls up asking about the breakin at your center.
You haven't heard of any such breakin.
Three days later you learn that there was a breakin. The
center director had his wife's name as a password.
? A change in system binaries is detected.
The day that it is corrected they again are changed.
This repeats itself for some weeks.
4 Incident Handling
The difficulty of handling an incident is determined by several
factors. These include the level of preparation, the sensitivity
of the data, and the relative expertise levels of the attacker(s)
and the defender(s). Hopefully, preliminary work in terms of
gathering tools, having notification lists, policies and most
importantly backup tapes, will make the actual handling much
easier.
This section is divided into three parts. The first of these
deal with general principles. The second presents some
particular (simple) techniques that have proven useful in the
past. Finally, the third section presents a description of a
simulation exercise based a set of real attacks.
4.1 Basic Hints
There are a number of basic issues to understand when handling a
computer incident. Most of these issues are present in handling
most of these issues and techniques are relevant in a wide
variety of unusual and emergency situations.
4.1.1 Panic Level
It is critical to determine how much panic is appropriate. In
many cases, a problem is not noticed until well after it has
occurred and another hour or day will not make a difference.
4.1.2 Call Logs and Time Lines
All (or almost all) bad situations eventually come to an end. At
that point, and perhaps at earlier points, a list of actions and
especially communications is needed to figure out what happened.
4.1.3 Accountability and Authority
During an incident it is important to remind people what
decisions they are empowered to make and what types of decisions
that they are not. Even when this is explicitly discussed and
formulated in a contingency plan, people have a tendency to
exceed their authorities when they are convinced that they know
what should be done.
4.1.4 Audit Logs
Audit logs need to be copied to a safe place as quickly as
possible. It is often the case that an attacker returns to a
computer to destroy evidence that he had previously forgotten
about.
4.1.5 Timestamps
The second most powerful tool (second only to backup tapes) in an
incident handlers arsenal is timestamps. When in doubt as to
what to do, try to understand the sequencing of the events. This
is especially true when some of the actions will change the value
on the system clock.
4.2 Basic Techniques
There are five basic sets of techniques for understanding what
has happened.
4.2.1 Differencing
Differencing is that act of comparing the state of a part of the
computer system to the state that it was in previously. In some
cases we have compared every executable system file with the
corresponding file on the original distribution tape to find what
files the attacker may have modified. Checksums are often used
to decrease the cost of differencing. Sometimes people look only
for differences in the protection modes of the files.
4.2.2 Finding
Finding is generally cheaper than differencing. Finding is the
act of looking at a part of a computer system for files that have
been modified during a particular time or have some other
interesting property.
4.2.3 Snooping
Snooping is the act of placing monitors on a system to report the
future actions of an attacker. Often a scripting version of the
command line interpreter is used or a line printer or PC is
spliced in to the incoming serial line.
4.2.4 Tracking
Tracking is the use of system logs and other audit trails to try
to determine what an attacker has done. It is particularly
useful in determining what other machines might be involved in an
incident.
4.2.5 Psychology
A wide range of non-technical approaches have been employed over
the years with an even wider range of results. Among these
approaches have been leaving messages for the attacker to find,
starting talk links, calling local high school teachers, etc.
4.3 Prosecution
Prosecution has historically been very difficult. Less than a
year ago, the FBI advised me that it was essentially impossible
to succeed in a prosecution. More recently, FBI agent Dave
Icove, (icove@dockmaster.cnsc.mil, 703--640--1176) has assured me
that the FBI will be taking a more active role in the prosecution
of computer break-ins and has expressed interest in lending
assistance to investigation where prosecution is appropriate.
4.4 Exercise
The bulk of this class hour is reserved for an incident handling
simulation. A facility will be described. A consensus policy
for incident handling will be agreed upon and then the simulation
will begin.
During the simulation, the effects of the attackers actions and
those of third parties will be described. The participants can
choose actions and take measurements and will be informed of the
results of those actions and measurements. In a sufficiently
small working group that had several days, we would run a
software simulation; but as many of the actions take hours (ega
full system comparison to the original distribution), we will
proceed verbal in the short version of this workshop.
5 Recovering From Disasters
Incident recovery is the final portion of the of the incident
handling process. Like the other portions of incident handling,
it is not particularly difficult but is sufficiently intricate to
allow for many errors.
Telling everyone that is over. For a large incident, it is not
unusual to have contacted people at a dozen or more sites.
It is important to let everyone know that you are done and
to be sure to give your colleagues the information that they
need. It is also important that your staff knows that
things are over so that they can return to normal work.
Generally a lot of people need to thanked for the extra
hours and effort that they have contributed.
Removing all Tools. Many of the tools that were installed and
using during an incident need to removed from the system.
Some will interfere with performance. Others are worth
stealing by a clever attacker. Similarly a future attacker
that gets a chance to look at the tools will know a lot
about how you are going to track him. Often extra accounts
are added for handling the incident. These need to be
removed.
File and Service Restoration. Returning the file system to a
``known good state'' is often the most difficult part of
recovery. This is especially true with long incidents.
Reporting Requirements. Often, especially if law enforcement
agencies have become involved, a formal report will be
required.
History. After everything is over, a final reconstruction of the
events is appropriate. In this way, everyone on your staff
is telling the same story.
Future Prevention. It is important to make sure that all of the
vulnerabilities that were used in or created the incident
are secured.
Just after an incident, it is likely to be a good time to create
sensible policies where they have not existed in the past and to
request extra equipment or staffing to increase security.
Similarly, it is a logical time for someone else to demand
stricter (nonsensical) policies to promote security.
A Micro Computers
While the bulk of this book and class has concerned multi-user
computers on networks, micro computers are also worth some
attentions.
Basically there are four issues that cause concern.
Shared Disks. In many settings, micro computers are shared among
many users. Even if each user brings his own data, often
the system programs are shared on communal hard-disk,
network or library or floppies. This means that a single
error can damage the work of many people. Such errors might
include destruction of a system program, intentional or
accidental modification of a system program or entry of a
virus.
To combat this, systematic checking or reinstallation of
software from a known protected source is recommended. In
most shared facilities, refreshing the network, hard-disk or
floppy-library weekly should be considered. Shared floppies
should be write protected and the original copies of
programs should be kept under lock and key and used only to
make new copies.
Trusted server the provide read only access to the system
files have been successfully used in some universities. It
is absolute critical that these machines be used only as
servers.
Viruses. A number of computer viruses have been found for
micro-computers. Many experts consider this problem to be
practically solved for Macintoshes an soon to be solved for
IBM-style PC's.
Two basic types of anti-viral software are generally
available. The first type is installed into the operating
and watches for virus's trying to infect a machine.
Examples of this on the Mac include Semantic's SAM (Part 1),
Don Brown's vaccine and Chris Johnson's Gate Keeper.
The second type of anti-viral software scans the disk to
detect and correct infected programs. On the Mac, SAM (Part
2), H. G. C. Software's Virex, and John Norstab's Disinfinct
are commonly used disk scanners.
On the PC type of machines we find three types of virus.
The first of these is a boot sector virus that alters the
machine language start up code found on the diskette. The
second infects the command.com startup file and the third
alters the exe (machine language executable files).
Flu Shot Plus by Ross Greenberg is an example of a program
to deal with command.com & some exe virus. Novirus and
cooperatively built by Yale, Alemeda and Merit is one of the
boot track repair systems.
There are a number of electronic discussion groups that deal
with computer virus. On BITNET (and forwarded to other
networks), virus-l supports discussion about PC and Mac
virus, while valert is used to announce the discovery of new
ones. Compuserve's macpro serves as a forum to discuss
Macintosh viruses.
Network. The third is issue is the placement of single user
computers on networks. Since there is little or no
authentication on (or of) these machines, care must be taken
to not place sensitive files upon them in such a
configuration.
Reliability. Finally there is a reliability issue. Most single
user computers were never designed for life and time
critical applications. Before using such a computer in such
an application, expert advise should be sought.
In the use of single user computers, there are some basic issues
that need be considered and some simple advice that should be
given.
In the advice column, there are a few basic points.
1. Where practical, each user should have his own system disks
and hence be partially insulated from potential mistakes.
2. When people are sharing disks have an explicit check out
policy logging the users of each disk. Be sure to set the
write-protect them and teach the users how to write protect
there own system disks. (Most PC programs are sold on
write-protected disks, this is not true of most Macintosh
programs.
3. Keep a back up copy of all system programs and system
programs to allow for easy restoration of the system.
4. Write lock originals and keep them under lock and key for
emergency use only.
5. Have an explicit policy and teach users about software theft
and software ethics.
6. Teach users to back up their data. Just as with large
computers, the only real defense from disaster is
redundancy.
Even when the computer center is not providing the machines
themselves, it should generally help to teach users about
backups, write protection, software ethics and related issues.
Most PC users do not realize that they are their own system
managers and must take the responsibility of care for their
systems or risk the consequences.
B VMS Script
This script is courtesy of Kevin Oberman of Lawrence Livermore
National Labs. It is used on DEC VMS systems to close a number
of the standard created by the normal installation of DECNET.
Rather than typing this in by hand, please request one by
electronic mail. This DCL script is provided for reference
purposes only and is not guaranteed or warranted in any way.
$ Type SYS$INPUT
countpandedure changes the password for the default DECnet ac-
sets up a new account for FAL activity. It prevents unautho-
rized users from making use of the default DECnet account for any pur-
pose except file transfer.
This procedure assumes a default DECnet account named DECNET us-
ing a directory on SYS$SYSROOT. If this is not the case on this sys-
tem, do readypinceed! It will use UIC [375,375]. If this UIC is al-
use, do not continue.
$ Read/End=Cleanup/Prompt="Continue [N]: " SYS$COMMAND OK
$ If .NOT. OK Then Exit
$ Say := "Write SYS$OUTPUT"
$ Current_Default = F$Environment("DEFAULT")
$ Has_Privs = F$Priv("CMKRNL,OPER,SYSPRV")
$ If Has_Privs Then GoTo Privs_OK
$ Say "This procedure requires CMKRNL, OPER, and SYSPRV."
$ Exit
$POnvControl_Y Then GoTo Cleanup
$ On Error Then GoTo Cleanup
$ Set Terminal/NoEcho
$ Read/End=Cleanup/Prompt="Please enter new default DECnet pass-
word: " -
SYS$Command DN_Password
$ Say " "
$ If F$Length(DN_Password) .GT. 7 Then GoTo DN_Password_OK
$ Say "Minimum password length is 8 characters"
$ GoTo Privs_OK
$DN_Password_OK:
$ Sayd"E"d=Cleanup/Prompt="Enter new FAL password: " SYS$COMMAND FAL_Password
$ If F$Length(FAL_Password) .GT. 7 Then GoTo FAL_Password_OK
$ Say "Minimum password length is 8 characters"
$ GoTo DN_Password_OK
$FAL_Password_OK:
$ Set Terminal/Echo
$ Type SYS$INPUT
The FAL account requires a disk quota. This quota should be large
enough to accomodate the the files typically loaded into this account.
formldefaultqouta be exhausted, the system will fail to per-
DECnet file transfers.
It is also advisable to clear old files from the direc-
tory on a daily
basis.
$ If .NOT. F$GetSYI("CLUSTER_MEMBER") Then GoTo Not_Cluster
$ Say "This system is a cluster member.
$ Read/Prom="Has this procedure already been run on another clus-
ter member: "-
$ IfSClusterCTheneGoTo No_Create
$Not_Cluster:
$ Read/End=Cleanup -
/Prompt="Disk quota for FAL account (0 if quotas not en-
abled): " -
SYS$COMMAND Quota
$ If F$Type(Quota) .EQS. "INTEGER" Then GoTo Set_Quota
$ Say "Diskquota must be an integer"
$ GoTo FAL_Password_OK
$Set_Quota:
$ Say "Setting up new FAL account."
$ Set NoOnult SYS$SYSTEM
$ UAF := "$Authorize"
$ UAF Copy DECNET FAL/Password='FAL_Password'/UIC=[375,375]/Directory=[FAL]
$ Create/Directory SYS$SYSROOT:[FAL]/Owner=[FAL]
$No_Create:
$ NCP := "$NCP"
$ NCP Define Object FAL USER FAL Password 'FAL_Password'
$ NCP Set Object FAL USER FAL Password 'FAL_Password'
$ If (Quota .eq. 0) .OR. Cluster Then GoTo NO_QUOTA
$ Say "Entering disk quota for FAL account.
$ Set Default SYS$SYSTEM
$ Open/WritetQuota"SET_QUOTA'PID'.COM
$ Write Quota "$ Run SYS$SYSTEM:DISKQUOTA"
$ Write Quota "Add FAL/Perm=''Quota'"
$ Close Quota
$ @SET_QUOTA'PID'
$ Delete SET_QUOTA'PID'.COM;
$No_Quota:
$ Say "Resetting default DECNET account password"
$ NCP Define Executor Nonpriv Password 'DN_Password'
$ NCP Set Executor Nonpriv Password 'DN_Password'
$ UAF Modify DECNET/Password='DN_Password'
$Cleanup:
$ Set Default 'Current_Default'
$ Set Terminal/Echo
$ Exit
C Highly Sensitive Environments
An computing environment should be considered highly sensitive
when it is potentially profitable to covert the data or when
great inconvenience and losses could result from errors produced
there. In particular, you should consider you site sensitive if
any of the following conditions apply:
1. You process data that the government considers sensitive.
2. You process financial transactions such that a single
transaction can exceed $25,000.00 or the total transactions
exceed 2.5 Million dollars.
3. You process data whose time of release is tightly controlled
and whose early release could give significant financial
advantage.
4. Your function is life critical.
5. Your organization has enemies that have a history of
``terrorism'' or violent protests.
6. Your data contains trade secrete information that would be
of direct value to a competitor.
Essentially money is more directly valuable than secrets and a
``vilian'' can potentially steal more from one successful attack
on one financial institution than he will ever be able to get
selling state secrets for decades. There is significant concern
that the electrical utility companies and and bank conducting
electronic funds transfer will be targets of terrorists in thee
next decade.
For centers the must support sensitive processing it is strongly
advised to completely separate the facilities for processing this
data from those facilities used to process ordinary data and to
allow absolutely no connection from the sensitive processing
systems to the outside world. There is No substitute for
physical security and proper separation will require an attacker
to compromise physical security in order to penetrate the system.
Techniques for coping with the remaining ``insider threat'' are
beyond the scope of this tutorial.
In analysis of computing in sensitive environments, there are two
different security goals. The first is that of protecting the
system. All of the advice in this booklet should be considered
as a first step towards that goal. The second goal is the
protection of job or ``Technical Compliance.'' This is is the
goal of showing that all of the regulations have been followed
and that protecting the system has been done with ``due
diligence.''
It is important to realize that these two security goals are
separate and potentially conflicting. It may be necessary to
work towards the latter the goal and that is often more a legal
and bookkeeping question than a technical one. It is also beyond
the scope of this work.
D Handling the Press
Often media inquiries can absorb more time than all of the others
issues in incident handling combined. It is important to
understand this and to use your public affairs office if it
exists. In the excitement, people, especially those who are not
experience speakers will often forget that they are not empowered
to speak for the center and that nothing is ever really said,
``Off the record.''
D.1 Spin Control
The phrase ``Spin Control'' was first used in political circles.
It refers to altering the perceptions about an incident rather
than the delaying with the facts of the incident themselves.
Consider the two statements.
1. To keep our machines safe, we decided to disconnect them
from the network.
2. We were forced to shut down our network connections to
prevent damage to our machines.
I have found that the giving the press a state like the former
tends to produce a laudatory piece about one's staff while a
statement like the latter, produces an embarrassing piece. The
two statements are of course essentially identical.
Your public affairs group is probably familiar with these issues
and can help you form press statements
D.2 Time Control
With a sufficiently large incident, the media attention can
absorb almost unbounded amounts of time. The press will often
call employees at home. It is important the staff that are
solving a problem understand that the solving the incident is
more important that dealing with the press. At the very least
insist that all press representatives go through the public
affairs often so that the standard questions can be easily and
time-efficiently be answered.
D.3 Hero Making
The press likes to find outstanding heroes and villains. As a
result, the media will tend to make one of your staff members
into a hero if at all possible from them to do so. It is more
likely than not that the Hero will not be the person who has
worked the hardest or the longest.
D.4 Discouraging or Encouraging a Next Incident
The attention that an incident receives greatly affect the
likelihood of future incidents at that particular site. It
probably also influences the decision process or potential future
crackers in the community at large. Claiming that your site is
invulnerable is an invitation to a future incident. Giving the
media step by step instructions on how to break in to a computer
is also not a wonderful idea.
I (personally) suggest stressing the hard work of your staff and
the inconvenience to the legitimate users and staff members. To
the extent practical portray the cracker as inconsiderate and
immature and try to avoid making him seem brilliant at one
extreme or the attack seem very simple at the other.
D.5 Prosecution
If you considering prosecution, you need to consult with your
legal counsel and law enforcement official for advise on press
handling.
D.6 No Comment
One common strategy for avoiding (or at least bounding) time loss
with the press is to simply decline to comment on the situation
at all. IF you are going to adopt this approach, your public
affairs office can advise you on techniques to use. It is
important to tell everyone who is involved in the incident that
they should not discuss the situation; otherwise people will leak
things accidently. Also, without correct information from your
center, the press may print many inaccurate things that represent
their best guesses.
D.7 Honesty
I recommend against trying to mislead the press. It is hard to
keep a secret forever and when and if the press finds that you
have lied to them, the negative coverage that you may receive
will probably far exceed the scope of the actual incident.
E Object Code Protection
To keep object code safe from human attackers and virus, a
variety of techniques may be employed.
Checksums. Saving the checksums of each of the system files in a
protected area an periodically comparing the stored checksum
with those computed from the file's current contents is a
common and moderately effective way to detect the alteration
of system files.
Source Comparisons. Rather than just using a checksum the
complete files may be compared against a known set of
sources. This requires a greater storage commitment.
File Properties. Rather the computing a checksum, some facility
store certain attributes of files. Among these are the
length and location on the physical disk. While these
characteristics are easy to preserve, the naive attacker may
not know that they are important.
Read-Only Devices. Where practical, the system sources should be
stored on a device that does not permit writing. On many
system disk partitions may be mounted as ``Read-Only.''
Dates. On many systems the last modification date of each file is
stored and recent modifications of system files are reported
to the system administrator.
Refresh. Some system automatically re-install system software
onto there machines on a regular basis. Users of TRACK
often do this daily to assure that systems have not be
corrupted.
F The Joy of Broadcast
The majority of the local area nets (LAN's) use a system called
broadcast. It is somewhat like screaming in a crowded room.
Each person tends to try to ignore messages that weren't meant
for them.
In this type of environment, eaves-dropping is undetectable.
Often passwords are sent unencrypted between machines. Such
passwords are fair game to an attacker.
Various cryptographic solutions including digital signature and
one time keys have been used to combat this problem. Kerberos,
developed at the MIT Athena project is available without cost and
presents one of the few promising potential solutions to the
broadcast problem.
G Guest Accounts
The computer center guest policy is among the most hotly debated
topics at many computer centers. From a security standpoint, it
should be obvious that an attacker who has access to a guest
account can break into a computer facility more easily.
G.1 Attack Difficulty Ratios
Basically it is a factor of ten easier to break into a machine
where you can easily get as far as a login prompt that one where
you can't. Being able to reach the machine through a standard
networking discipline and open connections to the daemons is
worth another order of magnitude. Access to a machine that is
run by the same group is worth another factor of three and access
to a machine on the same LAN would grant a factor of three beyond
that. Having a guest account on the target machine makes the
attack still another order of magnitude easier.
Essentially, having a guest account on the target simplifies an
attack at least a thousand fold from having to start cold.
G.2 Individual Sponsors
I strongly suggest requiring each guest to have an individual
staff sponsor who takes responsibility for the actions of his
guest.
G.3 The No Guest Policy
In centers that prohibit guests, staff members often share their
passwords with their guests. Since these are generally
privileged accounts, this is a significant danger.
H Orange Book
You have doubtlessly by now heard of the ``Orange Book'' and
perhaps of the whole rainbow series.
Much of the ``Orange Book'' discusses discretionary and mandatory
protection mechanism and security labeling. Another section
deals with ``covert channels'' for data to leak out. While most
of these issues are not important in a university, the ideas of
protecting password files (even when encrypted), individual
accountability of users and password aging are worth implementing
in an unclassified environment.
I Acknowledgements
-- Help of a lot of people. -- copies were sent out to 48 people
for peer review
Jerry Carlin. For examples from his training course.
Joe Carlson. For help with spelling and grammar.
James Ellis. For help with organization.
Alan Fedeli.
Paul Holbrook. For help getting this document distributed.
David Muir. For help with spelling, grammar and comments about
computer games.
Kevin Oberman. For help with VMS issues, spelling and grammar.
Mike Odawa. For help with the microcomputers section.
Credits
-- UnKnown --
|