So, you've partitioned your drives, installed Linux, and created users and groups. Your next step is to address the most important security issue of all: password security.
Password security is so critical that without it, your system will never be safe. Indeed, you could install a dozen firewalls and still, if your passwords were vulnerable, your Linux system would be an open door.
Hence, password security demands a two-pronged approach. On the one hand, you apply advanced tools to strengthen passwords. On the other, you educate your users and hold them to essential password policies. This chapter covers both techniques.
The term password attack is generic. It describes various activities, including any action taken to crack, decrypt, or delete passwords, or otherwise circumvent password security mechanisms.
In the security pecking order, password attacks are primitive. In fact, password cracking is the first thing that budding hackers and crackers learn, chiefly because it demands minimal technical expertise. Today, anyone can crack Linux passwords using automated tools.
Don't confuse simplicity with ineffectiveness, though. In an overwhelming majority of cases, poor password security results in total system compromise. Attackers that initially gain only limited access can rapidly expand that access by attacking weak password security. Often, through password attacks alone, attackers obtain root access and seize control of not just one host but several.
This chapter will cover various password attack techniques, as well as steps required to secure your passwords, including
Installing password shadowing
Securing passwords in third-party applications
Hardening your system against password attack
Developing effective password policies
First, however, we'll examine how Linux generates and stores passwords. If you're already familiar with these processes, please skip ahead.
As explained in Chapter 4, "Basic Linux System Administration," many early Linux distributions store user passwords in /etc/passwd. This is unsafe because /etc/passwd is (and must be) readable. Hence, any user can view /etc/passwd's contents simply by concatenating it:
$cat /etc/passwd root:8OzrR2ac.lEGY:0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: adm:*:3:4:adm:/var/adm: lp:*:4:7:lp:/var/spool/lpd: sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:11:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail: news:*:9:13:news:/var/spool/news: uucp:*:10:14:uucp:/var/spool/uucp: operator:*:11:0:operator:/root: games:*:12:100:games:/usr/games: gopher:*:13:30:gopher:/usr/lib/gopher-data: ftp:*:14:50:FTP User:/home/ftp: man:*:15:15:Manuals Owner:/: nobody:*:65534:65534:Nobody:/:/bin/false bwagner:..CETo68esYsA:501:501:Bill Wagner:/home/bwagner:/bin/bash marty:jvXHHBGCK7nkg:502:502:Marty Rush:/home/marty:/bin/bash dnb:i1YD6CckS.J1A:500:503:Caldera OpenLinux User:/home/dnb:/bin/bash manny:bJ2NcvrnubUqU:503:504:Caldera OpenLinux User:/home/manny:/bin/bash moe:IK4OBb5NnkAHk:504:505:Caldera OpenLinux User:/home/moe:/bin/bash jack:FL.Ot0VxVe9L.:505:506:Caldera OpenLinux User:/home/jack:/bin/bash jill:JMpkh9ZrXePnM:506:507:Caldera OpenLinux User:/home/jill:/bin/bash stacy:OOfE8weNKJUFw:507:508:Caldera OpenLinux User:/home/stacy:/bin/bash Alex:yIRWmr3zbhms6:509:100:Alex Brittain:/home/Alex:/bin/bash Nicole:zKQR.cqTgzkco:508:509:Caldera OpenLinux User:/home/Nicole:/bin/bash
Passwords occupy the second field:
bwagner:..CETo68esYsA:501:501:Bill Wagner:/home/bwagner:/bin/bash marty:jvXHHBGCK7nkg:502:502:Marty Rush:/home/marty:/bin/bash dnb:i1YD6CckS.J1A:500:503:Caldera OpenLinux User:/home/dnb:/bin/bash manny:bJ2NcvrnubUqU:503:504:Caldera OpenLinux User:/home/manny:/bin/bash moe:IK4OBb5NnkAHk:504:505:Caldera OpenLinux User:/home/moe:/bin/bash jack:FL.Ot0VxVe9L.:505:506:Caldera OpenLinux User:/home/jack:/bin/bash jill:JMpkh9ZrXePnM:506:507:Caldera OpenLinux User:/home/jill:/bin/bash stacy:OOfE8weNKJUFw:507:508:Caldera OpenLinux User:/home/stacy:/bin/bash Alex:yIRWmr3zbhms6:509:100:Alex Brittain:/home/Alex:/bin/bash Nicole:zKQR.cqTgzkco:508:509:Caldera OpenLinux User:/home/Nicole:/bin/bash
Note that the passwords are scrambled beyond human recognition. They have been exposed to cryptography. Briefly, we'll examine passwords, encryption, and cryptography in a historical context.
Note
If your Linux system already has shadowing installed (the second field contains no scrambled passwords but only placeholders), please skip ahead.
Humans have used passwords for thousands of years, but we find the first concrete evidence in ancient Egypt. When a prominent Egyptian died, workers prepared his body by mummifying it. They then buried the deceased with scrolls bearing prayers from the Book of the Dead. On these scrolls, priests wrote secret passwords that could buy the deceased entry into heaven.
Most such passwords were not encrypted. Instead, priests put their trust in fate, gambling that the deceased would reach heaven before grave robbers discovered him. Whether things ultimately worked out that way, we'll never know. But we do know that at some point (roughly 2,000 B.C., during the reign of Mentuhotep III), Egyptians dispensed with plain-text passwords. Over the next 1,000 years, in addition to fractions and primitive algebra, the Egyptians developed rudimentary cryptography. Let's briefly cover cryptography now.
The word cryptography stems from two ancient words: krypto (hidden) and graphia (writing). Cryptography, therefore, is the science of secret writing. In cryptography, you create messages that only authorized personnel can read. To everyone else, cryptographic or encrypted text is gibberish.
The earliest cryptography was primitive, often consisting of anagram-style scrambling, where characters were merely rearranged. For example, the word Egyptian might be transposed to neagiytp. Please see Figure 5.1.
Figure 5.1. In anagrams, letters are rearranged. To unscramble the message, you must rearrange the letters into their original positions.
Later, in Roman times, messengers used substitution ciphers. Early substitution ciphers employed simple formulas to uniformly convert each character to another. Julius Caesar popularized one that consisted of shifting characters ahead by three. Hence, the letter a becomes c, the letter b becomes d, and so on.
Today, simple substitution ciphers exist but aren't used for serious data hiding. One is ROT-13, a substitution cipher that shifts characters 13 positions ahead (so a becomes n, b becomes o, and so on). To test ROT-13, compile the following code and run it:
#include <stdio.h>
#include <ctype.h>
/* test-rot13.c
A simple ROT-13 substitution cipher.
To compile: "gcc test-rot13.c -o rot13" */
void main() {
int user_input;
printf(">Please enter some text to encrypt or decrypt
");
printf("---------------------------------
");
while((user_input=getchar())) {
if (islower(user_input))
user_input = 'a' + (user_input - 'a' + 13) % 26;
if (isupper(user_input))
user_input = 'A' + (user_input - 'A' + 13) % 26;
putchar(user_input);
}
}
Running this book's title, Maximum Linux Security, through ROT-13 will produce the following text:
Znkvzhz Yvahk Frphevgl
The chief advantage of ROT-13-style ciphers is that they obscure the original letters used. Hence, attackers cannot decode the message by rearranging letter positioning, as they would with an anagram. Instead, they must deduce the shifting formula used, which is more difficult.
Note
For a more detailed (but still brief) historical treatment of cryptography, see A Short History of Cryptography, Dr. Frederick B. Cohen, Management Analytics, 1995, located at http://www.all.net/books/ip/Chap2-1.html.
Simple substitution ciphers are too rudimentary to protect data, though. So over the centuries, and particularly in the last 100 years, researchers have developed many different cipher types. Initially, these ciphers were simple enough that human beings, spending hours or days, could ascertain the algorithm used. However, as computers emerged that could perform millions of calculations per second, the demand for stronger encryption increased.
Linux passwords are created using an advanced encryption algorithm from IBM called the Data Encryption Standard, or DES.
The Data Encryption Standard (DES) is the most popular cipher in history, even though it's been around a mere 25 years.
In the early 1970s, the U.S. government was already using several ciphers in classified, secret, and top secret environments. However, it lacked a standardized encryption method for more general use. In 1973, the National Bureau of Standards strove to remedy that.
As explained in Federal Information Processing Standards Publication 74, Guidelines for Implementing and Using the NBS Data Encryption Standard:
Because of the unavailability of general cryptographic technology outside the national security arena, and because security provisions, including encryption, were needed in unclassified applications involving Federal Government computer systems, NBS initiated a computer security program in 1973 which included the development of a standard for computer data encryption. Since Federal standards impact on the private sector, NBS solicited the interest and cooperation of industry and user communities in this work.
Many companies developed proposals, but IBM prevailed. IBM's DES was subjected to rigorous testing and, by 1977, the National Bureau of Standards and the National Security Agency endorsed it. Since then, DES has been the de facto encryption algorithm used in non-classified environments and UNIX/Linux passwords.
Federal Processing Standards Publication 46-2 concisely describes DES as:
Both encryption and decryption functions rely on a key, without which unauthorized users cannot decrypt a DES-encrypted message. This key (derived from the user's typed password and some padded information, as discussed later) consists of 64 binary digits (0s and 1s). 56 bits are used in encryption, and 8 are used in error checking. The total number of possible keys is therefore quite high:
If the complete 64-bit input is used (i.e., none of the input bits should be predetermined from block to block) and if the 56-bit variable is randomly chosen, no technique other than trying all possible keys using known input and output for the DES will guarantee finding the chosen key. As there are over 70,000,000,000,000,000 (seventy quadrillion) possible keys of 56 bits…
Functionally, DES is a block cipher, a cipher that works on data blocks of determinate size (in this case, 64-bit chunks). Blocks of data that exceed this determinate size are broken into 64-bit fragments. The remaining portions shorter than 64 bits are then padded. Padding is when DES adds insignificant bits to smaller parts to achieve a complete 64-bit block.
From here, DES performs three important operations, the first of which is the initial permutation. In permutation, data bits are shifted to different positions in a table. To gain a sense of what permutation is all about, consider encrypting the following string:
THE RED CAR
You can use a rudimentary permutation cipher that shifts character positioning. This takes two steps. First, you rewrite the string vertically, like this:
T H E R E D C A R
Next, you reconstitute the message to a horizontal string again:
TRC HEA EDR
Of course, the DES initial permutation is infinitely more complicated but happens in a similar fashion. Through this initial permutation, DES derives an input block. The input block is then scrambled by complex mathematical operations (a process called transformation) to produce a pre-output block. Finally, the pre-output block is subjected to still another permutation, and the final result is the scrambled text, sometimes called encrypted text but more accurately referred to as encoded text.
Note
If you want specifics (including mathematical formulas) on how DES arrives at encrypted text, see the resource links at the end of this chapter or go to http://www.itl.nist.gov/div897/pubs/fip46-2.htm. Linux's implementation of DES is crypt(3), an enhanced, high-speed, efficient DES implementation from Eric Young that's available in libdes. You'll find that many security programs use (or incorporate) libdes, including Secure Shell (discussed in Chapter 10, "Protecting Data in Transit").
In any event, early Linux distributions store DES-encrypted passwords in /etc/passwd. Here, again, is a typical entry:
stacy:OOfE8weNKJUFw:507:508:Caldera OpenLinux User:/home/stacy:/bin/bash
If your system stores passwords this way, you need to either upgrade or manually install password shadowing (discussed later in this chapter). Here's why: Although it is true that attackers must search a minimum of 32 quadrillion keys (and probably more) to find the correct key, they need not search for keys at all. Instead, they can concatenate /etc/passwd to a file and use the encrypted passwords to perform a simple dictionary attack.
Note
For excellent coverage of cryptographic terms, check out Terry Ritter's Crypto Glossary, located at http://www.io.com/~ritter/GLOSSARY.HTM.
DES, like most things, is not infallible. Linux passwords encrypted with DES can be cracked quickly, usually within minutes. There are two chief reasons for this:
The human factor—Users invariably choose characteristically weak passwords.
Limited length—Linux passwords are short. The number of transformations necessary to encrypt one is relatively small.
In dictionary attacks, attackers take dictionaries—long wordlists—and encrypt them using DES. During this process, they send regular words, proper names, and other text through precisely the same permutations and transformations that Linux passwords are exposed to. Over time, using high-speed cracking tools, attackers can encrypt each dictionary word in some 4,096 different ways. Each time a cracking tool derives such encrypted text, it compares it to the passwords from /etc/passwd. Sooner or later (often sooner) it finds a match, and when it does, it notifies the attacker: a password has been cracked.
Since there's no substitute for experience, you're going to execute a dictionary attack right now.
To perform a dictionary attack on your own passwords, you need passwords from /etc/passwd (naturally) and a suitable password auditing tool. For this example, use Crack.
Note
If your system already has password shadowing installed, you must first extract your passwords to a file. To do so, issue the following command: ypcat passwd > passwords.txt.
Application: Crack
Required: C + root (and Perl if you do parallel or multi-processor cracking)
Config Files: dictgrps.conf, dictrun.conf, globrule.conf, network.conf.
Security History: Crack has no outstanding or previous security history.
Notes: You must have root to run Crack. Note that if you're caught running Crack on other folks' password files, you may get busted because this is quite illegal. If you're employed as a system administrator, you may still encounter problems, so ensure that you have adequate authorization before testing or cracking system passwords. Cases often arise where system administrators are brought to book, dismissed, or otherwise penalized for performing unauthorized password audits. If you have any doubts about your firm's policies, ask first. (Conversely, if you're intentionally using Crack for unlawful activity, remember that if you use someone else's processor power and time to perform your nefarious activity, you will almost certainly get collared.)
Crack is the UNIX community's best-known password auditing tool. In early releases, its author, Alec Muffett, described Crack as
…a freely available program designed to find standard UNIX eight-character DES encrypted passwords by standard guessing techniques… It is written to be flexible, configurable and fast, and to be able to make use of several networked hosts via the Berkeley rsh program (or similar), where possible.
(See Crack: A Sensible Password Checker for Unixat http://alloy.net/writings/funny/crack_readme.txt.)
Over time, he only slightly amended that description. Today, Muffet describes Crack as
…a password guessing program that is designed to quickly locate insecurities in UNIX (or other) password files by scanning the contents of a password file, looking for users who have misguidedly chosen a weak login password.
Crack is currently in release 5.0a, which I used to generate the following example. If you intend to try Crack against your own passwords, please take a moment now to download Crack at http://www.users.dircon.co.uk/~crypto/index.html.
The example runs through several phases:
Unpacking
CrackMaking
CrackRunning
CrackViewing your results
Let's do it.
After you've downloaded Crack, place it in a directory suitable for unpacking. For this example, unpack Crack from /root.
Next, unzip the Crack archive using gunzip:
$ gunzip crack5.0.tar.gz
This will unzip to a file named crack5.0.tar, a tar archive. Unpack the Crack archive using the tar command, like this:
$ tar -xvf crack5.0.tar
Next, you'll see many file and directory names scroll past. Crack is busy unpacking a directory named c50a/. Depending on your system load and resources, this may take time.
When Crack is finished unpacking, change to directory c50a/ and read manual.txt for specific configuration notes. Otherwise, at this point you're ready to make Crack.
Note
You shouldn't encounter problems installing, compiling, or running Crack. (The most common problem is when C either wasn't installed or was installed improperly.) Before generating the following example, I unpacked and compiled Crack on default installations of both OpenLinux and Red Hat. In both cases, there were no problems. However, note that on some Linux systems, you may need to uncomment the line in Crack for LIBS –lcrypt because this is not in libc.
To make Crack, issue the following command line:
$./Crack –makeonly
Again, you'll see many messages scroll past as Crack compiles. This can take as long as 10 minutes. If your system successfully compiles Crack, you will see this message:
all made in util make[1]: Leaving directory `/root/c50a/src/util' Crack: makeonly done
Next, you must have Crack compile your dictionaries. To do so, issue the following command:
$ Crack -makedict
This will take some time. When Crack is finished, it will report this message:
Crack: Created new dictionaries... Crack: makedict done
Crack can crack your /etc/passwd file directly, so you needn't necessarily copy your password records to another file. However, I like to keep everything together, so I copied /etc/passwd to passwords.txt in the /cd50a directory:
$ cp /etc/passwd passwords.txt
To run Crack, issue the Crack command plus options (discussed below) plus the name of the file that contains the passwords, like this:
$ Crack passwords.txt
Crack will then start and issue an initial report:
src; for dir in * ; do ( cd $dir ; make clean ) ; done ) make[1]: Entering directory `/root/c50a/src/lib' rm -f dawglib.o debug.o rules.o stringlib.o *~ make[1]: Leaving directory `/root/c50a/src/lib' make[1]: Entering directory `/root/c50a/src/libdes' /bin/rm -f *.o tags core rpw destest des speed libdes.a .nfs* *.old *.bak destest rpw des speed make[1]: Leaving directory `/root/c50a/src/libdes' make[1]: Entering directory `/root/c50a/src/util' rm -f *.o *~ make[1]: Leaving directory `/root/c50a/src/util' make[1]: Entering directory `/root/c50a/src/lib' make[1]: `../../run/bin/linux-2-i586/libc5.a' is up to date. make[1]: Leaving directory `/root/c50a/src/lib' make[1]: Entering directory `/root/c50a/src/util' all made in util make[1]: Leaving directory `/root/c50a/src/util' Crack: The dictionaries seem up to date... Crack: Sorting out and merging feedback, please be patient... Crack: Merging password files... cat: run/F-merged: No such file or directory Crack: Creating gecos-derived dictionaries mkgecosd: making non-permuted words dictionary mkgecosd: making permuted words dictionary Crack: launching: cracker -kill run/Ksamshacker.sams.net.1092
After startup, Crack will run as a background process unless you specify otherwise. You can track it using the ps command. Here's some typical output:
1175 2 S N 0:04 cracker -kill run/Ksamshacker.sams.net.1092 1178 2 Z N 0:00 (kickdict <zombie>) 4760 2 S N 0:00 kickdict 240 4761 2 R N 0:00 sh root/c50a/scripts/smartcatrun/dict/gecos.txt.dwg.gz 4762 2 S N 0:00 sh -c dictfilt | crack-sort | uniq 4763 2 S N 0:00 dictfilt 4764 2 R N 0:00 sort 4765 2 R N 0:00 sh -c dictfilt | crack-sort | uniq
As Crack works, it applies many rules to each word. Rules are possible ways in which a password might be written. For example:
Alternate upper- and lowercase lettering.
Spelling the word forwards and then backwards, and then fusing the two results (for example:
cannac).Repeating a word once, twice, and so on (you'll see an example in your results on this cracking session).
Adding the number
1to the beginning and/or end of each word.
Table 5.1 lists some rules employed by Crack.
Table 5.1. Some Common Crack Rules
You can keep tabs on Crack and the rule it is currently using by watching progress files in /c50a/run. Here's some sample output:
I:925693285:LoadDictionary: loaded 10 words into memory G:925693285:yIRWmr3zbhms6:nicole I:925693285:OpenDictStream: trying: kickdict 4 I:925693285:OpenDictStream: status: /ok/ stat=1 look=4 find=4 genset='conf/rules.basic' rule='!?Alp' dgrp='gecos' prog='smartcat
To see if Crack has correctly guessed any of your passwords, use the Reporter tool in /c50a, like this:
$./Reporter
Here's the output from the example cracking session:
Guessed marty [marty] Marty Rush [passwords.txt /bin/bash] Guessed Nicole [alexalex] Caldera OpenLinux User [passwords.txt /bin/bash] Guessed manny [willow] Caldera OpenLinux User [passwords.txt /bin/bash] Guessed moe [solace] Caldera OpenLinux User [passwords.txt /bin/bash]
As you can see from the output, Crack got four passwords. This took only about two minutes, and you can probably deduce why: the passwords were poorly chosen. Later in this chapter, we'll discuss password choices.
Crack supports several command-line options. The more commonly used options are summarized in Table 5.2.
Table 5.2. Common Crack Command-Line Options
Finally, your Crack toolbox wouldn't be complete without a copious collection of wordlists (or dictionaries). Wordlists are simply lists of words, typically one word per line, in ASCII format. You can incorporate these wordlists into Crack's dictionary system to expand your dictionary attack's scope. Note that the larger the wordlist, the longer Crack will take to complete a full pass. However, this will also increase your chances of matching a password.
Crack comes with prefabricated wordlists suitable for most lightweight password auditing. However, if you intend to do industrial-strength password auditing, visit these sites:
You can find dictionary wordlists from the National Center for Supercomputer Applications. The NCSA offers the Official Scrabble Players' Dictionary and Webster's dictionary at http://sdg.ncsa.uiuc.edu/~mag/Misc/Wordlists.html.
If you're doing extensive password auditing, try the Wordlist Archive at Coast Purdue. Coast's archive offers wordlists on computer terms, literature, film and television, proper names, geographical names, religious terms, and scientific terms. Moreover, the site houses dictionaries in various languages, including Australian, Chinese, Danish, Dutch, French, German, Italian, Japanese, Norwegian, Spanish, Swedish, and Yiddish. Find it at ftp://coast.cs.purdue.edu/pub/dict/wordlists/.
Note
To add dictionaries, see the c50s/conf/dictgrps.conf file, which contains pointers to all currently used dictionaries. You can add your own entry. Entry format is priority:directory, like this: 1:/usr/dict/*words*. Here, the directory is given a high priority (1) and the wordlists are any filenames with the string word in /usr/dict. The priority indicates which lists (or dictionary groups) should be used first, or which ones are most likely to contain passwords. For example, you might start with common words and proper names and then progress to less likely lists, like those that contain scientific terms. For more information, see the Crack manual and the conf/dictgrps.conf file for examples.
Also, some quick notes on performance: Crack is quite fast, but much depends on your hardware. Certainly, the ideal configuration is a 400MHz box with 256MB of RAM. Unfortunately, not everyone has this kind of horsepower. However, on systems where users choose their passwords poorly, you'll probably see most user passwords cracked within an hour. (When you're testing many passwords in an enterprise environment, consider erecting a box specifically for this purpose. You'll reap better performance and avoid worries about CPU usage and priority.)
Crack is well established and quite effective, but it's not your only choice. Table 5.3 lists a few other UNIX/Linux-based DES password auditing tools.
Table 5.3. Other Linux-Compatible Password Auditing Tools
| Tool | Description and Location |
|---|---|
| John the Ripper | An all-purpose password-auditing tool for DOS, Windows, and UNIX. However, although John handles DES-style passwords, it does not use the crypt(3) approach. Instead, it uses homegrown algorithms. Nonetheless, John is fast, it supports many rules and options, and it's well documented. Get it at http://www.bullzeye.net/tools/crackers/john.zip. |
| Killer Cracker | A lightweight password-auditing tool from Doctor Dissector, written in C++. Although Killer Cracker lacks some of the extended functionality available with Crack, it's still fast. Get it at http://www.giga.or.at/pub/hacker/unix/kc9_11.tar.Z. |
| Lard | A password-auditing tool for Linux and other UNIX versions. Lard is small enough to fit on a floppy diskette, which is good for auditing on non-networked boxes in different departments and such. Get it at http://www.rat.pp.se/hotel/panik/archive/lard.zip. |
| PerlCrack | A Perl DES password cracker for Linux. Get it at http://www.netrom.com/~cassidy/utils/pcrack.zip. |
| Xcrack | A Perl script for cracking Linux passwords. It does not exercise complex rules. Instead, it performs straight-ahead encryption of words in your dictionary file. Good for environments where you expect that users have made exceptionally bad password choices. Get it at http://www.netrom.com/~cassidy/utils/xcrack.pl. |
Such tools are becoming more common now and offer widely varied attack options. For example, some tools offer not simply dictionary attacks but brute force attacks that try every possible combination. This is a seemingly indiscriminate process, and in some cases it truly is. However, good brute force routines are designed to try the most likely combinations first.
The major difference between these two approaches, though, is that a brute force attack will always eventually prevail. ("Eventually" here could mean months. As you might expect, brute force attacks take a while.) Conversely, a dictionary attack is only as good as your wordlist and your rules.
Crack-style dictionary attacks are the subject of a lot of folklore. Even today such attacks occur, although they are diminishing with the widespread use of shadowing.
One interesting story from a system administrator's viewpoint was offered in a classic paper titled Security Breaches: Five Recent Incidents at Columbia University. In it, the authors wrote
During a two-month period (February through March, 1990) Columbia University was involved in five break-in incidents on various Computer Center systems… On Friday, February 16, 1990, at around 5 P.M. a member of our UNIX systems group noticed that one of our Multimaxes felt uncharacteristically sluggish for a Friday evening. A quick look at all running processes to try and identify what was using so much of the system revealed a program called
program 2running as useruser1…A look at
user1'skshhistory file to see what the program was and where it was run from revealed unusual activity.user1had connected to a directory named''.. ''(dot dot space space) and had run a program from there. This directory contained a copy of our/etc/passwd, a file calledfunlist, and a list of 324 words calledlistcontaining a lot of first names, names of famous people and teams, and 4 miscellaneous other words. In this directory we found another copy of the executable file program, though the source code was not there. After examining the executable using tools such asstringsandnm, we concluded that program was a "password cracker" (or perhaps a "password checker" depending on your point of view).
(See Security Breaches: Five Recent Incidents at Columbia University, Fuat Baran, Howard Kaye, and Margarita Suarez, Columbia University Center for Computing Activities. Find it at http://www.vc3.com/~caldwm/security/OLDARCHIVE/papers/columbia_incidents.ps.)
Ultimately, the researchers traced down at least one culprit, a local student, but the others remained anonymous. The paper describes several such cases. If you're a first-time Linux user, I recommend reading it to get a preview of what such an attack looks like and its warning signs.
Other important papers on this subject include
Foiling the Cracker:A Survey of, and Improvements to, Password Security, Daniel V. Klein, Software Engineering Institute, Carnegie Mellon University. Klein discusses practical aspects of password security and how increased processor power and poor password choices can lead to highly effective dictionary attacks. Find it at http://www.alw.nih.gov/Security/FIRST/papers/password/klein.ps.
UNIX Password Security—Ten Years Later, David C. Feldmeier and Philip R. Karn, Bellcore. This is a formidable document that explores not only dictionary attacks but also other possible methods of using substantial processor power to crack DES. Find it at http://www.alw.nih.gov/Security/FIRST/papers/password/pwtenyrs.ps.
A Simple Scheme to Make Passwords Based on One-Way Functions Much Harder to Crack,Udi Manber, Department of Computer Science, University of Arizona. Manber discusses an interesting angle: Instead of concerns about wordlist-to-DES attacks, the focus is the possibility that crackers might generate and distribute a massive list of encrypted passwords. Find it at ftp://ftp.cs.arizona.edu/reports/1994/TR94-34.ps.
Password Security:A Case History, Robert Morris, Ken Thompson, Bell Labs. This is another good document that explores theoretical and practical means of cracking DES passwords. Find it at http://www.alw.nih.gov/Security/FIRST/papers/password/pwstudy.ps.
Dictionary attack tools like Crack are invaluable to you. They help you test your users' passwords for relative strength (something we'll address later). However, like almost any other security tool, Crack also can be a powerful weapon in the wrong hands.
Indeed, dictionary attacks have always been an integral part of the cracking scene. For years, crackers targeted /etc/passwd because it stored user passwords. Once attackers had these, they had everything. As a result, UNIX security specialists were forced to rethink password security. They needed a way of keeping /etc/passwd readable while still obscuring encrypted passwords. The answer was password shadowing.
Password shadowing is a technique in which /etc/passwd remains readable but no longer contains passwords. Instead, user passwords are stored in /etc/shadow.
Several tools perform shadowing, but the most popular is the Linux Password Shadow Suite (the shadow package), which has been available for several years. However, depending on your distribution and how old it is, you may or may not have it. To find out, examine /etc/passwd. If it contains raw, encrypted passwords in the second field, the shadow package is not installed. In that case, visit your Linux vendor's FTP or Web site now (or check your CD-ROM) and obtain and install the package.
Note
Some notes: as of this writing, most Linux distributions come with the shadow suite standard (Debian 1.3+, Red Hat 3.0.3+, and SlackWare 3.2+). However, depending on the type of installation you performed, you may need to retrieve several shadow utilities from your distribution CD-ROM. Typically, these are in a package named shadow-utils, shadow-m, shadow-misc, or something similar. If you can't immediately ascertain whether these packages are installed or even available on your CD-ROM, use a package manager like glide or LISA to find out.
After you've installed the shadow package (and verified that all shadow utilities are present), examine /etc/shadow, the shadow password database. /etc/shadow is the focal point of the shadow suite, so we'll start there.
Note
Other shadowing suites for Linux do exist, including Shadow in a Box by Michael Quan, a compilation of utilities for managing all your shadow passwords. The package contains tools for FTP, POP, sudo, and xlock, as well as both a compact and extensive crack library. Shadow in a Box is available at http://metalab.unc.edu/pub/Linux/system/admin/shadow-ina-box-1.2.tgz.
/etc/shadow is a special file that stores not just user passwords but also special rule indicators (covered later in the chapter). Here's a typical /etc/shadow file:
root:lLOTWOUA.YC2o:10713:0::7:7:: bin:*:10713:0::7:7:: daemon:*:10713:0::7:7:: adm:*:10713:0::7:7:: lp:*:10713:0::7:7:: sync:*:10713:0::7:7:: shutdown:*:10713:0::7:7:: halt:*:10713:0::7:7:: mail:*:10713:0::7:7:: news:*:10713:0::7:7:: uucp:*:10713:0::7:7:: operator:*:10713:0::7:7:: games:*:10713:0::7:7:: gopher:*:10713:0::7:7:: ftp:*:10713:0::7:7:: man:*:10713:0::7:7:: majordom:*:10713:0::7:7:: postgres:*:10713:0::7:7:: nobody:*:10713:0::7:7:: bigdave:aNi7cQR3XSTmc:10713:0::7:7:: jackie:7PbiWxVa5Ar9E:10713:0:-1:7:-1:-1:1073897392
In some respects, /etc/shadow resembles /etc/passwd. The file consists of one record per line, and each record is broken into nine colon-delimited fields:
The username
The user password
The number of days since January 1, 1970, that the password was last changed
The number of days left before the user is permitted to change his password
The number of days left before the user is forced to change his password
The number of days in advance that the user is warned that his password must soon be changed
The number of days left in which a user must change his password before the account is disabled
The number of days since January 1, 1970, that the account has been disabled
The last field is reserved
Using these values, the shadow suite implements two new concepts above and beyond basic password database maintenance:
Password aging—This is when you limit passwords to a finite lifespan, such as 90 days. When this lifespan expires, Linux forces users to create new passwords. When password aging is used in concert with proactive password checking (covered later in the chapter), it greatly enhances your security.
Automatic account lockout—Merely warning users that they need to change their passwords is unrealistic. Users are lazy and apt to ignore you. The better approach is to lock their accounts if they refuse to cooperate, but doing this manually is time-consuming. With the
shadowsuite, you needn't bother because lockout happens automatically. (You can specify lockout rules.)
The shadow suite consists of multiple utilities for user, group, and password management. These tools and their functions are summarized in Table 5.4.
Table 5.4. shadow Suite Utilities and Their Functions
Let's look at the more essential shadow suite tools and the tasks they perform.
Note
Depending on your Linux distribution and how well integrated it is with shadowing, several of the preceding utilities may not be available. This includes pwchk, pwconv, and pwunconv, among others. Recent distributions (such as Red Hat 6.0) handle most password administration tasks via graphical tools that greatly simplify your experience. When in doubt, try searching the manual pages (man –k passwd, man –k shadow) or check the Control Panel in X.
To add a new user to a password-shadowed system, use the useradd utility, which handles entries to /etc/passwd, /etc/group, and /etc/shadow.
Application: useradd (/usr/sbin/useradd)
Required: useradd
Config Files: None. This is part of the shadow package.
Security History: useradd does have a significant security history. Early versions could potentially create a UID of 0 (root) if you didn't explicitly specify a user's UID with the –u option (see the command-line option summary later in the chapter). This is an old bug (circa 1995), so it's unlikely to affect your version. However, if you're using an older Linux distribution, you should check. The problem was reported in shadow version 3.3.1. Additionally, both shadow 3.3.1 and 3.3.2 were proven to have serious security issues regarding SUID files and login.
useradd takes multiple arguments and options. These options are summarized in Table 5.5.
Table 5.5. useradd Command-Line Options
If you call useradd without arguments, it prints a usage summary:
usage: useradd [-u uid] [-g group] [-m] [-d home] [-s shell] [-r rootdir]
[-e expire dd/mm/yyyy] [-f inactive] name
useradd -D
useradd –v
Here's a minimal command line that will create a user entry in /etc/passwd, /etc/group, and /etc/shadow:
/usr/sbin/useradd jsprat -m -c"Jack Sprat" -u510 -g100 -s/bin/bash
In /etc/passwd, jsprat is added to the user list, along with his UID, GID, real name, home, and shell:
bigdave:x:100:100:Big Dave:/home/bigdave:/bin/bash
jackie:x:101:100:Jackie:/home/jackie:/bin/bash
jsprat:x:510:100:Jack Sprat:/home/jsprat/:/bin/bash
In /etc/shadow, jsprat is also added to the user list. However, note that his password wasnot automatically generated:
root:lLOTWOUA.YC2o:10713:0::7:7::
bin:*:10713:0::7:7::
daemon:*:10713:0::7:7::
adm:*:10713:0::7:7::
lp:*:10713:0::7:7::
sync:*:10713:0::7:7::
shutdown:*:10713:0::7:7::
halt:*:10713:0::7:7::
mail:*:10713:0::7:7::
news:*:10713:0::7:7::
uucp:*:10713:0::7:7::
operator:*:10713:0::7:7::
games:*:10713:0::7:7::
gopher:*:10713:0::7:7::
ftp:*:10713:0::7:7::
man:*:10713:0::7:7::
majordom:*:10713:0::7:7::
postgres:*:10713:0::7:7::
nobody:*:10713:0::7:7::
bigdave:aNi7cQR3XSTmc:10713:0::7:7::
jackie:7PbiWxVa5Ar9E:10713:0:-1:7:-1:-1:1073897392
jsprat:*not set*:10715:0:-1:7:-1:-1:
Remember this when you're creating a user: useradd does not generate passwords. Instead, you must generate the user's passwords after creating his account. The procedure for this is precisely the same as for creating a user's password on a non-shadowed system. Use the passwd command:
[root@linuxbox2 /root]# passwd jsprat Enter new UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully
Afterward, when you check /etc/shadow, you'll find that the user's password information has been updated:
bigdave:aNi7cQR3XSTmc:10713:0::7:7::
jackie:7PbiWxVa5Ar9E:10713:0:-1:7:-1:-1:1073897392
jsprat:cALtUMRf40VbU:10715:0:-1:7:-1:-1:1073897392
After you've created the new user's account and password, your next step is to seed his directory with vital startup files. Let's quickly cover that issue now.
When a user logs in, Linux reads environment information from one or more startup files and then stores pristine copies of these files in /etc/skel. Here's a typical listing of /etc/skel:
$ ls –al /etc/skel drwxr-xr-x 4 root root 1024 May 2 13:32 . drwxr-xr-x 23 root root 3072 May 3 22:18 .. -rw-r--r-- 1 root root 49 Nov 25 1997 .bash_logout -rw-r--r-- 1 root root 913 Nov 24 1997 .bashrc -rw-r--r-- 1 root root 650 Nov 24 1997 .cshrc -rw-r--r-- 1 root root 111 Nov 3 1997 .inputrc -rw-r--r-- 1 root root 392 Jan 7 1998 .login -rw-r--r-- 1 root root 51 Nov 25 1997 .logout -rw-r--r-- 1 root root 341 Oct 13 1997 .profile drwxr-xr-x 2 root root 1024 May 2 12:09 .seyon drwxr-xr-x 3 root root 1024 May 2 12:08 lg
Note
Note that when you're viewing your etc/skel, you must use the –a option (at a minimum) because the majority of files are dot files. Dot files do not appear in simple ls –l listing output.
After you've created a new user account, copy these files to the user's home directory and change his owner and group accordingly. If you leave them in their original state, they will still be owned by root and the user won't be able to use them.
To delete a user on a shadowed system, use userdel. This deletes user information in /etc/shadow, /etc/passwd, and /etc/group, and generally cleans up.
Application: userdel
Required: userdel
Config Files: None. This is part of the shadow package.
Security History: userdel has no significant security history. However, both shadow 3.3.1 and 3.3.2 had serious security issues regarding SUID files and login. If you're using these versions, upgrade.
Notes: In late 1998, a minor bug report was issued on userdel. Apparently, if you create and delete a user twice, using userdel for deletion, your system will thrash and the process will eat significant memory and possibly processor power. The report was relevant to shadow-980724.
To delete a user using userdel, issue the following command:
$ userdel –r username
The –r option deletes the user's home directory, which is convenient.
Note
When you're deleting users, it's good practice to back up their directories, especially if you're deleting their accounts because of unauthorized activity. By preserving a snapshot of their directory hierarchy, you retain evidence in case a dispute arises or you need to bring in the authorities.
To modify an existing user record on a shadowed system, use usermod.
Application: usermod
Required: usermod
Config Files: None. This is part of the shadow package.
Security History: usermod has no significant security history. However, both shadow 3.3.1 and 3.3.2 had serious security issues regarding SUID files and login. If you're using these versions, upgrade.
usermod can modify one field, several fields, or all fields of a user record. Changes are reflected in multiple databases. usermod options are summarized in Table 5.6.
Table 5.6. usermod Command-Line Options
Note
If you wrap automated scripts around usermod, remember that it will not allow you to institute changes on currently active users. That is, the targeted user cannot be logged on at the time. If he is, usermod will fail to commit these changes. When you're writing scripts for this purpose, include a routine that handles usermod failures (and perhaps mails you to report that the changes couldn't be made). Otherwise, you might think that changes were made when, in fact, they weren't.
Over time, you'll undoubtedly make copious changes to the password database. Because the potential for error exists, and increases over time, you should periodically verify the password database's integrity. For this, use pwchk.
Application: pwchk
Required: pwchk
Config Files: None.
Security History: pwchk has no significant security history. However, both shadow 3.3.1 and 3.3.2 had serious security issues regarding SUID files and login. If you're using these versions, upgrade.
pwchk verifies that all information in /etc/passwd and /etc/shadow is valid. It makes sure that the user and groups are valid and have valid login shells, that all fields are presented and accounted for, and that all users have an appropriate group and unique UID.
To add a group, use the groupadd utility.
Application: groupadd
Required: groupadd
Config Files: None.
Security History: groupadd has no significant security history. However, both shadow 3.3.1 and 3.3.2 had serious security issues regarding SUID files and login. If you're using these versions, upgrade.
groupadd accepts two command-line options, which are summarized in Table 5.7.
To modify a group's information, use the groupmod command.
Application: groupmod
Required: groupmod
Config Files: None.
Security History: groupmod has no significant security history. However, both shadow 3.3.1 and 3.3.2 had serious security issues regarding SUID files and login. If you're using these versions, upgrade.
Notes: In early 1998, a bug report was submitted on groupmod in Debian. Apparently, certain group modifications could cause groupmod to core dump. This problem had no reported security impact and has since been fixed.
groupmod accepts three command-line options, which are summarized in Table 5.8.
To delete a group, use the groupdel utility.
Application: groupdel
Required: groupdel
Config Files: None.
Security History: groupdel has no significant security history.
groupdel accepts a single argument—the group's name. Here's an example:
$ groupdel workers
At some point, you'll want to assign group administrators to user groups. A group administrator is someone who can add or delete users to the group he's administrating. Additionally, you may want to limit access to groups and even password-protect them. For this, use the gpasswd utility.
Application: gpasswd
Required: gpasswd
Config Files: None.
Security History: gpasswd has no significant security history.
gpasswd takes several command-line options, which are summarized in Table 5.9.
Table 5.9. gpasswd Command-Line Options
| Option | Purpose |
|---|---|
-A [admin-username] | Use this option to specify a group administrator. You identify him by username. For example, gpasswd –A jsprat workers makes jsprat a group administrator of group workers. |
-a [username] | Use this option to add a user to a group. |
-d [username] | Use this option to delete a user from a group. |
-M [member-username] | Use this option to specify members. |
-r [group] | Group administrators use this option to remove a group password. |
-R [group] | Use this option to disable group access via the newgrp command. (newgrp is discussed later in the chapter.) |
Changes made with gpasswd are reflected in /etc/group.
Over time, you and your group administrators may make copious changes to group data. Because the potential for error exists, and increases over time, you should periodically verify the integrity of group information. For this, issue the grpchk command either without arguments (grpchk) or, if you prefer, in read-only mode (grpchk –r).
Application: grpchk
Required: grpchk
Config Files: None.
Security History: grpchk has no significant security history.
grpchk examines group data, searching for possible mistakes in the number of fields and the validity of group names, group users, and group administrators. If grpchk finds such mistakes, it prompts you to fix them.
Note
If you anticipate that grpchk will find errors, consider starting it in read-only mode. Here's why: certain errors trigger grpchk to delete an entire record. Before you have it do so, I recommend that you manually examine the specified record. Perhaps you can repair the damage without entirely obliterating the record.
The shadow suite's author recognized that there would be instances when you'd want to go above and beyond the simple addition and deletion of users and groups. To account for this, the shadow suite provides several utilities for the general maintenance of accounts and authentication databases.
To modify a user's existing password expiration data, use the chage command.
Application: chage
Required: chage
Config Files: None.
Security History: chage has no significant security history.
chage allows you to change one rule, several rules, or all rules, using command-line options. Those options are summarized in Table 5.10.
Table 5.10. chage Command-Line Options
Occasionally, you may need to migrate /etc/passwd data to shadow format. If so, no problem. Use pwconv, which not only allows you to migrate data from an existing /etc/passwd database, but also allows you to simultaneously integrate already-shadowed information from an existing shadow database. This is quite convenient.
Also, pwconv has several automated security mechanisms. One is that whenever you introduce entries that have no set password, pwconv does not migrate them to /etc/shadow. Moreover, pwconv uses the default settings for expiration, warning, and account lockout that are defined in /etc/login.defs. These settings offer you a good starting point for all newly migrated accounts. (If these values are unsuitable, change them, especially if you intend to use pwconv regularly.)
From another angle, you may want to convert shadow data back to standard /etc/passwd format. For this, use pwunconv.
Finally, let's briefly address the shadow suite's own security. Is it safe? It can be. However, there are ways for attackers to mount formidable attacks.
First, know this: At its most basic, the shadow suite simply hides your passwords from prying eyes. So, instead of passwords being accessible in /etc/passwd, they're stowed away in /etc/shadow. In the short run, this certainly bolsters your system security. However, attackers are well acquainted with the shadow suite and have accordingly shifted their interest from /etc/passwd to /etc/shadow. The only material difference from an attacker's viewpoint is that /etc/shadow is harder to reach.
In fact, the shadow suite is quite safe in itself, providing that you've installed the most recent version. Unfortunately, though, its security depends largely on your system security at large. Here's why: Many other applications have holes that allow attackers to read (or even write) /etc/shadow. Mind you, this is not the fault of the shadow suite's author. It's simply a fact of life. Security analysts discover software vulnerabilities every day, and over time, applications are bound to crop up that will jeopardize your password security. This happens often enough that you must constantly be on guard.
Here are some examples:
In March 1999, a bug surfaced in
xfs(the X font server) on Red Hat 5.1. If root runsxfswhile/tmp/.font-unixexists, ordinary users will be able to read and write/etc/shadow. Check out the example exploit at http://geek-girl.com/bugtraq/1999_1/1166.html.In December 1998, researchers discovered a security flaw in
pam_unix_passwd.so(a Pluggable Authentication Module component): a temporary file is used without proper permissions. The ultimate result is that attackers can gain read and write access to/etc/shadow.In November 1998, researchers revealed a flaw in the K Desktop screensaver that, when exploited, gives attackers read access to
/etc/shadow.
In fact, on average, a similar bug crops up once every 90 days or so. Table 5.11 gives a slightly expanded view and demonstrates just how eclectic such attacks can get.
Table 5.11. Various Attacks Leading to /etc/shadow Access
| Exploit | Brief Description and Location |
|---|---|
deshadow.c | Cracker source code for uncovering /etc/shadowentries. |
imapd hole | impad core dumps in Linux can reveal shadowed passwords. Find out more at http://underground.simplenet.com/central/linux-ex/imapd_core.txt. |
| Telnet hole | You can force a core dump using telnet. The dump will reveal shadowed passwords. Find out more at http://www.hoobie.net/security/exploits/hacking/telnet_core.txt. |
shadowyank | Exploiting an FTP hole, shadowyank grabs shadowed passwords from FTP core dumps. Find out more at http://www.atomicfrog.com/archives/exploits/Xnix/SHADOWYANK.C. |
imapd crash | impad can be crashed, and the resulting dump will reveal shadowed passwords. Find out more at http://www.hoobie.net/security/exploits/hacking/imapd_4.1b.txt. |
Note
Some platforms are also vulnerable to the following attack:
$ export RESOLV_HOST_CONF=/etc/shadow $ rlogin /etc/shadow
In summary, while the shadow suite is not fundamentally flawed, many other unrelated factors can affect its security. The only way for you to protect your shadowed passwords is to be vigilant and keep your system up to date.
The shadow suite is an important innovation and a vital tool in your security arsenal. In addition to protecting your passwords from unauthorized eyes, the shadow suite offers you extended control over user accounts and passwords, as well as an opportunity to implement at least minimal password policy with relative ease.
Password shadowing is an excellent start, but it cannot guarantee your system's password security. At this point, let's expand the scope from traditional password security (locking down /etc/passwd) to more exotic but equally important issues:
Human password choices and their effect on system security
Proactive password checking
Auxiliary password security
Encryption is a vital security component. However, no matter how strong your encryption is, it will fail when users make poor password choices.
Here's a fact: Users are lazy, error-prone, and forgetful. Often, users create passwords from the following (partly to save time and partly to make their lives easier):
These are all awful choices. Crack would crack any such password in seconds. In fact, good passwords are difficult to come by even if you know something about encryption.
There are several reasons for this. One is that even your local electronics store sells computers with staggering processor power. These machines can perform millions of instructions per second, thus providing attackers with the necessary juice to try thousands of character combinations.
Moreover, dictionary attack tools have become quite advanced. For example, Crack employs rules to produce complex character combinations and case variations that create exotic passwords far beyond the limits of the average user's imagination, memory, or patience (such as #z!~[non-printable-character]=X<). Even when users get relatively creative with their passwords, Crack can often prevail.
Note
To test this theory, create a few accounts with what you think would be strong passwords, and then run Crack against them. See how long it takes before Crack generates a valid match.
Most of the time, users don't even make reasonable efforts to bolster password security. In a 1993 paper titled UNIX Password Security, one specialist observed:
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 important to the security of the whole system. Users often have no idea how a multi-user system works and don't realize that they, by choosing an easy-to-remember password, indirectly make it possible for an outsider to manipulate the entire system.
(See Unix Password Security, Walter Belgers, December 6, 1993. Find it at http://www.giga.nl/walter/write/pwseceng.ps.)
This is why tools like Crack are so valuable. By regularly checking the strength of the passwords on your network, you can ensure that crackers cannot penetrate it by exploiting bad password choices. Such a regimen can greatly improve your system security. In fact, many folks now employ tools that check a user's password when it is first created. This implements the philosophy that
The best solution to the problem of having easily guessed passwords on a system is to prevent them from getting on the system in the first place. If a program such as a password cracker reacts by guessing detectable passwords already in place, then although the security hole is found, the hole existed for as long as the program took to detect it… If, however, the program which changes users' passwords… checks for the safety and guessability before that password is associated with the user's account, then the security hole is never put in place.
(See "Improving System Security via Proactive Password Checking", Computers and Security [14, pp. 233-249], Matthew Bishop, UC Davis, California and Daniel Klein, LoneWolf Systems Inc., 1995.)
This technique is called proactive password checking, something that can greatly improve your Linux system's password security.
In proactive password checking, you eliminate weak passwords before they're committed to the password database. The process works like this: When a user creates his desired password, it is first compared against a wordlist and a series of rules. If the password fails to meet the requirements of this process (for example, the proactive password checker finds a match or judges the pattern to be too simple), the user is forced to choose another.
Currently, there are three prevailing proactive password checkers (and there's a fourth one forthcoming). All require some hacking on your part. They are
Let's quickly cover each one now.
Caution
If you're new to Linux or UNIX, take extra care when you install proactive password checkers or any program that intervenes in the login or password-creation processes. I strongly urge you to take an old hard drive, install Linux, and perform a test run before installing these programs on any mission-critical system. That way, if you make mistakes, you can simply reinstall and try again with no harm done. Ideally, you should be able to successfully implement these tools on a throwaway drive several times before you move them to a mission-critical system.
Matt Bishop authored passwd+, which offers the following amenities:
Extensive logging capabilities, including the logging of each session, any errors, which users have changed their passwords, which rules the password failed to meet, and the success or failure of a given password change.
Specification of the number of significant characters in the password (that is, how many will be used in the test).
Additionally, passwd+ allows you to set the error message that will be displayed when a user forwards a weak password. You should use this functionality to gently teach users why their password choices are bad.
Here are some sample rules that passwd+ provides:
Office number, office telephone, hostname, and domain name are forbidden.
Passwords must be at least n characters long.
Passwords must be mixed-case.
Passwords that appear in the dictionary are forbidden.
The first and last names (forward or reversed) are forbidden.
The login name (forward or reversed) is forbidden.
Bishop developed an extensive toolkit language so that you can control every aspect of the password and the tests to which it is exposed.
Get passwd+ at ftp://ftp.dartmouth.edu/pub/security/
To learn more about passwd+ and the theory behind it, get the technical report A Proactive Password Checker, Dartmouth Technical Report PCS-TR90-152. This is not available on the Net from Dartmouth. However, you can request it hardcopy by mail from http://www.cs.dartmouth.edu/cgi-bin/mail_tr.pl?tr=TR90-152.
Another good proactive password checker is Argonne National Laboratory's anlpasswd. This program, written largely in Perl, uses the dictionary file of your choice, and you can create custom rules. Standard out-of-the-box rules include the following:
Numbers with spaces and spaces with numbers
Uppercase and lowercase with spaces
All lower- or uppercase
All numbers
Leading capital letters and numbers
All combinations of the above
There are also other amenities to anlpasswd. One is that the Perl code is exceptionally well commented and highly readable. From this, you can gain insight into how such programs are designed, even if you have only minimal knowledge of Perl.
anlpasswd also comes with a paper titled "Pass or Fail: A New Test for Password Legitimacy." In it, the authors of anlpasswd describe their motivation, their aim, and their results along the way, offering a rare look into the tool's development. And finally, anlpasswd is quite easy to install.
anlpasswd is available at ftp://coast.cs.purdue.edu/pub/tools/unix/anlpasswd/anlpasswd-2.3.tar.Z.
npasswd (written by Clyde Hoover) is more than simply a proactive password checker. As explained in the documentation:
npasswdis a replacement for thepasswd(1)command for UNIX and UNIX-like operating systems.npasswdsubjects user passwords to stringent guessability checks to decrease the chance of users choosing vulnerable passwords…npasswdis designed to supplement or replace the standard password change programs—passwd,chfnandchsh.
npasswd's history is interesting. When the Internet Worm hit in 1988, npasswd's author was at the University of Texas in Academic Computing Services. Although UT survived the worm unscathed, the incident generated substantial interest. Based on after-the-fact Worm documentation, npasswd's author wrote a password-auditing program, ran it against his department's password database, and found many weak passwords.
Over the next year, the author wrote the first version of npasswd and deployed it system-wide. By 1993, he had incorporated modules from Crack. Today, npasswd is a very advanced proactive password checker.
npasswd is a commercial-grade, comprehensive solution that can greatly strengthen your password security. The distribution even comes with a development toolkit so you can extend npasswd or incorporate it into other applications.
To learn more about npasswd and the principles on which it's based, go to http://www.utexas.edu/cc/unix/software/npasswd/doc/.
To obtain npasswd, point your browser to http://www.utexas.edu/cc/unix/software/npasswd/.
In traditional password attacks, attackers grab system password files and run cracking utilities against them. Their aim is to seize root. As we've seen, you can circumvent these attacks with shadowing, proactive password utilities, and some common sense.
However, although these steps substantially reduce risk, by themselves they cannot guarantee comprehensive password security. Here's why: On the average Linux network, a lot of other password mechanisms exist, many of which don't rely on /etc/passwd or /etc/shadow for authentication. In this next section, we'll examine these other possible avenues of attack and how you can close them.
Up until this point I've focused primarily on login passwords, and these are certainly important. After all, many client/server applications use standard /etc/passwd- or /etc/shadow-based authentication (FTP, telnet, and TFTP, just to name a few). However, in the greater scheme, these are only the beginning.
I want you to fully appreciate the importance of password security, so we're going to take it in steps. First, consider your own account—not as root, but as a user. Please examine Figure 5.2.
As depicted in Figure 5.2, chances are that you've got at least five passwords. Take me, for example. When I wake up each morning, I go through this routine:
Boot up and provide a BIOS password.
Connect to my ISP and provide a dialup password.
Check my mail with a POP3 password.
Log on to a few AltaVista and Hotmail mail accounts, using even more passwords.
Telnet into my company's server with another password.
But Linux is a multi-user system, and I know that you probably plan to support at least a few users. For the sake of argument, let's say that you have five other users on your machine. Please examine Figure 5.3.
To put things completely in perspective, let's also assume that you're deploying Linux in a business environment. You will ultimately be faced with a situation similar to the one depicted in Figure 5.4.
Your tiny network could have as many as 200 passwords on it. There are only two possibilities for these, and both are highly undesirable:
Most of those passwords are the same.
Most of those passwords are different.
Each scenario presents its own risks. In the first case, users create identical passwords for several applications and servers. This is deadly. Suppose that your users also maintain outside accounts with services like Hotmail. Suppose further that your users are lazy and their Hotmail passwords are identical to passwords they've used on your system. Already you're in hot water. If Hotmail's password databases are ever compromised (and Hotmail passwords have been exposed in the past), outsiders could raid your system. Hence, you're exposed to cross-host attacks, and possibly even cross-network attacks.
Or take the reverse situation. Suppose that you institute a company policy that all passwords must be unique, and your users actually adhere to this, even on systems that do not support proactive password checking. (An unlikely scenario, but we're theorizing.) If so, the quality and strength of these passwords invariably will be poor. Your users' laziness, coupled with their anxiety over forgetting all those different passwords, will probably cause them to buckle and create passwords that are either rudimentary or quite similar to others they've created.
And it gets worse. Third-party applications seldom use established password databases (/etc/passwd or /etc/shadow) to perform authentication. Even less seldom do they implement entirely secure password storage. (For example, Netscape Communicator 4.5 stored encrypted email passwords in a JavaScript source file named prefs.js.)
These conditions will only worsen because networking is becoming more and more critical for business and entertainment. This naturally increases public demand for newer and more interesting networking tools. In response, developers continue churning out innovative applications and rushing them to market, often without subjecting them to stringent security testing. Thus, the consumer market is flooded with applications that store or transmit passwords insecurely.
Therefore, if you're deploying Linux in a business environment, take the following steps:
Limit your users to an established, approved application set with which you are intimately familiar. You can do this by defining critical tasks and the tools needed to perform them. In regard to applications that do not fit these criteria, chuck them and forbid personnel to use them.
For each approved application, ascertain password storage and transmission procedures. Contact the vendor if necessary. If the vendor refuses to provide this information, reconsider using that application. There is no good reason why a vendor would want to conceal such information.
To assess password transmission procedures, try sniffing a network session between two hosts using the application under suspicion. Sniffer results will reveal whether the password was transmitted in plain text, uuencoded text, XOR'd text, or encrypted text. To learn how, see Chapter 7, "Sniffers and Electronic Eavesdropping."
Eliminate any application that employs poor password storage and transmission procedures. For example, if you discover that a client/server application stores passwords on the client end, that's a warning sign.
Regarding your approved application set, monitor its respective vendors (and security lists) for hot-off-the-press advisories. You should know within hours when new holes are discovered.
Test system passwords for strength once a month, even if you use proactive password checking.
Beyond all this, you still have one great weapon at your disposal: user education. Ensure that your users understand how important password security is. In particular, try to impress upon them the importance of complying with password policies, even when it's inconvenient. They should never write down passwords, give them to third parties without authorization, or share them even with trusted co-workers. (This last requirement may seem severe, but it is quite necessary.)
One recent advance in authentication is Pluggable Authentication Modules (PAMs), which allow you to alter how Linux applications perform authentication without rewriting and compiling them. In recent distributions, PAMs have been integrated into login and other procedures requiring password authentication.
Some typical PAM modules:
pam_cracklib—A pluggable proactive password checker. This module from Cristian Gafton adds password strength checking to any PAM-aware application.pam_deny—A pluggable module from Andrew G. Morgan that will notify a PAM-aware application that authentication has failed. It forces authentication and denies any session in which authentication is not provided or fails.pam_pwdb—A pluggable password database module from Cristian Gafton and Andrew G. Morgan that provides password expiration, aging, warning, and so on.pam_group—A pluggable module from Andrew G. Morgan that assigns and tracks group membership on users and their terminal sessions.
PAMs provide many options for authentication management, account management, session management, and password management, and they've been used to develop authentication operations like single sign-on. (That's where a user is authenticated once within a network of trusted machines. Once logged in, the user can roam and his initial authentication follows them.) To see an example of this type of PAM usage, see X/Open Single Sign-on Service (XSSO): Pluggable Authentication Modules from the OpenGroup, located at http://www.opengroup.org/onlinepubs/8329799/toc.htm.
To learn more about PAMs, see these documents by Andrew G. Morgan:
The Linux-PAM System Administrators' Guide, which demonstrates PAM concepts and usage.
The Linux-PAM Module Writers' Manual Draft, located at http://temp.redhat.com/linux-info/pam/docs/pam_modules.html.
Pluggable Authentication Modules,Internet Draft draft-morgan-pam-00.txt, August 11, 1998. In this document, Morgan gives a view to PAM guts and the PAM specification.
The Linux-PAM Application Developers' Guide, located at http://temp.redhat.com/linux-info/pam/docs/pam_appl.html .
Note
PAMs now also provides MD5 password support and therefore much longer passwords. If you use Red Hat Linux, please check your user guide for more information.
PAMs have a limited but significant security history. Michal Zalewski determined in December 1998 that PAM packages up to version 0.64-2 were vulnerable to a race condition attack that offered local attackers root access.
Reportedly, pam_unix_passwd.so (the password security module) creates a temporary shadow file with permissions 0666. Under the correct conditions, this could lead to a world-readable/writeable /etc/npassd and /etc/shadow. Check out the vulnerability test code at http://www.sekurity-net.com/newfiles/pam_unix_passwd.so.txt. Also, independent researcher Tani Hosokawa reported in June 1999 that on Red Hat 6.0, the PAM-aware su provided a decent opportunity for you to brute-force the root's password. For a description of that technique (and be sure to read the follow-ups) go to http://www.securityportal.com/list-archive/bugtraq/1999/Jun/0097.html.
Finally, several other exotic password security solutions are available:
Biometric access controls—As discussed in Chapter 2, "Physical Security," these tools authenticate a user based on his body odor, facial structure, fingerprints, retinal or iris patterns, vein layout, or voice. Biometric access controls have an exceptionally high level of accuracy. However, these are unrealistic solutions due to their high cost. With the notable exception of pilot programs recently instituted by Compaq and Sony, biometric-enabled PCs and workstations have remained quite expensive.
One-time passwords—One-time password systems generate disposable passwords on-the-fly. These passwords are never actually transmitted over the network, either. Instead, the server challenges the client with a numeric value, which the client can use to generate a suitable secret value for the return transmission. One-time password systems are designed to thwart passive password attacks, in which the attack is monitoring the network using a sniffer, protocol analyzer, and so forth. S/Key from Bellcore is a good example. Learn more in Chapter 7.
It's unlikely that you'll be running Network Information Service (NIS, formerly called the Yellow Pages or YP system). However, since NIS has a significant security history and can adversely affect your password security, it's worthy of mention here.
NIS, developed by Sun Microsystems and originally released in 1985, allows machines on a given network to share user and password information (among other things). NIS achieves this using the client-server model and RPC (remote procedure calls) to share either local or global information contained in at least these files:[*]
/etc/group/etc/hosts/etc/passwd
Global NIS information (which can be used to simulate a single sign-on situation) must be updated in a special way using special YP utilities. As explained in the yppasswd manual page:
When distributing your users' passwords over NIS (a.k.a. YP), the standard
passwd,chfnandchshutilities cannot be used anymore to let a user change her password, because they only modify the password file on the local host. They are usually replaced by their YP counterparts:yppasswd,ypchfn, andypchsh.
The chief problem with NIS is that it's insecure. By guessing your "secret" NIS domain name, crackers can grab your password information (local or global) and crack your system passwords. To see how these attacks work, get Improving the Security of Your Site by Breaking Into It, by Dan Farmer and Wietse Venema, located at http://www.securit.net/breakin.html.
NIS is quite complicated. If you intend to use it (and you shouldn't, except in intranet environments), get these resources:
Securing NIS by Doug Hughes at Auburn University, located at http://www.eng.auburn.edu/users/doug/nis.html.
Thorsten Kukuk's Linux NIS(YP)/NYS/NIS+ HOWTO, located at http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html.
Fujitsu's NIS Administration Guide, located at http://www.pdc.kth.se/doc/fujitsu/manuals/C/nuae/nuae24/nuae0439.htm.
The manual pages for ypserv,
ypbind,ypcat,ypinit, ypmake,ypmatch,yppoll,yppush,ypwhich,ypset,yppasswd,ypchfn, andypchsh, as well as the filesyp.conf, andypserv.conf.
Good password security is arguably the best and most important advantage you can have. Often, unskilled attackers will try password attacks first. When these fail, attackers may execute a denial-of-service or other primitive attack and move on. You should therefore view password security as your first line of defense. And decent password security comes with a minimum of effort.
Here are a few good rules, to be executed in sequence:
On a non-shadowed system, temporarily shut down the machine, install the
shadowsuite, and migrate users and groups accordingly. Set passwords to expire every 60–90 days, with a 5-day warning and a 1-week lockout.Next, install proactive password checking, enforcing the maximum rules and using at least a 100,000-term dictionary.
Release the machine back to the general population and let users create new passwords.
Once a month, run
Crackusing the most comprehensive wordlist you can muster. (You can automate this procedure using theatcommand.)Keep a close eye on vendor and security lists for new exploits that expose your passwords.
Ensure that each user creates a new and unique password for each host he has access to. If necessary, take the logs from your proactive password checker (which contain all passwords that users have previously tried) and append them to proactive password checking wordlists on additional hosts. This way, users' bad password choices follow them across the network.
Give your users at least basic education about password security.
If you faithfully execute these steps, you will achieve decent password security.
The following list points to good reference material online:
"2x Isolated Double-DES: Another Weak Two-Level DES Structure," Terry Ritter of Ritter Software Engineering, February 16, 1994. In this paper, Ritter makes a good argument for replacing DES. Find it at http://www.l0pht.com/pub/blackcrwl/encrypt/2XISOLAT.TXT.
"CERN Security Handbook on Passwords," CERN, November 1998. A good, short primer on choosing strong passwords. Find it at http://consult.cern.ch/writeups/security/security_3.html#SEC7.
"Observing Reusable Password Choices," Purdue Technical Report CSD-TR 92-049, Eugene H. Spafford, Department of Computer Sciences, Purdue University. Find it at http://www.alw.nih.gov/Security/FIRST/papers/password/observe.ps.
"Opus: Preventing Weak Password Choices," Purdue Technical Report CSD-TR 92-028, Eugene H. Spafford, Department of Computer Sciences, Purdue University. Find it at http://www.alw.nih.gov/Security/FIRST/papers/password/opus.ps.
"Selecting Good Passwords," David A. Curry. (Excerpted from Improving the Security of Your Unix System.) Find it at http://www.dsm.fordham.edu/password-dos+donts.html.
"Announcing the Standard for Automated Password Generator," Federal Information Processing Standards Publication 181. This document focuses on bad password choices and how to develop tools to avoid them. Find it at http://www.alw.nih.gov/Security/FIRST/papers/password/fips181.txt.
"Department of Defense Password Management Guideline." If you want to gain a more historical perspective regarding password security, start here. This document was produced by the Department of Defense Computer Security Center at Fort Meade, Maryland. Find it at http://www.alw.nih.gov/Security/FIRST/papers/password/dodpwman.txt.
"Self-Study Course in Block Cipher Cryptanalysis," B. Schneier, 1998. Self-study course in block-cipher cryptanalysis in PDF or PostScript, written by a pro. Find it at www.counterpane.com/self-study.html.
"Cryptographic Design Vulnerabilities," B. Schneier, 1998. Document in PDF. Find it at http://www.counterpane.com/design-vulnerabilities.pdf.
"DES Modes of Operation." Federal Information Processing Standards Publication 81. A technical treatment of DES. Find it at http://www.itl.nist.gov/div897/pubs/fip81.htm.
"The Electronic Frontier Foundation DES Challenge News." If you'd like to keep up with the latest efforts to crack DES, go to http://www.eff.org/descracker/.
distributed.net. This site is home to the folks who have cracked various encryption algorithms using thousands of computers over the Internet. Their project is, in a word, fascinating. By harnessing the processing power of PCs all over the world, they were able to crack at least one RSA algorithm in 23 hours. Incredible. Check it out at http://www.distributed.net/."The Encryption and Security Tutorial," Peter Gutmann. This is Mr. Gutmann's "Godzilla" tutorial, consisting of 500+ slides and addressing many important encryption issues. A good last-site-of-the-night visit, but don't expect to get much sleep. Find it at http://www.cs.auckland.ac.nz/~pgut001/tutorial/.
"Security Pitfalls in Cryptography," Bruce Schneier. A document that addresses some common misconceptions about strong encryption. Find it at http://www.counterpane.com/pitfalls.html.
[*] Depending on how NIS is configured, it can also share local and global versions of /etc/services, /etc/ethers, /etc/bootparams, and so on.