DP Tool Club 17/CD_ASCQ_17_101194.iso/vrac/riskunix.zip/RISKS.REI

Text File | 1994-09-14 | 57KB | 1,102 lines

RISKS-LIST: RISKS-FORUM Digest, Summary of messages on UNIX breakins.
THIS FILE IS AVAILABLE FOR FTP FROM CSL.SRI.COM <RISKS>RISKS.REID.

------------------------------------------------------------------------

From: [e-mail] (Brian Reid)
Date: 16 Sep 1986 1519-PDT (Tuesday)
To: Peter G. Neumann <[e-mail]>   [FOR RISKS]
Subject: Massive UNIX breakins at Stanford
RISKS-LIST: RISKS-FORUM Digest, Tuesday, 16 September 1986  Volume 3 : Issue 56

    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

------------------------------

From: [e-mail] (Dave Curry)
To: [e-mail]
Cc: [e-mail]
Subject: Massive UNIX breakins
Date: Wed, 17 Sep 86 08:01:03 EST
RISKS-LIST: RISKS-FORUM Digest,  Wednesday, 17 Sept 1986  Volume 3 : Issue 58

Brian -

    I feel for you, I really do.  Breakins can be a real pain in the
neck, aside from being potentially hazardous to your systems.  And, we
too have had trouble convincing the authorities that anything serious
is going on.  (To their credit, they have learned a lot and are much
more responsive now than they were a few years ago.)

    I do have a couple of comments though.  Griping about the Berkeley
networking utilities is well and good, and yes, they do have their
problems.  However, I think it really had little to do with the
initial breakins on your system.  It merely compounded an already
exisiting breakin several fold.

    Two specific parts of your letter I take exception to:

    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.

    Um, to put it mildly, you were asking for it.  "guest" is probably
the second or third login name I'd guess if I were trying to break
in.  It ranks right up there with "user", "sys", "admin", and so on.
And making the password to "guest" be "guest" is like leaving the
front door wide open.  Berkeley networking had nothing to do with your
initial breakin, leaving an obvious account with an even more obvious
password on your system was the cause of that.

    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.

    Once again, you asked for it.  If you don't plug the holes, someone
will come along and use them.  Again Berkeley networking had nothing to
do with your intruder getting root on your system, that was due purely
to neglect.  Granted, once you're a super-user, the Berkeley networking
scheme enables you to invade many, many accounts on many, many machines.

    Don't get me wrong.  I'm not trying to criticize for the sake of
being nasty here, but rather I'm emphasizing the need for enforcing
other good security measures:

    1. Unless there's a particularly good reason to have one, take
       all "generic" guest accounts off your system.  Why let
       someone log in without identifying himself?

    2. NEVER put an obvious password on a "standard" account.
       This includes "guest" on the guest account, "system" on the
       root account, and so on.

       Enforcing this among the users is harder, but not
       impossible.  We have in the past checked all the accounts
       on our machines for stupid passwords, and informed everyone
       whose password we found that they should change it.  As a
       measure of how simple easy passwords make things, we
       "cracked" about 400 accounts out of 10,000 in one overnight
       run of the program, trying about 12 passwords per account.
       Think what we could have done with a sophisticated attack.

    3. FIX SECURITY HOLES.  Even on "unused" machines.  It's amazing
       how many UNIX sites have holes wide open that were plugged
       years ago.  I even found a site still running with the 4.2
       distributed sendmail a few months ago...

    4. Educate your police and other authorities about what's going
       on.  Invite them to come learn about the computer.  Give
       them an account and some documentation.  The first time we
       had a breakin over dialup (1982 or so), it took us three
       days to convince the police department that we needed the
       calls traced.  Now, they understand what's going on, and
       are much quicker to respond to any security violations we
       deem important enough to bring to their attention.  The
       Dean of Students office is now much more interested in
       handling cases of students breaking in to other students'
       accounts; several years ago their reaction was "so what?".
       This is due primarily to our people making an effort to
       educate them, although I'm sure the increased attention
       computer security has received in the media (the 414's, and
       so on) has had an effect too.

--Dave Curry
Purdue University
Engineering Computer Network

------------------------------

From: [e-mail] (Brian Reid)
Date: 17 Sep 1986 0729-PDT (Wednesday)
To: [e-mail] (Dave Curry)
Cc: [e-mail]
Subject: Massive UNIX breakins
RISKS-LIST: RISKS-FORUM Digest,  Wednesday, 17 Sept 1986  Volume 3 : Issue 58

The machine on which the initial breakin occurred was one that I didn't
even know existed, and over which no CS department person had any
control at all. The issue here is that a small leak on some
inconsequential machine in the dark corners of campus was allowed to
spread to other machines because of the networking code. Security is
quite good on CSD and EE machines, because they are run by folks who
understand security. But, as this episode showed, that wasn't quite good
enough.

