Safari Form Values Decryptor

James Habben

As a forensic investigator, you are likely already familiar with the artifacts left in storage on a disk from the use of a web browser. The mainstream browsers all provide, for the most part, the same functionality of things like tabbed browsing, remembering history and exposing it in date ranges, storing bookmarks for later viewing, etc.

One of those features is the topic of this blog post: remembering data that a user typed into a form field so that same value doesn’t have to be typed into that same form next time. This is generally referred to as an autofill form values feature. Firefox, Chrome, Internet Explorer, Safari, they all offer this feature, but each of them store these values in a different way.

Safari makes use of a plist file stored in the following path:
/Users/[username]/Library/Safari/Form Values

Those of you who are familiar with Apple plist files, you already know that they have a header which indicates that a file is 1) a plist file and 2) in either binary or XML format. The header of bplist00 indicates binary, while <?xml indicates XML. Take a look at the following example plist files.

If you examine the hex of the Form Values file, you will note that neither header is present. If you don’t have an OS X computer in front of you, take a look at mine.

The reason for this comes from the use of AES encryption when storing this plist file to the disk. I promise you that this really is a plist file.

Techie Alert! (Feel free to skip the boring stuff).

Apple makes use of several functions that are part of an encryption platform called CDSA. Apple has taken the open source package from the Open Group and tweaked it a bit for their own use. The good part about this, is that apple has released parts of their implementation on their open source website. The part of CDSA that does the work for us here comes from a few modules in a smaller section known as CSSM.

For example, the Open Group version of CSSM doesn’t allow for AES encryption (among others), so Apple has brought that into their implementation as noted in a customheader file.

The Mach-O binary inside of the Safari application file is a smaller executable that handles more of the functionality relating to the GUI and user experience, and is therefore written in Objective-C. The heavy lifting code is pulled in from a framework written in C and located at: /System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari

A mildly interesting note comes from the above linked CDSA Overview in the form of this note at the top of the page.

Important This technology is deprecated in OS X v10.7 and is not available in iOS. You should use it only if none of the other cryptographic service APIs support what you are trying to do.

Apple continues to use CDSA/CSSM in their frameworks, but they have deprecated it for other developers.

Welcome back!

I bet you want to know how we can use all that junk above to get these dang form values, am I right?

Apple stores a chunk of randomly generated data (32 bytes to be exact), inside the user’s keychain. You can see this on your Mac by opening the Keychain Access app, or you can look at the screen shot from mine. Sort on the name column, and look for a record titled Safari Forms AutoFill. Check the show password box, and it will display the UTF8 interpretation of the password data after asking you for the password to unlock the keychain.

This data chunk is flavored with a dash of salt, a sprig of thyme, and a pinch of paprika. Let it simmer for an hour, and viola. Oh wait, that was dinner, and a string instrument? Well, it goes something like that anyways.

The result is then used as a master key to encrypt this plist file with AES-128.  The nice part is that AES is symmetric encryption, which means the key used to encrypt the data, is the same used to decrypt the data.

Once I worked out the intricacies of this process, Simon Key (a colleague of mine) was able to put together a little package to prevent us from having to use our fingers and toes. As of right now, it requires that you copy the files out of EnCase, but I’m hoping to get it into an EnScript soon. We wanted to get this out to you instead of waiting to get it packaged up and wrapped with a bow.

Finally!

Download the utility. There are two files in there. One is a windows exe file and the other is a packaged installer file for OS X which places the executable, named sfvd, to the /usr/bin directory on your Mac, where it will be available in terminal no matter which folder you are in. The two tools are identical in function and allow you to decrypt in either OS X or Windows.

A couple notes on sfvd:

1. It is a signed package but you may need to bypass the Gatekeeper security to get it installed. Right click (secondary click) on the package, then hold down the command (⌘) key and click on Open.
2. It was developed and tested on 10.8. It will work against Safari files in earlier versions (I’ve tested 10.6), but it may not run on earlier versions.

The next step is to copy the two files from your evidence file. Put them in a location that is accessible to your examination Mac. I created a new folder at /Users/james.habben/Documents/safari forms.

The user keychain:

/Users/[username]/Library/Keychains/login.keychain

The form data:

Users/[username]/Library/Safari/Form Values

Open the Terminal app, and navigate into the folder where these files are located. Type sfvd in terminal and you will see some basic help text.

• <user_keychain> This is the fully qualified path to the login.keychain of the user whose data you are examining. Not using a fully qualified path will result in an error.
• <encrypted_form_values_file> This is the relative or absolute) path to the Safari Form Values file that you want to decrypt.
• <output_file> This is the path (relative or absolute) to write the decrypted Form Values plist file. (I suggest a .plist extension)

You can run this against your own Safari and see what you have been up to lately. If you run this against your own files, OS X will ask you to allow sfvd access to your keychain.

Try this command:

sfvd ~/Library/Keychains/login.keychain ~/Library/Safari/Form\ Values output.plist

When you run sfvd against a keychain that you have extracted, then the keychain has to be unlocked before the data can be accessed. OS X will ask you for the password to unlock, and then ask you to allow access. This password is typically the same as the user login, though it can be made to be different. This prompt will still show even if the password is blank (so try blank!).

You should have xcode installed already on your examination Mac, so a double click on that plist file will bring up the plist editor.

Another option to view the plist data is to bring it back into EnCase as a single file, and then use the PlistViewer Plugin from App Central to view the data.

The integer value in each of the folders represents the date of the last time a value was stored into this collection. The format is in Mac Absolute Time.  The tool Dcode from DigitalDetective will decode the value.

You can download my sample login.keychain and Form Values file here.  I even included the decrypted version for those of you that don’t have access to a Mac right now.

You can download the sfvd tool here @ EnCase App Central:

http://tinyurl.com/nvtlu6k

Sample download:

Form Values File