OS X allows a user to select one of three ways to login to their account. Login options can be set in the Accounts preference in the System Preferences application. There are three different methods that we can use to log in on a Mac: List of users, Name and password, and Automatic Login.

Figure 1 Login Options

Probably the most widely used method of logging onto a Mac when there is more than one user is the  “List of users”. The list of users shows the name of the users and their icon, which is selected upon creation of the user account. In order to login to the account, one only needs to click on the icon and then the password window will open which enables the user to type in the password and gain entry to their account.

Figure 2 List of Names

A more secure option is the “Name and password” login. This method provides only a login window that has an area to type in a username and the password. There is no other information such as a list of users that can be used for social engineering in order to gain access to a user’s account.

Figure 3 Name & Password

By default with a new Mac or a fresh installation of Mac OS X, the automatic login is turned on. Automatic Login bypasses the need to login and allows the computer to boot straight into the users Home account. There is no requirement to authenticate or other security function associated with the automatic logging for access to the Home folder. As mentioned on Inside the Core, the episode on hardening your Mac, it’s wise to turn off automatic login because of the potential for full access to your user account if the laptop is stolen or lost.

So what happens when automatic login is turned on? When the user is selected, an authentication window is opened and the password for the user must be inputted. Once the authentication is successful, the /private/Library/Preferences/com.apple.loginwindow.plist is amended to show the automatic login user.

Figure 4 com.apple.loginwindow.plist

Once the plist has been updated, a file, kcpassword, is created in the /etc folder. The kcpassword file holds the login password for that automatic login user only. Just looking at the file will not reveal much other than a string of hex characters. The user password is encrypted using XOR, or exclusive or. XOR is an encryption algorithm that combines two binary strings to create a 3^rd encrypted string. The encryption method is very weak and decoding it, once the key string is known, is simple.

Figure 5 hex editor view of the kcpassord file

Gavin Brock decoded the kcpassword file and stated in his blog [iii] that the file uses an 11 byte pattern that repeats depending on the length of the password. The password itself uses a 12 byte string. This means that if the password is 11 or less characters, there will only be 12 bytes shown in the kcpassword. If the password were 12 characters in length, then there would be 24 bytes used and if it were 25 characters long, the kcpassword would show 36 bytes used.

Figure 6 Example of a 11 character password

Brock provided the key string that is used to decode the user password. The XOR key 11 bytes are as follows:

0×7D  0×89  0×52  0×23  0xD2  0xBC  0xDD  0xEA  0xA3  0xB9  0×1F

Just by looking at the XOR password, you can’t tell where it stops and the salted data begins. By matching the password byte by byte with the key string we can tell where the password ends by looking for the same hex byte in each string. An example of this would be the following:

Key = 0×7D  0×89  0×52  0×23  0xD2  0xBC 0xDD  0xEA  0xA3  0xB9  0×1F

Pwd= 0×15  0xEC   0×3E  0×4F  0xBD  0xBC 0xBA  0×2C  0xCA  0xCA  0×4E  0×82

As we look from left to right, we see that the 6th byte of each string is the same. This represents the null and the end of the password. This means that the password is 5 characters in length. The remaining hex values to the right of the null appear to be of no value to us.

How do we decrypt the password using the key string? As an example, lets say that the first byte in a password is 0×0D. 0×7D is the first byte in the key string for the XOR operation that is used to decrypt the kcpassword. If we break both down to their binary equivalents we can easily break the encryption for the first byte.

The result is achieved by comparing each of the bits. In XOR, if two bits are the same then they are False (0). If the bits are different, then they are True (1). As we read across the above table we see the following;

1 = 1 XOR 1 = 0                         16 =  1 XOR 0 = 1

2 = 0 XOR 0 = 0                         32 =  1 XOR 0 = 1

4 = 2 XOR 1 = 0                         64 =  1 XOR 0 = 1

8 = 1 XOR 1 = 0                       128 =  0 XOR 0 = 0

When we convert 01110000 to hex we get 0×70, further converting it to ASCII gives us the first letter of the password, “p”.

While we can do this for each of the characters in the password, an easier way is to use a programmer’s calculator, such as the one that is native to OS X. The following is the way to setup the calculator and decrypt the password:

1. Setup the calculator so that it is set to 16 and ASCIII

2. First, type in the first byte of the key string, then click on the XOR

3. Type in the corresponding password byte & press return on the keyboard