------------------------------

Date: Thu, 18 Sep 86 09:12:59 cdt
From: "Scott E. Preece" <[e-mail]>
To: [e-mail]
Subject: Re: Massive UNIX breakins at Stanford
RISKS-LIST: RISKS-FORUM Digest, Saturday, 20 September 1986 Volume 3 : Issue 60

> From: [e-mail] (Brian Reid) The machine on which the initial
> breakin occurred was one that I didn't even know existed, and over
> which no CS department person had any control at all. The issue here is
> that a small leak on some inconsequential machine in the dark corners
> of campus was allowed to spread to other machines because of the
> networking code. Security is quite good on CSD and EE machines, because
> they are run by folks who understand security. But, as this episode
> showed, that wasn't quite good enough.
----------

No you're still blaming the networking code for something it's not supposed
to do.  The fault lies in allowing an uncontrolled machine to have full
access to the network.  The NCSC approach to networking has been just that:
you can't certify networking code as secure, you can only certify a network
of machines AS A SINGLE SYSTEM.  That's pretty much the approach of the
Berkeley code, with some grafted on protections because there are real-world
situations where you have to have some less-controlled machines with
restricted access.  The addition of NFS makes the single-system model even
more necessary.

scott preece, gould/csd - urbana, uucp:    ihnp4!uiucdcs!ccvaxa!preece

------------------------------

Date: Mon, 22 Sep 86 11:04:16 EDT
To: RISKS FORUM    (Peter G. Neumann -- Coordinator) <[e-mail]>
Subject: Massive UNIX breakins at Stanford
From: Jerome H. Saltzer <[e-mail]>
RISKS-LIST: RISKS-FORUM Digest,  Monday, 22 September 1986  Volume 3 : Issue 62

In RISKS-3.58, Dave Curry gently chastises Brian Reid:

> . . . you asked for it. . . Berkeley networking had nothing to
> do with your intruder getting root on your system, that was due purely
> to neglect.  Granted, once you're a super-user, the Berkeley networking
> scheme enables you to invade many, many accounts on many, many machines.

And in RISKS-3.59, Scott Preece picks up the same theme, suggesting that
Stanford failed by not looking at the problem as one of network security,
and, in the light of use of Berkeley software, not enforcing a no-attachment
rule for machines that don't batten down the hatches.

These two technically- and policy-based responses might be more tenable if
the problem had occurred at a military base.  But a university is a
different environment, and those differences shed some light on environments
that will soon begin to emerge in typical commercial and networked home
computing settings.  And even on military bases.

There are two characteristics of the Stanford situation that
RISK-observers should keep in mind:

     1.  Choice of operating system software is made on many factors,
not just the quality of the network security features.  A university
has a lot of reasons for choosing BSD 4.2.  Having made that choice,
the Berkeley network code, complete with its casual approach to
network security, usually follows because the cost of changing it is
high and, as Brian noted, its convenience is also high.

     2.  It is the nature of a university to allow individuals to do
their own thing.  So insisting that every machine attached to a
network must run a certifably secure-from-penetration configuration
is counter-strategic.  And on a campus where there may be 2000
privately administered Sun III's, MicroVAX-II's, and PC RT's all
running BSD 4.2, it is so impractical as to be amusing to hear it
proposed.  Even the military sites are going to discover soon that
configuration control achieved by physical control of every network
host is harder than it looks in a world of engineering workstations.

Brian's comments are very thoughtful and thought-provoking.  He describes
expected responses of human beings to typical current-day operating system
designs.  The observations he makes can't be dismissed so easily.

                    Jerry Saltzer

------------------------------

Date: Mon, 22 Sep 1986  23:03 EDT
From: Rob Austein <[e-mail]>
To:   [e-mail]
Subject: Massive UNIX breakins at Stanford
RISKS-LIST: RISKS-FORUM Digest,  Monday, 22 September 1986  Volume 3 : Issue 62

I have to take issue with Scott Preece's statement that "the fault
lies in allowing an uncontrolled machine to have full access to the
network".  This may be a valid approach on a small isolated network or
in the military, but it fails horribly in the world that the rest of
us have to live in.  For example, take a person (me) who is
(theoreticly) responsible for what passes for security on up to half a
dozen mainframes at MIT (exact number varies).  Does he have any
control over what machines are put onto the network even across the
street on the MIT main campus?  Hollow laugh.  Let alone machines at
Berkeley or (to use our favorite local example) the Banana Junior
6000s belonging to high school students in Sunnyvale, California.

