Mac OS X Forensics
Never give up, the answer is right in front of you...
-
Our Sponsors
-
Custom Search
Passwords and
the Shadow File
Passwords in Leopard are handled in a very secure manner. Very secure until insecure services are mixed in! Let’s take a look at how a user is identified on a Leopard system, and where the password hash values are kept for a particular user.
First, look at this image:
System Preferences - Accounts - Advanced Options Window
Most important in this image is the UUID (Universally Unique Identifier). Each user on a Macintosh system is assigned a UUID. Now look at the contents of the directory: /var/db/shadow/hash/
Password Hash Files
Notice in the above image how we have pairs of files. Specifically, we have a pair that is named exactly the same as the UUID for the user “Goof”. Let’s look at the content of each of these files!
“UUID” file:
Salted SHA1 password hash
Notice in lines 2-3 the alphanumeric value. This is a “salted SHA1” hash of the user’s login password! This is the same password used for AFP (Apple Filing Protocol) logins.
What is a salted SHA1 hash? When a user account is created, a password is also assigned. It is possible that the password assigned is NULL (a blank password). The system does not save the user’s password in clear text! This would be horribly insecure. Instead, the system performs a mathematical computation called a hash. The specific computation performed is SHA1. Since all data on the computer is “digital” we can perform math with it, and what we have here is math to get hidden result. The result is hidden because we cannot take the SHA1 hash and go backwards with ease. This is because of the last piece of the security, the “salt”. Leopard uses a random 4 byte integer with each calculation. Without knowing what the “salt” was at the time of the calculation, we cannot easily go backwards in the equation as get the user’s password. Rainbow tables are difficult to form when “salt” is involved. By calculating a “salted SHA1”, even a NULL (blank) password will have a value in this file!
Now, let’s look at this same file, with another value added in:
Salted SHA1 and NTLM password hash
Look at line 1. We have a new hash now. This is the NTLM password hash. This hash is not salted. In fact, I chose this example in particular to show what a user with a blank password could look like. User “Goof” has a NULL password. The NTLM password hash will always be the same on every Mac.
Next, we need to look at the second of the paired files.
“UUID”.state file
The “UUID”.state file is a PLIST file! These 4 values are excellent evidentiary information!
Lastly, a couple of notes.
To look at all of this information, I needed ‘root’ privileges. In order to obtain ‘root’ privileges safely and temporarily, I opened a Terminal window, and typed the command ‘sudo sh’ to open a shell with root level privileges.
To open the “UUID”.state file, I first placed a copy of it onto my Desktop (‘cp “UUID”.state ~/Desktop’). Second, the file needs proper ownership by me, not ‘root’ or it won’t open. To take ownership, type the command ‘chown “your_username” ~/Desktop/“UUID”.state’. This causes the file to become yours! (Good thing you made a copy or you would make a mess of your system!)
Now, to view the contents of the “UUID”.state file, I right-clicked on the file and chose “Open With”. I navigated to my Developer Tools-Applications-Utilities-Property List Editor to open this file.
Any questions, feel free to email us!
Passwords in Leopard are handled in a very secure manner. Very secure until insecure services are mixed in! Let’s take a look at how a user is identified on a Leopard system, and where the password hash values are kept for a particular user.
Sponsored Advertisement
First, look at this image:
System Preferences - Accounts - Advanced Options Window
Most important in this image is the UUID (Universally Unique Identifier). Each user on a Macintosh system is assigned a UUID. Now look at the contents of the directory: /var/db/shadow/hash/
Password Hash Files
Notice in the above image how we have pairs of files. Specifically, we have a pair that is named exactly the same as the UUID for the user “Goof”. Let’s look at the content of each of these files!
“UUID” file:
Salted SHA1 password hash
Notice in lines 2-3 the alphanumeric value. This is a “salted SHA1” hash of the user’s login password! This is the same password used for AFP (Apple Filing Protocol) logins.
What is a salted SHA1 hash? When a user account is created, a password is also assigned. It is possible that the password assigned is NULL (a blank password). The system does not save the user’s password in clear text! This would be horribly insecure. Instead, the system performs a mathematical computation called a hash. The specific computation performed is SHA1. Since all data on the computer is “digital” we can perform math with it, and what we have here is math to get hidden result. The result is hidden because we cannot take the SHA1 hash and go backwards with ease. This is because of the last piece of the security, the “salt”. Leopard uses a random 4 byte integer with each calculation. Without knowing what the “salt” was at the time of the calculation, we cannot easily go backwards in the equation as get the user’s password. Rainbow tables are difficult to form when “salt” is involved. By calculating a “salted SHA1”, even a NULL (blank) password will have a value in this file!
Now, let’s look at this same file, with another value added in:
Salted SHA1 and NTLM password hash
Look at line 1. We have a new hash now. This is the NTLM password hash. This hash is not salted. In fact, I chose this example in particular to show what a user with a blank password could look like. User “Goof” has a NULL password. The NTLM password hash will always be the same on every Mac.
Next, we need to look at the second of the paired files.
“UUID”.state file
The “UUID”.state file is a PLIST file! These 4 values are excellent evidentiary information!
Lastly, a couple of notes.
To look at all of this information, I needed ‘root’ privileges. In order to obtain ‘root’ privileges safely and temporarily, I opened a Terminal window, and typed the command ‘sudo sh’ to open a shell with root level privileges.
To open the “UUID”.state file, I first placed a copy of it onto my Desktop (‘cp “UUID”.state ~/Desktop’). Second, the file needs proper ownership by me, not ‘root’ or it won’t open. To take ownership, type the command ‘chown “your_username” ~/Desktop/“UUID”.state’. This causes the file to become yours! (Good thing you made a copy or you would make a mess of your system!)
Now, to view the contents of the “UUID”.state file, I right-clicked on the file and chose “Open With”. I navigated to my Developer Tools-Applications-Utilities-Property List Editor to open this file.
Any questions, feel free to email us!