This section deals with Unix passwords.
The password file for Unix is located in /etc and is a text file called passwd. By default and by design, this file is world readable by anyone on the system. On a Unix system using NIS/yp or password shadowing the password data may be located elsewhere. This "shadow" file is usually where the password hashes themselves are located.
Okay, first off, let's cover the structure of the password file.
An entry in the password file consists of seven colon-delimited fields:
nomad:HrLNrZ3VS3TF2:501:100:Simple Nomad:/home/nomad:/bin/bash
This is what the fields actually are:
The password field contains, yes, a one-way encrypted password. This means that it is practically impossible to decrypt the encrypted password. The password field consists of 13 characters - the first two characters are the "salt" and the remainder is the actual hash.
When you log in with your account name and password, the password is encrypted and the resulting hash is compared to the hash stored in the password file. If they are equal, the system accepts that you've typed in the correct password and grants you access.
To prevent crackers from simply encrypting an entire dictionary and looking up the hash, the salt was added to the algorithm to create a possible 4096 different conceivable hashes for a particular password. This lengthens the cracking time because it becomes a little harder to store an encrypted dictionary online as the encrypted dictionary now would have to take up 4096 times the disk space. This does not make password cracking harder, just more time consuming.
Unix passwords allow mixed case, numbers, and symbols. Typically the maximum password length on a standard Unix system is 8 characters, although some systems (or system enhancements) allow up to 16 characters.
Brute-force password cracking is simply trying a password of A with the given salt, folowing by B, C, and on and on until every possible character combination is tried. It is very time consuming, but given enough time brute force cracking WILL get the password.
There are a few brute-force crackers out there for Unix passwords. Any brute-force cracker will do
Dictionary password cracking is the most popular method for cracking Unix passwords. The cracking program will take a word list, and one at a time try to crack one or all of the passwords listed in the password file. Some password crackers will filter and/or mutate the words as they try them, such as substitute numbers for certain letters, add prefixes or suffixes, or switch case or order of letters.
The most popular cracking utility is probably Alex Muffet's program, Crack. Crack can be configured by an administrator to periodically run and automagically mail a nastygram to a user with a weak password, or run in manual mode. Crack can also be configured to run across multiple systems and to use user-defined rules for word manipulate/mutation to maximize dictionary effectiveness - very flexible. However it is probably too much program for the novice script kiddie.
Another popular favorite is John the Ripper, based off of the popular DOS-based Jack the Ripper. Jack had a number of easy-to-use features, and Solar Designer took Jack's interface and developed John. To make things even better, Solar added Crack-like rules, and made sure the code would run on DOS or Unix. Either one is recommended. If you're going to be cracking on a DOS-based machine, use John the Ripper, otherwise either one is fine for Unix (the jury is still out on which one is best for Unix, it really depends on which one you are used to using).
There are several techniques that an admin might employ to force users to use better passwords, and several different packages that could be loaded and configured onto most Unix systems to better secure the passwords.
One of the first techniques is to enforce password aging. While this varies from system to system, basically password aging states that you can "expire" a password. That way you can force a user to have to change his password periodically.
The security advantage is that if the user changes their password every 30 days, that stolen password file is obsolete after a month (in theory, see the next question). This alone is not real security unless it is used in conjunction with other password techniques.
Some systems allow a minimal password length to be specified, certain dictionary words to be disallowed, or even disallow perceived "crackable" passwords. This in combination with password aging can help ensure that a user's password is probably going to be aged and therefore changed before it can be cracked.
Another very popular technique is called password "shadowing". This alters the password file entry slightly:
nomad:!:501:100:Simple Nomad:/home/nomad:/bin/bash
Note the "!" token in place of the one way encrypted password. This means that the password is located in a different file, typically called the shadow file. You will also find a "*" token on some shadow password implementations. On many Unix systems, the password file is still located in /etc but called shadow, some systems even place the shadow in a different directory. Here is a chart that lists a few systems, the location of the shadow, and the token.
| System | Shadow | Token |
|---|---|---|
| AIX | /etc/security/passwd | ! |
| BSD | /etc/master.passwd | * |
| DG/UX | /etc/tcb/aa/user/ | * |
| HP-UX | /.secure/etc/passwd | * |
| IRIX | /etc/shadow | x |
| Linux | /etc/shadow | * |
| SCO | /tcb/auth/files/[first letter of username]/[username] | * |
| SunOS 4.1+c2 | /etc/security/passwd.adjunct | ##username |
| SunOS 5.x | /etc/shadow [optional NIS+ private secure maps/tables] | ##username |
| System V < 4.2 | /etc/shadow | x |
| System V >= 4.2 | /etc/security/* database | x |
Depending on the system and implementation, an encrypted password may still be allowed in the password field, and lack of anything in the field implies lack of a password for that account. Some systems (AIX comes to mind) allow you to configure exactly what is allowed and not allowed as far as how the password field is used.
It should be noted most modern systems come with password shadowing already set up and configured.
The easiest way to get the hashes is to gain root and then compile and run the following program:
/*
* shadow.c - gcc -o shadow shadow.c
* run as root - shadow > passwd.file
*/
#include &lgt;pwd.h>
main()
{
struct passwd *p;
while(p=getpwent())
printf("%s:%s:%d:%d:%s:%s:%s\n",
p-> pw_name, /* account name */
p-> pw_passwd, /* hash */
p-> pw_uid, /* user id */
p-> pw_gid, /* group id */
p-> pw_gecos, /* gecos field */
p-> pw_dir, /* home dir */
p-> pw_shell); /* shell (typically) */
}
This will output the reconstructed password file, which you can save for easy cracking in most common password crackers. This will not work on a system using SRP (see below).
Okay, so you've gained access to a system and can see the password file, but it is shadowed and haven't busted root (yet), or you are simply viewing the password file, say through a CGI exploit. Here is an example:
root:!:0:0:root:/root:/bin/tcsh 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:0:shutdown:/sbin:/sbin/shutdown halt:!:7:0:halt:/sbin:/sbin/halt mail:!:8:12:mail:/var/spool/mail: news:!:9:13:INN (NNTP Server) Admin ID, 525-2525:/usr/local/lib/inn:/bin/ksh uucp:!:10:14:uucp login user:/var/spool/uucppublic:/usr/sbin/uucp/uucico operator:!:0:0:operator:/root:/bin/tcsh games:!:12:100:games:/usr/games: man:!:13:15:man:/usr/man: postmaster:!:14:12:postmaster:/var/spool/mail:/bin/tcsh httpd:!:15:30:httpd:/usr/sbin:/usr/sbin/httpd: nobody:!:65535:100:nobody:/dev/null: ftp:!:404:100::/home/ftp:/bin/nologin nomad:!:501:100:Simple Nomad, 525-5252:/home/nomad:/bin/bash webadmin:!:502:100:Web Admin Group ID:/home/webadmin:/bin/bash thegnome:!:503:100:Simple Nomad's Old Account:/home/thegnome:/bin/tcsh dorkus:!:504:100:Alternate account for Fred:/home/dorkus:/bin/tcsh
Some of the more interesting things about this password file are:
SRP, or Secure Remote Password, uses a zero knowledge authentication scheme. That is, only the user knows their password, there is never enough cryptographic material going back and forth on the network to reveal the password or its hash. The same goes for the password file -- there is simply not enough material in the file to construct a hash. This means that even if you crack a system with a remote root exploit and are sitting at a root shell, you cannot grab password hashes to crack.
SRP has other useful features as well. It allows for complete replacement of FTP and telnet with SRP-enabled versions (clients and daemons), long passwords (up to 127 characters), and full encrypted sessions for both FTP and telnet.
For more information on zero knowledge protocols, check out the Advanced Protocols chapter in Bruce Schneier's Applied Cryptography. To learn more about SRP, check out The Stanford SRP Authentication Project.
Top | Next: Unix Local Attacks | Previous: Unix Accounts | Table of Contents