As computer networks come into wider use in the private sector, this
problem will get worse, not better.  I'm waiting to see when AT&T
starts offering a long haul packet switched network as common carrier.

Rule of thumb: The net is intrinsicly insecure.  There's just too much
cable out there to police it all.  How much knowledge does it take to
tap into an ethernet?  How much money?  I'd imagine that anybody with
a BS from a good technical school could do it in a week or so for
under $5000 if she set her mind to it.

As for NFS... you are arguing my case for me.  The NFS approach to
security seems bankrupt for just this reason.  Same conceptual bug,
NFS simply agravates it by making heavier use of the trusted net
assumption.

Elsewhere in this same issue of RISKS there was some discussion about
the dangers of transporting passwords over the net (by somebody other
than Scott, I forget who).  Right.  It's a problem, but it needn't be.
Passwords can be tranmitted via public key encryption or some other
means.  The fact that most passwords are currently transmitted in
plaintext is an implementation problem, not a fundamental design
issue.

A final comment and I'll shut up.  With all this talk about security
it is important to keep in mind the adage "if it ain't broken, don't
fix it".  Case in point.  We've been running ITS (which has to be one
of the -least- secure operating systems ever written) for something
like two decades now.  We have surprisingly few problems with breakins
on ITS.  Seems that leaving out all the security code made it a very
boring proposition to break in, so almost nobody bothers (either that
or they are all scared off when they realize that the "command
processor" is an assembly language debugger ... can't imagine why).
Worth thinking about.  The price paid for security may not be obvious.

--Rob Austein <[e-mail]>

------------------------------

Date: Mon 22 Sep 86 11:07:04-PDT
From: Andy Freeman <[e-mail]>
Subject: Massive UNIX breakins at Stanford
To: [e-mail], [e-mail]
RISKS-LIST: RISKS-FORUM Digest,  Monday, 22 September 1986  Volume 3 : Issue 62

Scott E. Preece <[e-mail]> writes in RISKS-3.60:

    [e-mail] (Brian Reid) writes:
    The issue here is that a small leak on some [unknown]
    inconsequential machine in the dark corners of campus was
    allowed to spread to other machines because of the networking code.

    No, you're still blaming the networking code for something it's not
    supposed to do.  The fault lies in allowing an uncontrolled machine to
    have full access to the network.  The NCSC approach to networking has
    been just that: you can't certify networking code as secure, you can
    only certify a network of machines AS A SINGLE SYSTEM.  That's pretty
    much the approach of the Berkeley code, with some grafted on
    protections because there are real-world situations where you have to
    have some less-controlled machines with restricted access.  The
    addition of NFS makes the single-system model even more necessary.

Then NCSC certification means nothing in many (most?) situations.  A
lot of networks cross adminstrative boundaries.  (The exceptions are
small companies and military installations.)  Even in those that
seemingly don't, phone access is often necessary.

Network access should be as secure as phone access.  Exceptions may
choose to disable this protection but many of us won't.  (If Brian
didn't know about the insecure machine, it wouldn't have had a valid
password to access his machine.  He'd also have been able to choose
what kind of access it had.)  The only additional problem that
networks pose is the ability to physically disrupt other's
communication.

-andy             [There is some redundancy in these contributions,
                   but each makes some novel points.  It is better
                   for you to read selectively than for me to edit. PGN]

------------------------------

Date: 22 Sep 1986 16:24-CST
From: "Scott E. Preece" <[e-mail]>
Subject: Massive UNIX breakins at Stanford (RISKS-3.60)
To: [e-mail], [e-mail]
RISKS-LIST: RISKS-FORUM Digest,  Monday, 22 September 1986  Volume 3 : Issue 62

    Andy Freeman writes [in response to my promoting the view
    of a network as a single system]:

>       Then NCSC certification means nothing in many (most?) situations.
--------

Well, most sites are NOT required to have certified systems (yet?). If they
were, they wouldn't be allowed to have non-complying systems.  The view as a
single system makes the requirements of the security model feasible.  You
can't have anything in the network that isn't part of your trusted computing
base.  This seems to be an essential assumption.  If you can't trust the
code running on another machine on your ethernet, then you can't believe
that it is the machine it says it is, which violates the most basic
principles of the NCSC model. (IMMEDIATE DISCLAIMER: I am not part of the
group working on secure operating systems at Gould; my knowledge of the area
is superficial, but I think it's also correct.)
                   [NOTE: The word "NOT" in the first line of this paragraph
                    was interpolated by PGN as the presumed intended meaning.]

--------
        Network access should be as secure as phone access.  Exceptions may
        choose to disable this protection but many of us won't.  (If Brian
        didn't know about the insecure machine, it wouldn't have had a valid
        password to access his machine.  He'd also have been able to choose
        what kind of access it had.)  The only additional problem that
        networks pose is the ability to physically disrupt other's
        communication.
