| More breakin problems at Stanford.
Return-Path: <@MARLBORO.DEC.COM,@SU-SCORE.ARPA,@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from MARLBORO.DEC.COM by TOPS20.DEC.COM with TCP; Tue 23 Sep 86 17:44:08-EDT
Received: from SU-SCORE.ARPA by MARLBORO.DEC.COM with TCP; Tue 23 Sep 86 17:46:08-EDT
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Sep 86 12:38:40-PDT
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 23 Sep 86 12:32:22-PDT
Date: Tue 23 Sep 86 12:04:20-PDT
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
Subject: Security problems
To: TOPS-20@Score.Stanford.EDU
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12241284545.7.MRC@PANDA>
[Note: The following message deals with a series of computer
breakins at Stanford's Unix systems, but some of the lessons
learned are quite apropos to TOPS-20 and VMS as well. I am
passing this on to the TOPS-20 list, since many of you have
multiple systems. -- MRC]
Lessons learned from a recent rash of Unix computer breakins
Introduction
A number of Unix computers in the San Francisco area have
recently been plagued with breakins by reasonably talented
intruders. An analysis of the breakins (verified by a telephone
conversation with the intruders!) show that the networking
philosophy offered by Berkeley Unix, combined with the human
nature of systems programmers, creates an environment in which
breakins are more likely, and in which the consequences of
breakins are more dire than they need to be.
People who study the physical security of buildings and military
bases believe that human frailty is much more likely than
technology to be at fault when physical breakins occur. It is
often easier to make friends with the guard, or to notice that he
likes to watch the Benny Hill show on TV and then wait for that
show to come on, than to try to climb fences or outwit burglar
alarms.
Summary of Berkeley Unix networking mechanism:
The user-level networking features are built around the
principles of "remote execution" and "trusted host". For example,
if you want to copy a file from computer A to computer B, you
type the command
rcp A:file B:file
If you want to copy the file /tmp/xyz from the computer that you
are now using over to computer C where it will be called
/usr/spool/breakin, you type the command
rcp /tmp/xyz C:/usr/spool/breakin
The decision of whether or not to permit these copy commands is
based on "permission" files that are stored on computers A, B,
and C. The first command to copy from A to B will only work if
you have an account on both of those computers, and the
permission file stored in your directory on both of those
computers authorizes this kind of remote access.
Each "permission file" contains a list of computer names and user
login names. If the line "score.stanford.edu reid" is in the
permission file on computer "B", it means that user "reid" on
computer "score.stanford.edu" is permitted to perform remote
operations such as rcp, in or out, with the same access
privileges that user "reid" has on computer B.
How the breakins happened.
One of the Stanford campus computers, used primarily as a mail
gateway between Unix and IBM computers on campus, had a guest
account with user id "guest" and password "guest". The intruder
somehow got his hands on this account and guessed the password.
There are a number of well-known security holes in early releases
of Berkeley Unix, many of which are fixed in later releases.
Because this computer is used as a mail gateway, there was no
particular incentive to keep it constantly up to date with the
latest and greatest system release, so it was running an older version
of the system. The intruder instantly cracked "root" on that
computer, using the age-old trojan horse trick. (He had noticed
that the guest account happened to have write permission into a
certain scratch directory, and he had noticed that under certain
circumstances, privileged jobs could be tricked into executing
versions of programs out of that scratch directory instead of out
of the normal system directories).
Once the intruder cracked "root" on this computer, he was able to
assume the login identity of everybody who had an account on that
computer. In particular, he was able to pretend to be user "x" or
user "y", and in that guise ask for a remote login on other
computers. Sooner or later he found a [user,remote-computer] pair
for which there was a permission file on the other end granting
access, and now he was logged on to another computer. Using the
same kind of trojan horse tricks, he was able to break into root
on the new computer, and repeat the process iteratively.
In most cases the intruder left trojan-horse traps behind on
every computer that he broke into, and in most cases he created
login accounts for himself on the computers that he broke into.
Because no records were kept, it is difficult to tell exactly how
many machines were penetrated, but the number could be as high as
30 to 60 on the Stanford campus alone. An intruder using a
similar modus operandi has been reported at other installations.
How "human nature" contributed to the problem
The three technological entry points that made this intrusion
possible were:
* The large number of permission files, with entirely
too many permissions stored in them, found all over the campus
computers (and, for that matter, all over the ARPAnet).
* The presence of system directories in which users have write
permission.
* Very sloppy and undisciplined use of search paths in privileged
programs and superuser shell scripts.
Permissions: Berkeley networking mechanism encourages carelessness.
The Berkeley networking mechanism is very very convenient. I use
it all the time. You want to move a file from one place to
another? just type "rcp" and it's there. Very fast and very
efficient, and quite transparent. But sometimes I need to move a
file to a machine that I don't normally use. I'll log on to that
machine, quickly create a temporary permission file that lets me
copy a file to that machine, then break back to my source machine
and type the copy command. However, until I'm quite certain that
I am done moving files, I don't want to delete my permission file
from the remote end or edit that entry out of it. Most of us use
display editors, and oftentimes these file copies are made to
remote machines on which the display editors don't always work
quite the way we want them to, so there is a large nuisance
factor in running the text editor on the remote end. Therefore
the effort in removing one entry from a permission file--by
running the text editor and editing it out--is high enough that
people don't do it as often as they should. And they don't want
to *delete* the permission file, because it contains other
entries that are still valid. So, more often than not, the
permission files on rarely-used remote computers end up with
extraneous permissions in them that were installed for a
one-time-only operation. Since the Berkeley networking commands
have no means of prompting for a password or asking for the name
of a temporary permission file, everybody just edits things into
the permanent permission file. And then, of course, they forget
to take it out when they are done.
Write permission in system directories permits trojan horse attacks.
All software development is always behind schedule, and
programmers are forever looking for ways to do things faster. One
convenient trick for reducing the pain of releasing new versions
of some program is to have a directory such as /usr/local/bin or
/usr/stanford/bin or /usr/new in which new or locally-written
versions of programs are kept, and asking users to put that
directory on their search paths. The systems programmers then
give themselves write access to that directory, so that they can
intall a new version just by typing "make install" rather than
taking some longer path involving root permissions. Furthermore,
it somehow seems more secure to be able to install new software
without typing the root password. Therefore it is a
nearly-universal practice on computers used by programmers to
have program directories in which the development programmers
have write permission. However, if a user has write permission in
a system directory, and if an intruder breaks into that user's
account, then the intruder can trivially break into root by using
that write permission to install a trojan horse.
Search paths: people usually let convenience dominate caution.
Search paths are almost universally misused. For example, many
people write shell scripts that do not specify an explicit search
path, which makes them vulnerable to inheriting the wrong path.
Many people modify the root search path so that it will be
convenient for systems programmers to use interactively as the
superuser, forgetting that the same search path will be used by
system maintenance scripts run automatically during the night.
It is so difficult to debug failures that are caused by incorrect
search paths in automatically-run scripts that a common "repair"
technique is to put every conceivable directory into the search
path of automatically-run scripts. Essentially every Unix
computer I have ever explored has grievous security leaks caused
by underspecified or overlong search paths for privileged users.
Summary conclusion: Wizards cause leaks
The people who are most likely to be the cause of leaks are
the wizards. When something goes wrong on a remote machine, often
a call goes in to a wizard for help. The wizard is usually busy
or in a hurry, and he often is sloppier than he should be with
operations on the remote machine. The people who are most likely
to have permission files left behind on stray remote machines are
the wizards who once offered help on that machine. But, alas,
these same wizards are the people who are most likely to have
write access to system directories on their home machines,
because it seems to be in the nature of wizards to want to
collect as many permissions as possible for their accounts. Maybe
that's how they establish what level of wizard that they are. The
net result is that there is an abnormally high probability that
when an errant permission file is abused by an intruder, that it
will lead to the account of somebody who has an unusually large
collection of permissions on his own machine, thereby making it
easier to break into root on that machine.
Conclusions.
My conclusions from all this are these:
* Nobody, no matter how important, should have write permission
into any directory on the system search path. Ever.
* Somebody should carefully re-think the user interface of the
Berkeley networking mechanisms, to find ways to permit people to
type passwords as they are needed, rather than requiring them to
edit new permissions into their permissions files.
* The "permission file" security access mechanism seems
fundamentally vulnerable. It would be quite reasonable
for a system manager to forbid the use of them, or to
drastically limit the use of them. Mechanized checking is
easy.
* Programmer convenience is the antithesis of security, because
it is going to become intruder convenience if the programmer's
account is ever compromised. This is especially true in
setting up the search path for the superuser.
Lament
I mentioned in the introduction that we had talked to the
intruders on the telephone. To me the most maddening thing about
this intrusion was not that it happened, but that we were unable
to convince any authorities that it was a serious problem, and
could not get the telephone calls traced. At one point an
intruder spent 2 hours talking on the telephone with a Stanford
system manager, bragging about how he had done it, but there was
no way that the call could be traced to locate him. A few days
later, I sat there and watched the intruder log on to one
Stanford comptuer, and I watched every keystroke that he typed on
his keyboard, and I watched him break in to new directories, but
there was nothing that I could do to catch him because he was
coming in over the telephone. Naturally as soon as he started to
do anything untoward I blasted the account that he was using and
logged him off, but sooner or later new intruders will come
along, knowing that they will not be caught because what they are
doing is not considered serious. It isn't necessarily serious,
but it could be. I don't want to throw such people in jail,
and I don't want to let them get away either. I just want to
catch them and shout at them and tell them that they are being
antisocial.
Brian Reid
DEC Western Research and Stanford University
[Some TOPS-20 conclusions:
(1) Nobody should ever have access to <ROOT-DIRECTORY>, for any
reason whatsoever. A common means of leaving a Trojan horse
behind on TOPS-20 is to put a password on <ROOT-DIRECTORY>.
If you have a password on your <ROOT-DIRECTORY> you have
probably been and are still being cracked, perhaps without
your knowledge! It is truly trivial to crack a TOPS-20 wide
open if you know a password on <ROOT-DIRECTORY>.
PANDA monitors forbid all CRDIR%'s on <ROOT-DIRECTORY>
except during structure creation. Stanford monitors had an
earlier version of this; I don't know if they still do.
(2) Nobody should ever have group access to any of the SYS:
directories, and especially not to SYSTEM:.
(3) All users should have different passwords on each system
they have an account on. This especially holds true for
Wheels, but is not limited to them. Encrypted passwords
help, but users should be forbidden from using any word
that can be found in a dictionary, proper name, or commonly
used number (e.g. social security, telephone).
(4) Sites should log all significant security events on the
console. This list can include capabilities enablings,
directory creations (or at least those which create accounts
or change privileges), use of CRJOB%, excessive password
failures, privileged user logins/logouts. The monitor at
PANDA logs all of the above and more; it also fixes up the
old Tenex LOGTTY stuff (it suffered software rot over the
years).
(5) Sites should forbid unprivileged use of CRJOB%. In most
monitors it is a security hole.
(6) Sites should require periodic password changes.
]
|