4. The ASCII character will be presented

By first inputting the XOR key string, one byte at a time, we convert each password byte to ascii. The following is the result:

Here is an example of a longer password and how the XOR key string repeats itself. The password is 13 characters length so it uses 24 bytes in total.

The ability to decode the kcpassword file may have a limited impact for us forensically. Auto-login enabled provides the ability to boot a restored drive or a VM and gain access to the user account and open the login.keychain. It would be of help if perhaps the image were not bootable such as with an unmountable file system, which if you have been doing Mac forensics for any time you have run into at least once. In this instance, attaining the login password for the user would allow for the opening of an extracted login.keychain, which may provide additional needed passwords to DMGs, secure notes, and wireless networks.The kcpassword will only reside in the /etc folder while Automatic Login is turned on. If the user who has Automatic Login is changed to another user, the prior kcpassword file is deleted and a new file with the XOR encrypted password is created. When Automatic Login is turned off, the file is deleted from the /etc folder.

http://www.occam.com/osx/OSX_Sec.pdf

[ii] Apple Mailing Lists, August 13, 2004. /etc/kcpassword.

http://lists.apple.com/archives/student-dev/2004/Aug/msg00111.html

[iii] Brock, Gavin. Encoding & Decoding OS-X Auto-Login Password (/etc/kcpassword).

http://www.brock-family.org/gavin/perl/kcpassword.html

Ryan has been doing some good things at MOSXF.com, check out the metadata extractor. The site is usually updated at least once a week with new info.

We release a new podcast episode in mid March. We hope to have another recorded this week and released by the weekend. I am working on a video series that will show some of the topics that we cover on the podcast. I also hope to have the SQLite Manager video updated and posted soon.

Be safe,
Dave

SQLite Manger is a database management tool that allows us to open and view the many SQLite .db files that are on a Mac and the iPhone. The thing I like best, so far, is that I am able to see the actual image located in the blob data from a Safari cache.db file and the originating url information in one place.

I know we can use different software suites to do this but some of those may be out of our budget. Tools like SQLite Manager and SQLite Database Browswer 1.3 are examples of free or low cost tools that we can keep in our Mac forensics toolbox and not have to shell out a lot of money.

SQLite Manager by SQLabs

The discount code:

Be safe,
Dave

We are lucky to have Ben Charnota of BlackBag Technologies talking about their new software write block solution, Soft Block. Soft Block is a fire and forget write block solution for Macintosh computers. Once started, it runs quietly in the background until an external media is inserted into the computer. Soft Block then prompts you to mount the device Read Only or Read/Write. I have been running the demo version of the software on my MacBook Pro for a couple of weeks and forget it is there until I plug in a drive. The Soft Block prompt isn’t bothersome, it only takes a second to deal with and you are on your way. The nice thing about Soft Block is that, coupled with your laptop, you are ready to respond to the field with your preview system and a write blocker in one unit.

I will be doing a more in depth review of Soft Block and will post it on our sister site, MacOSXForensics.com.

Chris talks about the com.apple.recentitems.plist in this episode’s Plist of the Week (PLoW).  By default, each section, Applications, Documents, Hosts, & Servers, will have 10 entries. This can be modified in the System Preferences > Appearances section or by using Plist Editor to change the values. This is usually one of the first plists we look at during an examination. The Recent Items plist will show the last items, which were accessed by the user, such as programs, images, movies and documents. It is a good indication of what he/she was up to prior to the seizure or imaging of the computer and could be the smoking gun. I like to restore the drive, as part of my analysis, and then take a screenshot of the Recent Items menu, as the user would see them. As they say, a picture is worth a thousand words.

We take a good part of this show to talk about the basics of how we prep a Mac to become an analysis system. The first thing that should always be done is the installation of the Apple Developer Tools. The Developer Tools provides us with several programs and commands that will be of great use to us when we start our examinations. The most useful is the Plist Editor, which allows us to see a plist in an easy to read format. The newer versions of the Plist Editor allows us to print the plist while older versions had the ability to do a data dump, which allowed us to copy the code for review. Essentially, if you aren’t using Plist Editor or the third party, Plist Editor Pro, you are doing yourself a disservice. Another good tool that comes with the Tools is the GetFileInfo command. A Terminal command, GetFileInfo provides a number of arguments, which will allow you to retrieve file data such as creation/modification dates, creator code, file type code and file attributes.

Be Safe,

Dave