--------

Absolutely, network access should be as secure as phone access,
IF YOU CHOOSE TO WORK IN THAT MODE.  Our links to the outside
world are as tightly restricted as our dialins.  The Berkeley
networking software is set up to support a much more integrated
kind of network, where the network is treated as a single system.
For our development environment that is much more effective.
You should never allow that kind of access to a machine you don't
control.  Never.  My interpretation of the original note was that
the author's net contained machines with trusted-host access
which should not have had such access; I contend that that
represents NOT a failing of the software, but a failing of the
administration of the network.

scott preece
gould/csd - urbana, uucp:    ihnp4!uiucdcs!ccvaxa!preece

------------------------------

Date: Tue, 23 Sep 86 09:16:21 cdt
From: "Scott E. Preece" <[e-mail]>
To: [e-mail]
Subject: Massive UNIX breakins at Stanford
RISKS-LIST: RISKS-FORUM Digest Wednesday, 24 September 1986 Volume 3 : Issue 63

   [This was an addendum to Scott's contribution to RISKS-3.61.  PGN]

I went back and reviewed Brian Reid's initial posting and found myself more
in agreement than disagreement.  I agree that the Berkeley approach offers
the unwary added opportunities to shoot themselves in the foot and that
local administrators should be as careful of .rhosts files as they are of
files that are setuid root; they should be purged or justified regularly.

I also agree that it should be possible for the system administrator to turn
off the .rhosts capability entirely, which currently can only be done in the
source code and that it would be a good idea to support password checks (as
a configuration option) on rcp and all the other remote services.

scott preece, gould/csd - urbana, uucp:    ihnp4!uiucdcs!ccvaxa!preece

------------------------------

Date: Tue, 23 Sep 86 08:41:29 cdt
From: "Scott E. Preece" <[e-mail]>
To: [e-mail]
Subject: Re: Massive UNIX breakins at Stanford
RISKS-LIST: RISKS-FORUM Digest Wednesday, 24 September 1986 Volume 3 : Issue 63

  > From: Rob Austein <[e-mail]>

  > I have to take issue with Scott Preece's statement that "the fault lies
  > in allowing an uncontrolled machine to have full access to the network"...

I stand by what I said, with the important proviso that you notice the word
"full" in the quote.  I took the description in the initial note to mean
that the network granted trusted access to all machines on the net.  The
Berkeley networking code allows the system administrator for each machine to
specify what other hosts on the network are to be treated as trusted and
which are not.  The original posting spoke of people on another machine
masquerading as different users on other machines; that is only possible if
the (untrustworthy) machine is in your hosts.equiv file, so that UIDs are
equivalenced for connections from that machine.  If you allow trusted access
to a machine you don't control, you get what you deserve.

Also note that by "the network" I was speaking only of machines intimately
connected by ethernet or other networking using the Berkeley networking
code, not UUCP or telephone connections to which normal login and password
checks apply.

The description in the original note STILL sounds to me like failure of
administration rather than failure of the networking code.

scott preece

    [OK.  Enough on that.  The deeper issue is that most operating
     systems are so deeply flawed that you are ALWAYS at risk.  Some
     tentative reports of Trojan horses discovered in RACF/ACF2 systems
     in Europe are awaiting details and submission to RISKS.  But their
     existence should come as no surprise.  Any use of such a system in
     a hostile environment could be considered a failure of administration.
     But it is also a shortcoming of the system itself...  PGN]

------------------------------

Date: Mon 22 Sep 86 17:09:27-PDT
From: Andy Freeman <[e-mail]>
Subject: UNIX and network security again
To: [e-mail]
cc: [e-mail]
RISKS-LIST: RISKS-FORUM Digest Wednesday, 25 September 1986 Volume 3 : Issue 65

[e-mail] (Scott E. Preece) writes:

    If you can't trust the code running on another machine on your
    ethernet, then you can't believe that it is the machine it says it is,
    which violates the most basic principles of the NCSC model.

That's why electronic signatures are a good thing.

    I wrote (andy@sushi):
    >   Then NCSC certification means nothing in many (most?) situations.

    Well, most sites are required to have certified systems (yet?). If
    they were, they wouldn't be allowed to have non-complying systems.

The designers of the Ford Pinto were told by the US DOT to use $x as a
cost-benefit tradeoff point for rear end collisions.  Ford was still
liable.  I'd be surprised if NCSC certification protected a company
from liability.  (In other words, being right can be more important
than complying.)

       [This case was cited again by Peter Browne (from old Ralph Nader
        materials?), at a Conference on Risk Analysis at NBS 15 September
        1986:  Ford estimated that the Pinto gas tank would take $11 each to
        fix in 400,000 cars, totalling $4.4M.  They estimated 6 people might
        be killed as a result, at $400,000 each (the going rate for lawsuits
        at the time?), totalling $2.4M.  PGN]

    Absolutely, network access should be as secure as phone access, IF YOU
    CHOOSE TO WORK IN THAT MODE.  Our links to the outside world are as
    tightly restricted as our dialins.  The Berkeley networking software
    is set up to support a much more integrated kind of network, where the
    network is treated as a single system.  For our development
    environment that is much more effective.  You should never allow that
    kind of access to a machine you don't control.  Never.  My
    interpretation of the original note was that the author's net
    contained machines with trusted-host access which should not have had
    such access; I contend that that represents NOT a failing of the
    software, but a failing of the administration of the network.

My interpretation of Brian's original message is that he didn't have a
choice; Berkeley network software trusts hosts on the local net.  If
that's true, then the administrators didn't have a chance to fail; the
software's designers had done it for them.  (I repeated all of Scott's
paragraph because I agree with most of what he had to say.)

