Specialized Auditing Matters - UNIX Shadow Password File

On a UNIX/Linux system without a shadow password file installed, user password information is stored in the /etc/passwd file. Although popular literature will state passwords are encrypted, technically they are actually encoded rather than encrypted. The algorithm used to encode the password is a one-way hash function, ensuring that the encoded password cannot be feasibly decoded. Essentially, this means the algorithm encodes the password in one direction, but makes it mathematically infeasible to reverse the process. When a UNIX user uses an authorized password, it is encoded in a randomly generated value sometimes referenced as the "salt."

This means the password could be stored in 4096 different combinations. When a user logs into the system and provides a password, the salt is first retrieved from the encoded password. The salt value supplied password is encoded with the retrieved salt value, and then compared with the encoded password. If the two values match, the user is authenticated and permitted to access the system.

Password cracking software programmers know all this and simply encrypt a dictionary of words using all possible 4096 salt values and compare them to the already encoded passwords. They will compare the encoded passwords in the /etc/passwd file with the cracker's database. Once they find a match, they have the password for the account. This is known as a dictionary attack.

Think of it in terms of an eight-character password encoded to 4096 times 13 character strings. A dictionary of about 400,000 words, names, common passwords, and simple variations easily fit in a hard drive of 5GB. The program needs only to sort and check for matches.

Along with passwords, the /etc/passwd file contains user IDs and group IDs that are used in the systems programs. In order for UNIX to function, the /etc/passwd file must be read by everyone. If you were to change the file so no one can read it, the first command of ls -l will display all the user and group IDs.

Having a shadow password file solves the problem by relocating the passwords to another file, /etc/shadow, with access privileges set to root. By moving the passwords to the /etc/shadow file, administrators are effectively keeping attackers from having access to the encoded passwords with which to perform a dictionary attack.

Format of the /etc/passwd File
A nonshadowed /etc/passwd file has the following format:

user name:passwd:UID:GID:full_name:directory:shell
where

user name = the user (login) name

passwd = the encoded password

UID = numerical user ID

GID = numerical default group ID

full_name = the user's full name is held here in this field that can also store information other than just the full name

directory = user's home directory (full path name)

shell = user's login shell (full path name)


For example:

user name: Tbge08pfz4wuk:503:100:Full Name:/home/user
name:/bin/sh

where Tb is the salt and ge08pfz4wuk is the encoded password. The encoded salt/password could just as easily have been kbeMVnZM0oL7I and the two are exactly the same password. As was stated earlier, there are 4096 possible encoding combinations for the same password.

Once the shadow password file is installed, the /etc/passwd file would instead contain the entry:

user name:x:503:100:Full Name:/home/user name: /bin/sh
The x in the second field in this case is a place-holder. The format of the /etc/passwd file did not change. It no longer contains the encoded password. This means that any program that reads the /etc/passwd file does not actually need to verify passwords and it will operate correctly. The passwords are now relocated to the shadow file /etc/shadow.

Format of the Shadow File
The /etc/shadow file contains the following information:

user name:passwd:last:may:must:warn:expire:disable:reserved

where

user name = the user name

passwd = the encoded password

last = days since Jan. 1, 1970 that password was last changed

may = days before password may be changed

must = days after which password must be changed

warn = days before password is to expire that user is warned

expire = days after password expires that account is disabled

disable = days since Jan. 1, 1970 that account is disabled

reserved = a reserved field

Auditors must review the implementation of shadow password files in UNIX/Linux implementations. It is important to note that this UNIX audit guide is intended only to spur auditors to look at the potential areas that should be reviewed because there are many versions of UNIX as well as a great number of applications supported by it. Here are three specialized Web sites that may provide some guidance on auditing UNIX password files:

www.ISACA.org

www.sans.org

www.auditnet.org