⟦9e4f42ccc⟧

TextFile

\section{Incident Avoidance}
%\subsection{Overview}

``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
\quant\ 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 \classified.

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
\planning. In addition to whatever other measures are taken, the
greatest incremental security improvement will be obtained be implementing the
simple measures described below.

\subsection{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 {\em most important\/} topic in incident
prevention. Doing everything else entirely correctly is almost of
{\em no value\/} unless you get this right!

\subsubsection{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
({\tt 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.

\subsubsection{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.

\subsubsection{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\dots)

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 {\em 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 {\tt /bin/login}, {\tt /bin/passwd} and similar programs that
actually need to
use the password fields and then modify {\tt /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 \broadcast\ and \guests.

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.

\subsubsection{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.

\subsubsection{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.

\subsubsection{Machine Generated Passwords}

Most users hate machine generated passwords. Often they are
unrememberable and accompanied by a warning to ``{\em 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

\begin{description}

\item[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.

\item[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.

\item[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.

\item[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.

\end{description}

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.

\subsubsection{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.

\subsubsection{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.

\subsubsection{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.

\subsubsection{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 {\tt passwd} under unix
or (3) is an option to {\tt set} under VMS.

\subsection{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.

\subsection{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.

\subsubsection{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.

\subsection{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:

\begin{description}
\item[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.
\item[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.

\item[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.
\item[Guest.] Many operating systems are shipped with guest
accounts enabled.
\item[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).
\item[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.
\item[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.
\end{description}

Often these default accounts are normal accounts with an initialization
file ({\tt .login}, {\tt .profile}, {\tt login.cmd}, {\tt 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.

\begin{description}
\item[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 {\tt /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.

\item[Editors.] Most editors are sufficiently powerfully that if the
restricted system can use an editor, a way can be found to cause
problems.

\item[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 {\tt 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.

\item[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.

\item[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.

\item[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.
\end{description}

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.

\subsubsection{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.

\begin{description}
\item[Sysdiag.] Or {\tt diag}. This is used for doing hardware maintenance
and should have a password.

\item[Root.] Or {\tt Rootsh} or {\tt rootcsh} or {\tt toor}. All to often shipped
without a password.
\item[Sync.] Used to protect the disks when doing an emergency
shutdown. This account should be restricted from file transfer and
other net uses.
\item[Finger.] Or {\tt Who} or {\tt W} or {\tt Date} or {\tt Echo}.
All of these have
legitimate uses but need to be set up to be properly captive.

\end{description}

Among the things that one should do with a new unix system is
\begin{quotation}
{\tt grep :: /etc/passwd }
\end{quotation}
to see what unpassworded accounts exist on the system. All of these
are worth special attention.

\subsubsection{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 {\tt Decnet}, all have been eliminated on
systems newer than version 4.6.
\begin{description}
\item[Decnet] \quad
\item[System] \quad
\item[Systest] \quad
\item[Field] \quad
\item[UETP] \quad
\end{description}

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.
\begin{description}
\item[MMPONY] \quad
\item[PLUTO] \quad
\end{description}
The password on all of these accounts should be reset when a new system is
obtained. There are many problems with the {\tt DECNET} account and the
with the {\tt Task 0} object. System managers should obtain one of the
standard repair scripts to remove these vulnerabilities.

\subsubsection{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.

\begin{description}
\item[rcsc] \quad
\item[operator] \quad
\end{description}

\subsection{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.

\begin{description}

\item[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 {\em
never\/} be used by privileged users and programs. System data files
suffer from similar vulnerabilities.

\item[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.

\item[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.

\item[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.

\item[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.

\end{description}

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.

\subsection{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.

\begin{description}

\item[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.

\item[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.

\item[Login] on the Sun 386i and under Dec Ultrix 3.0, until a better fix is available,
\begin{quotation}
chmod 0100 /bin/login
\end{quotation}
to protect yourself from a serious security bug.

\item[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.

\item[TFTP.] This program should be set to run as an unprivileged
user and/or chrooted.

\item[Rwalld.] This program needs to be set to run as an
unprivileged user.

\item[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.

\item[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.

\end{description}

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.

\subsection{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.

\subsubsection{CERT}
Cert is a DARPA sponsored group to help internet sites deal with
security problems. They may be contacted as {\tt cert@cert.sei.cmu.edu}.
They also maintain a 24 hour phone number for security problems at
(412) 268-7090.

\subsubsection{ZARDOZ}

Neil Gorsuch moderates a computer security discussion group. He may
be contacted as {\tt zardoz!security-request@uunet.UU.NET} \linebreak
or {\tt security-request@cpd.com}.

\subsubsection{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 {\tt ciac@tiger.llnl.gov}.

\subsection{Excess Services}

Every extra network service that a computer offers potentially poses
an additional security vulnerability. I am emphatically {\em 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 {\tt
rexecd} under unix, the risks are not immediately apparent and are
caused by unexpected interactions that do not include any bugs per se.

\subsection{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
{\tt ps~-e} on unix) can detect this problem.

\subsection{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.

% reword below
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.

\subsection{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.

\subsubsection{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.

\subsubsection{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.

\subsubsection{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.

\subsubsection{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.

\subsubsection{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.

\subsection{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.

\begin{enumerate}
\item You can't change the password easily. You have to find everyone in
the group to let them know.

\item If something Dumb happens you don't know who to talk to about it.

\item 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.

\end{enumerate}

Group accounts should {\em 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 {\tt .rhosts}.

\subsection{.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
{\tt hosts.equiv},
{\tt .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.

\begin{enumerate}
\item If you can impersonate a machine, you can gain access to other
machines without having to provide passwords or find bugs.

\item Once you get access to one account on one machine, you are
likely to be able to reach many other accounts on other machines.

\item If you gain control of a machine, you have gained access to all
the machines that trusts it.
\end{enumerate}

Various experiments have shown that by starting {\it 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.

\subsection{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.

\subsection{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.
%\subsection{checklist}

DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦9e4f42ccc⟧ TextFile

Derivation

TextFile