-andy

    [I think the implications are clear.  The network software is weak.
     Administrators are often unaware of the risks.  Not all hosts are
     trustworthy.  The world is full of exciting challenges for attackers.
     All sorts of unrealistic simplifying assumptions are generally made.
     Passwords are typically stored or transmitted in the clear and easily
     readable or obtained -- or else commonly known.  Encryption is still
     vulnerable if the keys can be compromised (flawed key distribution,
     unprotected or subject to bribable couriers) or if the algorithm is
     weak.  There are lots of equally devastating additional vulnerabilities
     waiting to be exercised, particularly in vanilla UNIX systems and
     networks thereof.  Remember all of our previous discussions about not
     trying to put the blame in ONE PLACE.  PGN]

------------------------------

From: [e-mail] (Brian Reid)
Date: 25 Sep 1986 0014-PDT (Thursday)
To: [e-mail]
Reply-To: [e-mail]
Subject: Follow-up on Stanford breakins: PLEASE LISTEN THIS TIME!
RISKS-LIST: RISKS-FORUM Digest Thursday, 25 September 1986  Volume 3 : Issue 66

   "What experience and history teach is that people have never learned
    anything from history, or acted upon principles deduced from it."
        -- Georg Hegel, 1832

Since so many of you are throwing insults and sneers in my direction, I feel
that I ought to respond. I am startled by how many of you did not understand
my breakin message at all, and in your haste to condemn me for "asking for
it" you completely misunderstood what I was telling you, and why.

I'm going to be a bit wordy here, but I can justify it on two counts. First,
I claim that this topic is absolutely central to the core purpose of RISKS (I
will support that statement in a bit). Second, I would like to take another
crack at making you understand what the problem is. I can't remember the
names, but all of you people from military bases and secure installations who
coughed about how it was a network administration failure are completely
missing the point. This is a "risks of technology" issue, pure and simple.

As an aside, I should say that I am not the system manager of any of the
systems that was broken into, and that I do not control the actions of any
of the users of any of the computers. Therefore under no possible explanation
can this be "my fault". My role is that I helped to track the intruders down,
and, more importantly, that I wrote about it.

I am guessing that most of you are college graduates. That means that you
once were at a college. Allow me to remind you that people do not need badges
to get into buildings. There are not guards at the door. There are a large
number of public buildings to which doors are not even locked. There is not a
fence around the campus, and there are not guard dogs patrolling the
perimeter.

The university is an open, somewhat unregulated place whose purpose is the
creation and exchange of ideas. Freedom is paramount. Not just academic
freedom, but physical freedom. People must be able to walk where they need to
walk, to see what they need to see, to touch what they need to touch.
Obviously some parts of the university need to be protected from some people,
so some of the doors will be locked. But the Stanford campus has 200
buildings on it, and I am free to walk into almost any of them any time that
I want. More to the point, *you* are also free to walk into any of them.

Now let us suppose that I am walking by the Linguistics building and I notice
that there is a teenager taking books out of the building and putting them in
his car, and that after I watch for a short while, I conclude that he is not
the owner of the books. I will have no trouble convincing any policeman that
the teenager is committing a crime. More important, if this teenager has had
anything resembling a normal upbringing in our culture, I will have no
trouble convincing the teenager that he is committing a crime. Part of the
training that we receive as citizens in our society is a training in what is
acceptable public behavior and what is not. The books were not locked up, the
doors to the library were not locked, but in general people do not run in and
steal all of the books.

