Update Nov. 4, 2011: John’s jumbo version now has support for cracking these hashes too.  (Thanks solardiz for pointing this out!)

Update Sept. 7, 2011: There is a better way to get at the hashes, have a look at the “davegrohl” tool (here is a locally mirrored copy of version 1.0).  I’ll leave this post up since the explanation of how this works is still relevant.

With the latest release of MacOS version 10.7, there are a lot of changes and the way that password hashes are stored are no exception.  Dave Dribin provided a fantastic evaluation of how passwords were stored in previous versions of the OS, and I won’t duplicate his work.  With Lion, Apple decided to switch to using 4-byte salted SHA2 hashes with 512 bits.  It’s a significant upgrade to how the hashes are stored, but still quite a ways short of the Linux implementation in crypt(3).  More about that later.

Apple doesn’t make grabbing the hashes an intuitive process (I won’t say it isn’t easy, because it IS repeatable, and computers make repeatable processes easy.)  So how are they stored?

In the “/var/db/dslocal/nodes/Default/users/” directory, which is only available to the root user, there are a number of “plist” files.  That’s where the hashes are stored.  But it isn’t so simple.  Extracting the hashes requires a bit of massaging.  Let’s go through the process for an example user, with the login name of “test”.

If you weren’t already aware, there are several different valid plist file formats.  The two we are concerned with are binary and xml.  The plist file holding our hashes is in binary format and needs to be converted:

bash-3.2# file /var/db/dslocal/nodes/Default/users/test.plist
 /var/db/dslocal/nodes/Default/users/test.plist: Apple binary property list
 bash-3.2# cp /var/db/dslocal/nodes/Default/users/test.plist .
 bash-3.2# plutil -convert xml1 test.plist

Inside of that file, there is a key called ShadowHashData, which contains a text string. For example: Continue reading »

I recently had an opportunity to do some testing on the iPad, I wanted to evaluate the methods for performing forensics and the ability for someone to recover data off of the device.  Apple’s security implementation on the iOS platform is pretty abysmal.  In this post I will talk a little about the iOS platform and go over some of the techniques I used to pull data off the device.  I have a few more tricks that aren’t mentioned here, and hopefully I will get a chance to type those up in the near future.

All of this information is available out there somewhere, but I didn’t find a nice complete guide of how to get at the data without permanently jailbreaking the device.  None of this is original research, and I don’t have any association with any of the software developers and hackers that built these tools.

The premise is that when performing forensics you should modify the device as minimally as possible.  This isn’t always possible, but with iOS it is particularly difficult because accessing the data requires a jailbroken kernel and a few *nix utilities.  The most common approach (at least when doing an acquisition in the field) is to use a boot disk, load an operating system into RAM and then perform the data capture.

Before getting into the details, and they are not for someone that is not technically inclined, I want to talk a little about iOS.

Some common misconceptions about iOS (iPhone and iPad):

It isn’t a PC.

• Well, it sort of isn’t, it’s a Mac, but aside from marketing distinctions it most certainly is a Unix computer–just with a interface that doesn’t allow you to do anything other than what you are told.
• According to Apple’s sales numbers, people like having a limited user interface and no control over the computer they are using.
• This leads to a assumption that the device is simple–it is not.
• It’s Darwin, essentially a trimmed down version of Mac OS X with Springboard instead of Finder.
• Once you load up some tools, you can do most things that any other Unix system can do.

Data isn’t stored on the device, everything is in the “cloud” or stored elsewhere.

• No, it has a hard drive (solid state.)
• Most applications cache everything you view, you have no control over this, once again the decisions have been made for you.
• It tracks your location (this recently made the news.)
• It has to keep a log of what you type to make predictive typing work.  Yes, it logs what you type.

It’s encrypted, your data is safe.

• Technically it is encrypted, but Apple did such a poor job of implementing the key management, the encryption is rendered completely useless.
• There IS a second layer of encryption that is new in the 4.x releases of iOS, so far it only applies to mail.app.
• Calendars ARE NOT encrypted–how much email is embedded in calendar requests in a corporate environment?  You might be surprised.
• Unless you can decrypt the keychain, you can’t get access to these files (in theory this can be done, but who knows if the videos posted to youtube are real.)
• Only applies if 4.x was installed from scratch. Upgraded your iPad/iPhone from 3.x? Your data is still plaintext.

That said, Apple actually got something right: remote wipe works like a champ.  As long as your device is turned on, and on a network, you might be able to stop someone from stealing information off of it.

Tools I found useful: Continue reading »