Coping with the Threat of Computer Security Incidents
A Primer from Prevention through Recovery
Russell L. Brand ?
June 8, 1990
Abstract
As computer security becomes a more important issue in
modern society, it begins to warrant a systematic
approach. The vast majority of the computer security
problems and the costs associated with them can be
prevented with simple inexpensive measures. The most
important and cost effective of these measures are
available in the prevention and planning phases. These
methods are presented followed by a simplified guide to
incident handling and recovery.
---------------------------
?Copyright ?c Russell L. Brand 1989, 1990 Permission to copy
granteddprovidede eachscopyfincludes attributionoand the pversion
information. This permission extends for one year minus one day
from June 8, 1990; past that point, the reader should obtain a
newer copy of the article as the information will be out of date.
Contents
1 Overview
2 Incident Avoidance
2.Passwords
2.1Joe's
2.1Same Passwords on Different Machines
2.1Readable Password Files
2.1Many faces of a person
2.1Automated Checks for Dumb Passwords
2.1Machine Generated Passwords
2.1The Sorrows of Special Purpose Hardware
2.1Is Writing Passwords Down that Bad?
2.1The Truth about Password Aging
2.1How do you change a password
2.Old Password Files
2.Dormant Accounts
2.3VMS
2.Default Accounts and Objects
2.4Unix
2.4VMS
2.4CMS
2.File Protections
2.Well Known Security Holes
2.New Security Holes
2.7CERT
2.7ZARDOZ
2.7CIAC
2.Excess Services
2.Search Paths
2.Routing
2.Humans
2.1Managers
2.1Secretaries
2.1Trojan Horses
2.1Wizards
2.1Funders
2.Group Accounts
2..rhosts and proxy logins
2.Debugging
2.Getting People Mad at You
3 Pre-Planning your Incident Handling
3.Goals
3.1Maintaining and restoring data
3.1Maintaining and restoring service
3.1Figuring how it happenned
3.1Avoiding the Future Incidents and Escalation
3.1Avoiding looking foolish
3.1.Finding out who did it
3.1Punishing the attackers
3.Backups
3.2Why We Need Back Ups
3.2How to form a Back Up Strategy that Works
3.Forming a Plan
3.Tools to have on hand
3.Sample Scenarios to Work on in Groups
4 Incident Handling
4.Basic Hints
4.1Panic Level
4.1Call Logs and Time Lines
4.1Accountability and Authority
4.1Audit Logs
4.1Timestamps
4.Basic Techniques
4.2Differencing
4.2Finding
4.2Snooping
4.2Tracking
4.2Psychology
4.Prosecution
4.Exercise
5 Recovering From Disasters
A Micro Computers
B VMS Script
C Highly Sensitive Environments
D Handling the Press
D.Spin Control
D.Time Control
D.Hero Making
D.Discouraging or Encouraging a Next Incident
D.Prosecution
D.No Comment
D.Honesty
E Object Code Protection
F The Joy of Broadcast
G Guest Accounts
G.Attack Difficulty Ratios
G.Individual Sponsors
G.The No Guest Policy
H Orange Book
I Acknowledgements
1 Overview
Since 1984, I have been periodically distracted from my
education, my research and from my personal life to help handle
computer emergencies. After presenting dozens of papers,
tutorials talks on computer security, Roger Anderson and George
Michale arranged for me to lead a one day intensive seminar on
the practical aspects of computer security in an unclassified
networked environment for IEEE Compcon. This primer was written
as a basic text for this type seminar and has been used for about
2 dozen of them in the past year , and is still in draft form.
The text is divided into four main sections with a number of
appendices. The first two major sections of this document
contain the material for the morning lecture. The two following
sections contain the afternoon lecture contain the afternoon's
material. The remaining appendices include material that is of
interest to those people who have to deal with other computer
security issues.
Since this primer is a direct and simple ``how to guide'' for
cost-effective solutions to computer security problems, it does
not contain as many stories and examples as my other tutorials.
Those readers interested in these stories or who are having
difficulty convincing people in their organization of the need
for computer security are referred to Attack of the Tiger Team,
when it becomes available. and those readers interested in
comprehensive list of computer security vulnerabilities should
contact the author regarding the Hackman project.
Suggestions, questions and other comments are always welcome.
Please send comments to primer@cert.sei.cmu.edu. I hope to
publish a this set of notes in a more complete form in the
future. When sending comments or questions, please mention that
you were reading version CERT 0.6 of June 8, 1990.
Russell L. Brand
brand@lll-crg.llnl.gov
1862 Euclid Ave, Suite 136
Berkeley, CA 94709
2 Incident Avoidance
``An ounce of prevention is worth a pound of cure.'' In computer
security this is an understatement by a greater factor than can
be easily be believed. Very little has historically been done to
prevent computer break-ins and I have been told by a number of
the country's top computer scientists that ``Computer Security is
a waste of time.'' The belief that security measures or
preventive medicine is a waste has led to giant expenditures to
repair damage to both computers and people respectively. Must of
my surprise, several system managers reviewing this document were
sure that even basic preventative measures would not be cost
effective as compared to repairing disasters after they occurred.
The vast majority of the security incidents are caused by one of
about a dozen well understood problems. By not making these
mistakes, you can prevent most of the problems from happening to
your systems and avoid untold hassles and losses. Almost every
site that I survey and almost every incident that did not involve
insiders was caused by one of these problems. In the most of the
insider cases, no amount of computer security would have helped
and these are in many ways demonstrated problems with physical
security or personnel policy rather than with computer security
per se.
Most of the security incidents are caused by ``attackers'' of
limited ability and resources. Because of this and because there
are so many easy targets, if you provide the most basic level of
protection, most of the attackers will break into some other site
instead of bothering yours. There are of course exceptional
cases. If you are believed to have highly sensitive information
or are on a ``hit list'' of one type or another, you may
encounter more dedicated attackers. Readers interested in more
comprehensive defensive strategies should consult the appendices.
Over all, prevention of a problem is about four orders of
magnitude cheaper than having to handling it in the average case.
Proper planning can reduce the cost of incident handling and
recovery and is discussed in the section on planning. In
addition to whatever other measures are taken, the greatest
incremental security improvement will be obtained be implementing
the simple measures described below.
2.1 Passwords
While ``good passwords'' is not a hot and sexy topic and will
never command the prestige of exploitable bugs in the operating
system itself, it is the single most important topic in incident
prevention. Doing everything else entirely correctly is almost
of no value unless you get this right!
2.1.1 Joe's
A ``Joe'' is an account where the username is the same as the
password. This makes the password both easy to remember and easy
to guess. It is the single most common cause of password
problems in the modern world.
In 1986, there was popular conjecture that every machine had a
Joe. There was fair amount of random testing done and in fact a
Joe was found on each and every machine tested. These included
machines that had password systems designed to prevent usernames
from being used as passwords.
This summer, while I was testing a series of sensitive systems,
where hundred of thousands of dollars were spent to remove
security holes including re-writing a fair fraction of the
operating system, there were Joes.
It is worthwhile to include a process in your system batching
file (cron on unix) to check for Joes explicitly. The most
common occurrences of Joes is the initial password that the
system administrators set for an account which has never been
changed. Often this initial password is set by the administrator
with the expectation the user will change it promptly. Often the
user doesn't know how to change it or in fact never logs in at
all. In the latter case a dormant account lies on the system
accomplishing nothing except wasting system resources and
increasing vulnerabilities.
2.1.2 Same Passwords on Different Machines
Many years ago when a computing center had a single mainframe the
issue of a user having the same password on multiple machines was
moot. As long the number of machines that a user accessed was
very small, it was reasonable to request that a person to use a
different password on each machine or set of machines. With a
modern workstation environment, it is no longer practical to
expect this from a user and a user is unlikely to comply if
asked. There are a number of simple compromise measures that can
and should be taken.
Among these measures is requesting that privileged users have
different passwords for their privileged accounts than for their
normal use account and for their accounts on machines at other
centers. If the latter is not the case, then anyone who gains
control of one of these ``other'' machines which you have no
control over, has gained privileged access to yours as well.
The basic question of when passwords should be the same is
actually a simple one. Passwords should be the same when the two
machines are (1) logically equivalent (as in a pool of
workstations), (2) ``trust each other'' to the extent that
compromising one would compromise the others in other ways, or
(3) are run by the same center with the same security measures.
Passwords should be different when the computers are (1) run by
different organizations, (2) have different levels of security or
(3) have different operating systems.
Lest this seems too strict, be assured that I have on several
occasions broken into machines by giving privileged users on the
target machines accounts on one of my own and exploiting their
use of the same password on both. Further, machines with
different operating systems are inherently vulnerable to
different ``programming bugs'' and hence by having the same
passwords on the two machines, each machine is open to the all
the bugs that could exist on either system.
It is interesting (but of little practical value) to note that an
attacker can gain a cryptographic advantage by having two
different encrypted strings for the same password. This would
happen when the user has the same password on two machines but it
has been encrypted with different salts. In principle, this
makes hostile decryption much easier. In practice, the attack
methods that are most often used do not exploit this.
The worst offenders of the ``shared password problem'' are
network maintenance people and teams. Often they want an account
on every local area net that they service, each with the same
password. That way they can examine network problems and such
without having to look up hundreds of passwords.
While the network maintainers are generally (but not always) good
about picking reasonable passwords and keeping them secret, if
any one machine that they are using has a readable password file
(discussed below) or is ever compromised, this password is itself
compromised and an attacker can gain unauthorized access to
hundreds or thousands of machines.
2.1.3 Readable Password Files
A readable password file is an accident waiting to happen. With
access to the encrypted password an attacker can guess passwords
at his leisure without you being able to tell that he is doing
so. Once he has a correct password, he can then access your
machine as that user. In the case of certain operating systems,
including older versions of VMS, there is a well know inversion
for the password encryption algorithm and hence the attacker
doesn't need to guess at all once he can read the password file.
Changing the encryption method to some other method that is also
publically known doesn't help this set of problems, even if the
crypto-system itself is much stronger. The weakness here is not
in the crypto-system but rather in the ease of making guesses.
It is vital to protect your password file from being read. There
are two parts to this. First you should prevent anonymous file
transfers from be able to remove a copy of the password file.
While this is generally very easy to do correctly, there is a
common mistake worth avoiding. Most file transfer facilities
allow you to restrict the part of the file system from which
unauthenticated transfers can be made. It is necessary to put a
partial password file in this subsection so that an anonymous
agent knows ``who it (itself) is''. Many sites have put complete
password files here defeating one of the most important purposes
of the restrictions. (Of course without this restriction ``World
Readable'' takes on a very literal meaning:::)
The second part of the solution is somewhat harder. This is to
prevent unprivileged users who are using the system from reading
the encrypted password from the password file. The reason that
this is difficult is that the password file has a great deal of
information that people and programs need in it other than the
passwords themselves. Some version of some operating systems
have privileged calls to handle the details of all this and hence
their utilities have already been written to allow protection of
the encrypted passwords.
Most of the current versions of Unix are not among of these
systems. Berkeley has distributed a set of patches to
incorporate this separation (called shadow passwords) and the
latest version of the SunOS has facilities for it. For those who
are using an operating system that does not yet have shadow
passwords and cannot use one of the new releases, a number of ad
hoc shadowing systems have been developed. One can install
shadow passwords by editing the binaries of /bin/login,
/bin/passwd and similar programs that actually need to use the
password fields and then modify /etc/vipw to work with both the
diminished and shadow password files.
Of course, since most of us use broadcast nets, there is a real
danger of passwords being seen as they go over the wire. This
class of problems is discussed in the the Joys of Broadcast
appendix and the Guests appendix.
Kerberos, developed at MIT's Athena project has an alternative
means of handling passwords. It allows one to remove all the
passwords from the normal use machines and to never have them
broadcasted in clear text. While Kerberos is vulnerable to a
number of interesting password guessing and cryptographic attacks
and currently has problems with multi-home machines (Hosts with
more than one IP address), it does provide the first practical
attempt and network security for a university environment.
An often overlooked issue is that of passwords for games. Many
multiplayer computer games, such as ``Xtrek'' and ``Empire''
require the user to supply a password to prevent users from
impersonating one another during the game. Generally these
passwords are stored by the game itself and are in principle
unrelated to the passwords that the operating system itself uses.
Unfortunately, these passwords are generally stored unencrypted
and some users use the same password as they do for logging into
the machine itself. Some games now explicitly warn the users not
use his login passwords. Perhaps these games will eventually
check that the password is indeed not the same as the login
password.
2.1.4 Many faces of a person
A single individual can have many different relationships to a
computer at different times. The system programmers are acting
as ``just users'' when they read their mail or play a computer
game. In many operating systems, a person gets all of his
privileges all of the time. While this is not true in Multics,
it is true in the default configuration of almost every other
operating system. Fortunately a computer doesn't know anything
about ``people'' and hence is perfectly happy to allow a single
person have several accounts with different passwords at
different privilege levels. This helps to prevent the
accidentally disclosure of a privileged password. In the case
where the privileged user has his unprivileged account having the
same password as his unprivileged account on other machines it
will at least be the case that his privileges are not compromised
when and if this other machine is compromised.
The one case where it is especially important to have separate
accounts or passwords for a single individual is for someone who
travels to give demos. One can be assured that his password will
be lost when he is giving a demo and something breaks. The most
common form of ``breakage'' is a problem with duplex of of delay.
It would nice if all that was lost was the demo password and for
the demo password to be of no use to an attacker.
2.1.5 Automated Checks for Dumb Passwords
Automated checks for dumb passwords come in three varieties. The
first is to routinely run a password cracker against the
encrypted passwords and notice what is caught. While this is a
good idea, it is currently used without either of the other two
mechanisms we will describe. Since it is computationally less
efficient than the others by about a factor of 50,000, it should
be used to supplement the others rather than be used exclusively.
Among its many virtues is that an automated checking system that
reads the encrypted passwords does not require having source for
the operating system or making modification an system
modifications.
The second method of preventing dumb password is to alter the
password changing facility so that it doesn't accept dumb
passwords. This has two big advantages over the first method.
The first of these is computational. The second is more
important. By preventing the user from selecting the poor
password to begin with, one doesn't need an administrative
procedure to get him to change it later. It can all happen
directly with no human intervention and no apparent
accountability. As a general rule, people are not happy about
passwords and really don't want to hear from another person that
they need to change their password yet again.
While this change does require a system modification, it can
often be done without source code by writing a pre-processor to
screen the passwords before the new password is passed to the
existing utilities. The weakness in this approach lies with the
users who are not required to use the new style of password
facility. As a result, one finds that facilities that use only
this method have good passwords for everyone except the system
staff and new users who have had their initial passwords set by
the system staff.
The third method is designed primarily to catch the bad passwords
that are entered in despite the use of the second method. Once
could check the ``dumbness'' of a password with each attempted
use. While this is computationally more expensive than the
second method, it generally catches everyone. Even the system
programmers tend to use the standard login utility. It has the
nice feature of locking out anyone that finds a way to circumvent
the second method. This generally requires a small amount of
system source and risks causing embarrassment to ``too clever''
system staff members.
In terms of dumb passwords, there are a number of ``attack
lists''. An attack list is a list of common passwords that an
attacker could use to try to login with. Several of these have
been published and more are constantly being formed. These lists
are used for the automated password guesser and they may also be
used directly in the second and third method described above.
With the second and third method one may also use criteria
including minimum length, use of non-alphabetic characters, etc.
Finally, information about the individual user found in standard
system files can be scanned to see if the user has incorporated
this information into his password.
2.1.6 Machine Generated Passwords
Most users hate machine generated passwords. Often they are
unrememberable and accompanied by a warning to ``Never write them
down'' which is a frustrating combination. (We will discuss the
the writing down of passwords later.) Machine generated
passwords come in four basic types
Gibberish. This is the most obvious approach to randomness.
Independently selected several characters from the set of
all printable characters. For a six character password,
this gives about 40 bits of randomness. It is very hard to
guess and perhaps even harder to remember.
Often a little bit of post processing is done on these
passwords as well as on the random syllables discussed
below. This post processing removes passwords that might
prove offensive to the user. When a potentially offensive
password is generated, the program simply tries again. The
user often behaves the same way and runs the randomizer over
and over again until a password that seems less random and
more memorable to him is selected. In principle, the clever
user could write a program that kept requesting new random
passwords until an English word was chosen for him; this
would take much too long to be practical.
Numbers. Numbers are a lot like letters. People don't try to
pronounce them and there are very few numbers that are
``offensive'' per se. An eight digit random number has
about 26 bits of randomness in it and is of comparable
strength to a 4 character random password chosen from the
unrestricted set of printable characters. (The amount of
randomness in a password is the log (base 2) of the number
of possible passwords if they were all equally likely to
occur.)
Eight digit numbers are hard to remember. Fortunately
``chunking'' them into groups (as 184---25---7546) makes
this less difficult than it would otherwise be.
Syllables. This is by far the most common method currently used.
The idea is to make non-words that are easy to remember
because they sound like words. A three syllable, eight
letter non-word often has about 24 bits of randomness in it
making it not quite as strong as an 8 bit number but
hopefully a little bit more memorable.
The principle here is good. In fact, this pseudo-word idea
should work very well. In practice it fails miserably
because the standard programs for generating these
pseudo-syllables are very poor. Eventually we may find a
good implementation of this and see a higher level of user
acceptance.
Pass Phrases. Pass phrases are the least common way to implement
machine generated passwords. The idea here is very simple.
Take 100 nouns, 100 verbs, 100 adjective and 100 adverbs.
Generate an eight digit random number. Consider it as four
2 digit random numbers and use that to pick one of each of
the above parts of speech. The user is then given a phrase
like ``Orange Cars Sleep Quickly.'' The words within each
list are uniquely determined by their first two characters.
The user may then type the phrase, the first few letters of
each word or the eight digit number.
The phrases are easy to remember, the system remains just as
secure if you publish the list of words and has about 26
bits of randomness. One can adapt the system down to three
words with 20 bits of randomness and still be sufficiently
safe for most applications.
I believe that machine generated passwords are generally a bad
solution to the password problem. If you must use them, I
strongly urge the use of pass-phrases over the other methods. In
any event, if your center is using machine generated passwords,
you should consider running an occasional sweep over the entire
user file system looking for scripts containing these passwords.
Proper selection of your password generation algorithm can make
this much easier than it sounds.
As with almost all password issues, the user of a single computer
center which gives him one machine generated password for access
to all the machines he will use will not have nearly the level of
difficulty as the user who uses computers at many centers and
might have to remember dozens or even hundreds of such passwords.
2.1.7 The Sorrows of Special Purpose Hardware
With the problems of broadcast networks and user selecting bad
passwords or rebelling at machine generated password, some
facilities have turned to special purpose hardware that generates
keys dynamically. Generally these devices look like small
calculators (or smart card) and when a user enters a short
password (often four digits) they give him a password that is
good for a single use. If the person wants to login again, he
must get a new password from his key-generator.
With a few exceptions, the technology of these devices works very
well. The exceptions include systems with bad time
synchronization, unreliable or fragile hardware or very short
generated keys. In at least one case the generated keys were so
short that it was faster to attack the machine by guessing the
password ``1111'' than by guessing at the user generated
passwords it replaced.
Despite the technology of these devices working well and the
installation generally being almost painless, there are two
serious problems with their use. The first is cost. Buying a
device for a user of large center can easily cost more than an
additional mainframe. The second problem is more serious. This
is one of user reluctance. Most users are unwilling to carry an
extra device and the people who are users of many centers are
even less willing to hold a dozen such devices and remember which
is which.
In one center, these devices were used only for privileged
accesses initiated from insecure locations. Only a handful of
them had to be made. (Being innovative, the center staff built
them from old programmable calculators.) They were used only by
the ``on call'' system programmer when handling emergencies and
provided some security without being to obtrusive.
2.1.8 Is Writing Passwords Down that Bad?
One of the first things that we were all told when we began using
timesharing is that one should never write down passwords. I
agree that the users should not record their passwords on-line.
There have been a large number of break-ins enable by a user
having a batch script that would include a clear-text password to
let them login to another machine.
On the other hand, how often has your wallet been stolen? I
believe that a password written down in wallet is probably not a
serious risk in comparison to other the problems including the
selection of ``dumb'' password that are easier to remember. In
classified systems, this is, of course, not permitted.
2.1.9 The Truth about Password Aging
Some facilities force users to change their passwords on a
regular basis. This has the beneficial side effect of removing
dormant accounts. It is also the case that it limits the utility
of a stolen password.
While these are good and worthwhile effects, most system
administrators believe that changing passwords on a regular basis
makes it harder for an attacker to guess them. In practice, for
an attacker that has gotten the crypt text of the password file,
he generally only needs a few hours to find the passwords of
interest and hence frequent changes do not increase the
difficulty of his task. For the attacker who is guessing without
a copy of the encrypt password, even changing the password every
minute would at most double the effort he would be required to
expend.
2.1.10 How do you change a password
Users should be told to change their passwords whenever they have
reason to expect that another person has learned their passwords
and after each use of an ``untrusted'' machine. Unfortunately
many users are neither told this, nor how to change the password.
Be sure both to tell you users how to change their passwords and
include these instructions in the on-line documentation in an
obvious place. Users should not be expected to realize the
password changing is (1) an option for directory maintenance
under TOPS-20 and many versions of CMS, (2) is spelled passwd
under unix or (3) is an option to set under VMS.
2.2 Old Password Files
It is often the case at sites running shadow password systems,
someone forgets to prevent the shadow password file from being
publically readable. While this is easy to prevent by having a
batch job that routinely revokes read permissions that were
accidently granted, there is an interesting variant of this
problem that is harder to prevent.
When password files are edited, some editors leave backup files
that are publically readable. In fact when a new system is
installed a password file is often created by extracting
information from the password files of many existing systems.
The collection of password files is all too often left publically
readable in some forgotten disk area where it is found by an
attacker weeks or months later. The attacker then uses this data
to break into a large number of machines.
2.3 Dormant Accounts
While requiring annual password changes does eventually remove
dormant accounts, it is worthwhile to try a more active approach
for their removal. The exact nature of this approach will vary
from center to center.
2.3.1 VMS
In VMS, the account expiration field is a good method of retiring
dormant accounts, but care should be taken as no advance notice
is given that an account is near expiration.
Also VMS security auditing makes the removal of expired users a
bad idea. Because one of the most common errors is typing the
password on the username line, DEC suppresses any invalid
username from the logs until a breaking attempt is detected. But
if the username is valid and the password wrong, the username is
logged.
2.4 Default Accounts and Objects
One of the joys of many operating systems is that they come
complete with pre-built accounts and other objects. Many
operating systems have enabled either accounts or prelogin
facilities that present security risks.
The standard ``accounts'' for an attacker to try on any system
include the following:
Open. A facility to automatically create new accounts. It is
often set by default to not require either a password or
system manager approval to create the new accounts.
Help. Sometimes the pre-login help is too helpful. It may
provide phone numbers or other information that you wouldn't
want to advertise to non-users.
Telnet. Or Terminal. An account designed to let someone just use
this machine as a stepping stone to get to another machine.
It is useful for hiding origins of an attack.
Guest. Many operating systems are shipped with guest accounts
enabled.
Demo. Not only are several operating systems shipped with a demo
account, but when installing some packages, a demo account
is automatically created. All too often the demo account
has write access to some of the system binaries (executable
files).
Games. Or Play. Often the password is Games when the account
name is Play. In some cases this account has the ability to
write to the Games directory allowing an attacker to not
only play games, and snoop around, but to also insert Trojan
horses at will.
Mail. Quite often a system is shipped with or is given an
unpassworded mail account so that people can report problems
(like their inability to login) without logging in. In
two-thirds of the systems that I have observed with such an
account, it was possible to break into the main system
through this account.
Often these default accounts are normal accounts with an
initialization file (.login, .profile, login.cmd, login.bat,
etc.) or alternate command line interpreter to make it do
something non-standard or restrict its action. These are
generally called, ``Captive Accounts'' or ``Turnkey Logins.''
Setting up a restricted login so that it stays restricted is very
hard. It should of course be very easy, but in most cases a
mistake is made.
Subjobs. It is often the case that a restricted account is set up
to only run a single application. This single application
program is invoked by a startup script or instead of the
standard command interpreter. Very often this program has
an option to spawn a subprocess.
In some cases this might be an arbitrary job (e. g. the
/spawn option to Mail in VMS or ``:!'' to vi in unix) or
might be limited to a small number of programs. In the
former case the problem is immediate, in the latter case, it
is often the case that one of these programs in turn allows
arbitrary spawning.
A carefully written subsystem will prevent this (and all
other such problems). Generally these subsystems are
created quickly rather than carefully.
Editors. Most editors are sufficiently powerfully that if the
restricted system can use an editor, a way can be found to
cause problems.
Full Filenames. Many restricted subsystems presume that by
resetting the set of places the command interpreter looks
for executable programs (called its ``search path'')
functionality can be restricted. In unix this might be done
by altering the Path variable or the logical names table in
VMS.
All too often the clever attacker is able to defeat this
plan by using the complete filename of the file of interest.
Sometimes non-standard names for the file are necessary to
circumvent a clever restriction program.
Removable Restriction Files. When a system relies on an
initialization file to provide protection, it is important
that this file cannot be altered or removed. If an
restricted application is able to write to its ``home
directory'' where these initialization files are kept it can
often free itself.
Non-standard Login. Some network access methods do not read or
respect the startup files. Among these are many file
transfer systems. I have often been able to gain privileged
access to a machine by using the the login and password from
a captive account with the file transfer facility that
didn't know that these accounts weren't ``normal.'' Many
file transfer facilities have methods for disabling the use
of selected accounts.
Interrupts. It is sad that a number of the captive accounts won't
withstand a single interrupt or suspend character. Try it
just to be sure.
Making sure that you have not made any of the above listed
mistakes is of course not sufficient for having a perfectly safe
system. Avoiding these mistakes, or avoiding the use of captive
accounts at all, is enough to discourage the vast majority of
attackers.
Each operating system for each vendor has some particular default
accounts that need to be disabled or otherwise protected.
2.4.1 Unix
Under unix there are a lot of possible default accounts since
there are so many different vendors. Below is a partial list of
the default accounts that I have successfully used in the past
that are not mentioned above.
Sysdiag. Or diag. This is used for doing hardware maintenance
and should have a password.
Root. Or Rootsh or rootcsh or toor. All to often shipped without
a password.
Sync. Used to protect the disks when doing an emergency shutdown.
This account should be restricted from file transfer and
other net uses.
Finger. Or Who or W or Date or Echo. All of these have
legitimate uses but need to be set up to be properly
captive.
Among the things that one should do with a new unix system is
grep :: /etc/passwd
to see what unpassworded accounts exist on the system. All of
these are worth special attention.
2.4.2 VMS
Since VMS is available from only one vendor, the default account
here are better known. On large systems, these appear with
standard well known passwords. On smaller systems, these
accounts appear with no passwords at all. With the exception of
Decnet, all have been eliminated on systems newer than version
4.6.
Decnet
System
Systest
Field
UETP
Many of the networking and mail delivery packages routinely added
to VMS systems also have well know password. In the past six
months these accounts have been commonly used to break into VMS
systems.
MMPONY
PLUTO
The password on all of these accounts should be reset when a new
system is obtained. There are many problems with the DECNET
account and the with the Task 0 object. System managers should
obtain one of the standard repair scripts to remove these
vulnerabilities.
2.4.3 CMS
It has been many years since I have seriously used CMS. At last
glance the default configuration seemed to include well know
passwords for two accounts.
rcsc
operator
2.5 File Protections
With file protections simple measures can avoid most problems.
Batch jobs should be run on a regular basis to check that the
protections are correct.
Writable Binaries and System Directories. The most common problem
with file protections is that some system binary or
directory is not protected. This allows the attacker to
modify the system. In this manner, an attacker will alter a
common program, often the directory listing program to
create a privileged account for them the next time that a
privileged user uses this command.
When possible the system binaries should be mounted
read-only. In any event a program should systematically
find and correct errors in the protection of system files.
``Public'' areas for unsupported executable should be
moderated and these executable should never be used by
privileged users and programs. System data files suffer
from similar vulnerabilities.
Readable Restricted System Files. Just as the encrypted passwords
need to be protected, the system has other data that is
worth protecting. Many computers have passwords and phone
numbers of other computers stored for future use. The most
common use of this type of information is for network mail
being transported via UUCP or protected DECNET. It is
difficult to rework these systems so that this information
would not be necessary and hence it must be protected. You
have an obligation to protect this data about your neighbors
just as they have a responsibility to protect similar data
that they have about you.
Home Dir's and Init Files Shouldn't Be Writable. Checking that
these directories and files can be written only by the owner
will prevent many careless errors. It is also worthwhile to
check that peoples mail archives are not publically
readable. Though this is not directly a security threat, it
is only one more line of code while writing the rest of
this.
In many versions of the common operating systems special
checks are placed in the command interpreters to prevent
them from using initialization files that were written by a
third party. In this case there are still at least two
types of interesting attacks. The first is to install a
Trojan horse in the person's home directory tree rather than
in the initialization file itself and the second is to
simple remove the initialization files themselves. Often
security weaknesses are remedied through the proper
initialization file and without these files the
vulnerabilities are re-introduced.
No Unexpected Publically Writable Files or Directories. There are
of course places and individual files that should be
publically writable but these are stable quantities and the
script can ignore them. In practice user seems to react
well to being told about files that they own that are
publically overwritable.
When Parents aren't Owners. While it is not unusual for someone
to have a link to a file outside of his directory structure,
it is unusual for there to be a file to be in his home
directory that is owned by someone else. Flagging this when
the link-count is ``1'' is worthwhile.
Automated scripts can find these errors before they are
exploited. In general a serious error of one of the types
described above is entered into a given cluster university system
every other week.
2.6 Well Known Security Holes
While hundreds of security holes exist in commonly used programs,
a very small number of these account for most of the problems.
Under modern version of VMS, most of them relate to either DECNET
or creating Mailboxes.
Under unix, a handful of programs account for most of the
problems. It is not that these bugs are any worse or easier to
exploit than the others, just that they are well known and
popular. The interested reader is referred to the Hackman
Project for a more complete listing.
Set-Uid Shell Scripts. You should not have any set-uid shell
scripts. If you have system source, you should consider
modifying chmod to prevent users from creating set-uid
programs.
FTP. The file transfer utilities has had a number of problems
both in terms of configuration management (remembering to
disallow accounts like ``sync'' from being used to transfer
files) and legitimate bugs. Patched version are available
for most systems.
Login on the Sun 386i and under Dec Ultrix 3.0, until a better
fix is available,
chmod 0100 /bin/login
to protect yourself from a serious security bug.
Sendmail. Probably the only program with as many security
problems as the yellowpages system itself. Again a patched
version should be obtained for your system.
TFTP. This program should be set to run as an unprivileged user
and/or chrooted.
Rwalld. This program needs to be set to run as an unprivileged
user.
Mkdir. Some versions of unix do not have an atomic kernel call to
make a directory and hence can leave the inodes in a ``bad''
state if it is interrupted at just the right moment. If
your system is one of these it is worthwhile to write a
short program that increases the job priority of a job while
it is making a directory so as to make it more difficult to
exploit this hole.
YP & NFS. Both present giant security holes. It is important to
arrange to get patches as soon as they become available for
these subsystems because we can expect more security
problems with them in the future. Sun has recently started
a computer security group that will help solve this set of
problems.
While the ambitious and dedicated system manager is encouraged to
fix all of the security problems that exist, fixing these few
will discourage most of the attackers.
Next To :: Coping With The Threat of Computer Security Incidents - A Primer from Prevention through Recovery - Part 2
Credits
-- UnKnown --
|