Or let me suppose instead that I am a reporter for the Daily News. I have a
desk in a huge room full of desks. Most of the desks are empty because the
other reporters are out on a story. You've seen scenes like this in the
movies. It is rare in small towns to find those newsrooms locked. Here in
Palo Alto I can walk out of my office, walk over to the offices of the Times
Tribune a few blocks away, walk in to the newsroom, and sit down at any of
those desks without being challenged or stopped. There is no guard at the
door, and the door is not locked. There are 50,000 people in my city, and
since I have lived here not one of them has walked into the newsroom and
started destroying or stealing anything, even though it is not protected.
Why not? Because the rules for correct behavior in our society, which are
taught to every child, include the concept of private space, private
property, and things that belong to other people. My 3-year-old daughter
understands perfectly well that she is not to walk into neighbors' houses
without ringing the doorbell first, though she doesn't quite understand why.

People's training in correct social behavior is incredibly strong, even
among "criminals". Murderers are not likely to be litterbugs. Just because
somebody has violated one taboo does not mean that he will immediately and
systematically break all of them.

In some places, however, society breaks down and force must be used. In the
Washington Square area of New York, for example, near NYU, you must lock
everything or it will be stolen.  At Guantanamo you must have guards or the
Cubans will come take things. But in Palo Alto, and in Kansas and in Nebraska
and Wisconsin and rural Delaware and in thousands of other places, you do not
need to have guards and things do not get stolen.

I'm not sure what people on military bases use computer networks for, but
here in the research world we use computer networks as the building blocks of
electronic communities, as the hallways of the electronic workplace. Many of
us spend our time building network communities, and many of us spend our time
developing the technology that we and others will use to build network
communities. We are exploring, building, studying, and teaching in an
electronic world. And naturally each of us builds an electronic community
that mirrors the ordinary community that we live in. Networks in the Pentagon
are built by people who are accustomed to seeing soldiers with guns standing
in the hallway. Networks at Stanford are built by people who don't get out of
bed until 6 in the evening and who ride unicycles in the hallways.

Every now and then we get an intruder in our electronic world, and it
surprises us because the intruder does not share our sense of societal
responsibilities. Perhaps if Stanford were a military base we would simply
shoot the intruder and be done with it, but that is not our way of doing
things. We have two problems. One is immediate--how to stop him, and how
to stop people like him. Another is very long-term: how to make him and his
society understand that this is aberrant behavior.

The result of all of this is that we cannot, with 1986 technology, build
computer networks that are as free and open as our buildings, and therefore
we cannot build the kind of electronic community that we would like.

I promised you that I would justify what this all has to do with RISKS.

We are developing technologies, and other people are using those
technologies. Sometimes other people misuse them. Misuse of technology is one
of the primary risks of that technology to society. When you are engineering
something that will be used by the public, it is not good enough for you to
engineer it so that if it is used properly it will not hurt anybody. You must
also engineer it so that if it is used *improperly* it will not hurt anybody.
I want to avoid arguments of just where the technologist's responsibility
ends and the consumer's responsibility begins, but I want to convince you,
even if you don't believe in the consumer protection movement, that there is
a nonzero technologist's responsibility.

Let us suppose, for example, that you discovered a new way to make
screwdrivers, by making the handles out of plastic explosives, so that the
screwdriver would work much better under some circumstances. In fact, these
screwdrivers with the gelignite handles are so much better at putting in
screws than any other screwdriver ever invented, that people buy them in
droves. They have only one bug: if you ever forget that the handle is
gelignite, and use the screwdriver to hit something with, it will explode and
blow your hand off. You, the inventor of the screwdriver, moan each time you
read a newspaper article about loss of limb, complaining that people
shouldn't *do* that with your screwdrivers.

Now suppose that you have invented a great new way to make computer networks,
and that it is significantly more convenient than any other way of making
computer networks. In fact, these networks are so fast and so convenient that
everybody is buying them. They have only one bug: if you ever use the network
to connect to an untrusted computer, and then if you also forget to delete
the permissions after you have done this, then people will break into your
computer and delete all of your files. When people complain about this, you
say "don't connect to untrusted computers" or "remember to delete the files"
or "fire anyone who does that".

Dammit, it doesn't work that way. The world is full of people who care only
about expediency, about getting their screws driven or their nets worked. In
the heat of the moment, they are not going to remember the caveats. People
never do. If the only computers were on military bases, you could forbid
the practice and punish the offenders. But only about 0.1% of the computers
are on military bases, so we need some solutions for the rest of us.

Consider this scenario (a true story). Some guy in the Petroleum Engineering
department buys a computer, gets a BSD license for it, and hires a Computer
Science major to do some systems programming for him. The CS major hasn't
taken the networks course yet and doesn't know the risks of breakins. The
petroleum engineer doesn't know a network from a rubber chicken, and in
desperation tells the CS student that he can do whatever he wants as long as
the plots are done by Friday afternoon. The CS student needs to do some
homework, and it is much more convenient for him to do his homework on the
petroleum computer, so he does his homework there. Then he needs to copy it
to the CS department computer, so he puts a permission file in his account on
the CSD computer that will let him copy his homework from the petroleum
engineering computer to the CSD computer. Now the CS student graduates and
gets a job as a systems programmer for the Robotics department, and his
systems programmer's account has lots of permissions. He has long since
forgotten about the permissions file that he set up to move his homework last
March. Meanwhile, somebody breaks into the petroleum engineering computer,
because its owner is more interested in petroleum than in computers and
doesn't really care what the guest password is. The somebody follows the
permission links and breaks into the robotics computer and deletes things.

Whose fault is this? Who is to blame? Who caused this breakin? Was it the
network administrator, who "permitted" the creation of .rhosts files? Was it
the person who, in a fit of expedience, created /usr/local/bin with 0776
protection? Was it the idiot at UCB who released 4.2BSD with /usr/spool/at
having protection 0777? Was it the owner of the petroleum engineering
computer? Was it the mother of the kid who did the breaking in, for failing
to teach him to respect electronic private property? I'm not sure whose fault
it is, but I know three things:

 1) It isn't my fault (I wasn't there). It isn't the student's fault (he
    didn't know any better--what can you expect for $5.75/hour). It isn't the
    petroleum engineer's fault (NSF only gave him 65% of the grant money he
    asked for and he couldn't afford a full-time programmer). Maybe you could
    argue that it is the fault of the administrator of the CSD machine, but in
    fact there was no administrator of the CSD machine because he had quit to
    form a startup company. In fact, it is nobody's fault.

 2) No solution involving authority, management, or administration will work
    in a network that crosses organization boundaries.

 3) If people keep designing technologies that are both convenient and
    dangerous, and if they keep selling them to nonspecialists, then
    expedience will always win out over caution. Convenience always wins,
    except where it is specifically outlawed by authority. To me, this is
    one of the primary RISKs of any technology. What's special about
    computers is that the general public does not understand them well
    enough to evaluate the risks for itself.

------------------------------

Date: Wed, 24 Sep 86 09:35:37 pdt
From: hplabs!sdcrdcf![e-mail] (Darrel VanBuer)
Organization: System Development Corporation R&D, Santa Monica
To: hplabs!CSL.SRI.COM!RISKS
Subject: Re: Stanford breakin, RISKS-3.62 DIGEST
RISKS-LIST: RISKS-FORUM Digest  Thursday 25 September 1986  Volume 3 : Issue 67

I think many of the respondents misunderstand what went wrong: there was no
failure in the 4.2 trusted networking code.  It correctly communicated the
message that "someone logged in as X at Y wants to run program Z at W".  The
failure of security was that
  1)  the "someone" was not in fact X because of some failure of security
      (e.g. poor password).
  2)  the real X who had legitimate access on W had previously created a file
      under some user id at W saying X at Y is an OK user.
  3)  the real X was lazy about withdrawing remote privileges (not essential,
      but widens the window of opportunity.

There's a tough tradeoff between user convenience in a networked environment
and security.  Having to enter a password for every remote command is too
arduous for frequent use.  Interlisp-D has an interesting approach:
  1.  Try a generic userid and password.
  2.  Try a host-specific userid and password.
In either case, if it does not have these items in its cache, it prompts the
user.  The cache is cleared on logout and at certain other times which
suggest the user has gone away (e.g. 20 minutes without activity).
Passwords are never stored in long term or publically accessible locations.
It's also less convenient than 4.2 since you need to resupply IDs after
every cache flush.  It also has the opening for lazy users to use the same
ID and password at every host so that the generic entry is enough.

Darrel J. Van Buer, PhD, System Development Corp., 2525 Colorado Ave
Santa Monica, CA 90406, [phone] x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
                                                            !sdcrdcf!darrelj
[e-mail]

------------------------------

To: [e-mail]
Subject: Unix breakins - secure networks
Date: 24 Sep 86 13:46:39 PDT (Wed)
From: "David C. Stewart" <[e-mail]>
RISKS-LIST: RISKS-FORUM Digest,  Friday, 26 September 1986  Volume 3 : Issue 68

    One of the observations that have been made in the wake of the
Stanford breakin is that Berkeley Unix encourages the assumption that
the network itself is secure when in fact, it is not difficult to imagine
someone tapping the ethernet cable and masquerading as a trusted host.

    I have been intrigued by work that has been going on at CMU to
support the ITC Distributed File System.  (In the following, Virtue is
the portion of the filesystem running on a workstation and Vice is
that part running on the file server.)

    The authentication and secure transmission functions are
    provided as part of a connection-based communication package,
    based on the remote procedure call paradigm.  At connection
    establishment time, Vice and Virture are viewed as mutually
    suspicious parties sharing a common encryption key.  This key
    is used in an authentication handshake, at the end of which
    each party is assured of the identity of the other.  The final
    phase of the handshake generates a session key which is used
    for encrypting all further communication on the connection.
    The use of per-session encryption keys reduces the risk of
    exposure of authentication keys. [1]

    The paper goes on to state that the authorization key may be
supplied by a password (that generates the key but is not sent along
the wire in cleartext) or may be on a user-supplied magnetic card.

    This is one of the few systems I have seen that does not trust
network peers implicitly.  A nice possibility when trying to reduce
the risks involved with network security.

Dave Stewart - Tektronix Unix Support - [e-mail]

[1] "The ITC Distributed File System: Principles and Design",
Operating Systems Review, 19, 5, p. 43.

------------------------------

From: Dave Taylor <[e-mail]>
To: RISKS@sri-csl (The Risks Mailing Group)
Date: Fri, 26 Sep 86 17:55:53 PDT
Subject: Comment on the reaction to Brians Breakin Tale
Organization: Hewlett-Packard Laboratories, Unix Networking Group
Work-Phone-Number: [phone]
RISKS-LIST: RISKS-FORUM Digest,  Friday, 26 September 1986  Volume 3 : Issue 68

I have to admit I am also rather shocked at the attitudes of most of the
people responding to Brian Reids' tale of the breakin at Stanford.  What
these respondents are ignoring is The Human Element.

Any system, however secure and well designed, is still limited by the
abilities, morals, ethics, and so on of the Humans that work with it.  Even
the best paper shredder, for example, or the best encryption algorithm, isn't
much good if the person who uses it doesn't care about security (so they shred
half the document and get bored, or use their husbands' first name as the
encryption key).

The point here isn't to trivialize this, but to consider and indeed, PLAN FOR
the human element.

I think we need to take a step back and think about it in this forum...

                        -- Dave

------------------------------

End of RISKS-FORUM Digest  EXCERPTS ON UNIX BREAKINS AT STANFORD
************************
14-Oct-86 05:36:56-PDT,2516;000000000011
Return-Path: <[e-mail]>
Received: from decwrl.dec.com by CSL.SRI.COM with TCP; Tue 14 Oct 86 05:36:48-PDT
Received: by decwrl.dec.com (5.54.2/4.7.34)
    id AA26218; Tue, 14 Oct 86 05:37:16 PDT
Message-Id: <[e-mail]>
Date: 14-Oct-1986 0834
From: [e-mail]  (Martin Minow, DECtalk Engineering ML3-1/U47 223-9922)
To: [e-mail]
Subject: "Pink Floyd" -- (slightly) more on the Stanford breakin

(From Usenet, originally posted by Werner Uhrig @ ut-ngp.uucp):

Path: decvax!ucbvax!ucbcad!nike!think!husc6!ut-sally!ut-ngp!werner
From: [e-mail] (Werner Uhrig)
Newsgroups: misc.headlines
Subject: "Pink Floyd" HACKER HITS UNIVERSITY COMPUTERS
Date: Thu, 9-Oct-86 23:24:29 EDT


[from the Sunday paper - I hate it when they use 'hacker' instead of 'cracker']

    'Pink Floyd' attacks lack clear motive

SAN FRANCISCO - A sophisticated computer hacker who calls himself "Pink Floyd"
has broken into dozens of university and business computers around the nation
and taunted the experts who have tried to thwart him.

The hacker reportedly has used telephone connections to break into computers
at Stanford University, Lawrence Berkeley Laboratory, the University of
Illinois, MIT, Mitre, and at least 3 unidentified Silicon Valley companies.

The intruder began the break-ins Aug. 25.  Some of the computers contain
military and government information, ....

However, a computer official at Stanford speculated that the hacker may be
using his extraordinary skill to make a point, since no damage to files or
programs has been found.

"Pink Floyd" has made only subtle alterations to some systems to make
detecting his intrusions more difficult ....

Stanford and others have spent thousands of dollars to improve security as a
result.

Stanford officials said the hacker has tapped into as many as 60 campus
computers, some of which include systems that contain non-classified,
Pentagon-sponsored research data and programs.

The intruder, described by one computer scientist as fitting the profile of a
computer-science graduate student, has called Standford officials and carried
on a phone conversation with them while breaking security protection in campus
computers.

"This is the most pesky kind of case, involving people trying to get into
systems rather than do damage," said Jay BloomBecker, director of the
National Center for Computer Crime Data in Los Angeles.