Kerberos ticket renewal on MacOS Mountain Lion

Jan 302013

The active directory integration in Mountain Lion is getting pretty good, certainly much better than the early 10.7 days. Several applications integrate quite well, offering kerberos single sign on, such as Safari, and the Microsoft Office apps. One thing I do not like about kerberos on MacOS is that when my TGT expired it would not auto-renew. That means Safari wouldn’t perform SSO, and some tools like Lync or Communicator would start prompting for passwords. The easiest way to deal with this is to open a terminal and type “kinit”. This would prompt for your password and will issue a new ticket.

As easy as it is, I don’t like it, so I went looking for a solution, and as luck would have it there is an easy solution. If you set this up, each time you authenticate to the screensaver, or unlock the keychain the OS will get a new ticket granting ticket, which is much better … one downside is that it will not renew the ticket if you are logged in and the ticket expires. But my screen lock timeout is short enough anyways, so it will reduce much of the pain.

Here’s how to do it … (it’s super simple!)

Open the “Keychain Access” application, and under the “Keychain Access” dropdown menu select “Ticket Viewer”.

Screen Shot 2013-01-30 at 12.59.09 PM

Once that opens, you should see some tickets … note the principle name (case matters, so it needs to match how your directory services are configured.) Click on Add, type your principle name, password, and uncheck the remember password box (that setting might cause you to lock your domain account when you change your password–depending on lockout policy.) Then click continue. It takes a few seconds to work, so be patient. Once it is added (all the other tickets will likely disappear) highlight the principle and click on the “Set as Default” button. Now when you unlock the screensaver (or the keychain) it will request a new TGT, so it’s less likely that you will have timeouts. I did find one bug … if the Ticket Viewer application is open and running when a new key is issued it will crash, and all your tickets will be deleted; so close the application before testing.

Firewire Attacks Against Mac OS Lion FileVault 2 Encryption

Apple, Forensics, Security

Sep 182011

There is some question about the extent to which Lion and FileVault is vulnerable to Firewire DMA attacks. I performed some research (full paper is available below) and can present the following results:

Retrieving plain text passwords from RAM on Mac OS Lion (10.7) can be done under most circumstances where the system is using the default configuration. But, I want to point out that this definitely isn’t a fatal flaw in FileVault 2′s design and that it is quite easy to mitigate against these attacks. Unfortunately, Lion is not “secure by default”.

Here is a quick summary of what states are susceptible to the attack:

For a more-depth discussion of why, please see the paper (at the bottom of this post.)

Stopping the Attack

Protecting against the attack is pretty simple (assuming that FV2 is turned on,) requiring three configuration settings to be modified (Fast User Switching, and a couple of sleep options.) This will protect the system as long as it isn’t running and unlocked (in which case it is insecure anyway,) and if you haven’t logged out and left the system running (I don’t have any suggestions on that one.) Here is how . . .

Continue reading »

Cracking Mac OS Lion Passwords

Apple, Forensics, Security

Sep 052011

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 »

iPad Forensics and Data Theft

Apple, Forensics, Security

May 042011

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 »

2600 Article: Don’t steal music (or how to catch an iPod thief using forensics)

Apple, Forensics, Security

May 092009

I said I would post this once it was published, and a few days ago I picked up the latest copy. This article is a bit longer than what 2600 put out, because they were space limited (yes, I tend to be verbose.) So here it is.

Music is important, especially in a noisy office. There is a girl that sits a few feet away in a cubicle, and she talks to herself all day. As if it wasn’t bad enough to be stuffed into a cubicle but the constant chatter is maddening. Honestly there are days that if I didn’t have my headphones on I could quite possibly lose it. Because of this I am usually very careful to protect my iPod like it is made of gold–and if you look at the RIAA’s assessment (cost estimate of imaginary property? Huh?) of the value of the songs on it, it is worth more than gold! But that is a different article.

It is a good place to work, they pay people well, and treat employees better than most. I wasn’t too concerned when on my way home after work when I had realized that I left my iPod plugged into my Apple at work. Of course, you being an astute reader, already know what happened. The next morning arriving at work sleepy and slow, I was half way through the first cup of coffee before realizing that my music player was gone! (Cue dramatic music.) Of course I am always misplacing things, so I spent the next half hour tearing my cube apart looking for my iPod. Nothing. Crap. Now I am angry.

I work in IT security, so my first reaction is to start putting together a incident timeline. When did I leave the office, who was still there working as I was leaving. It didn’t make sense, there was only a couple of folks left when I went home, and I KNOW that they wouldn’t steal from me. So, maybe it was just a prank–there are a few folks that might find it funny to alarm me (and probably owe me for messing with them in the past.) Without tact I ask them if they know anything about my iPod and let them know that if it was a prank that it was cool, but I would like my iPod back. No luck; I believe them when they say they didn’t take it, but would add it to their list of ways to annoy me later.

Then it strikes me, I have a critical peice of information sitting in my lap and it just might get my iPod back in my hands. It was plugged into a Mac, not my windows box, woohoo–Unix creates log entries when a hard disk is unplugged! Sure enough, the /var/log/system.log has a bunch of the following:

Sep 10 22:31:23 computer kernel[0]: disk2s1: media is not present.

So I call up the physical security folks and let them know that there was a theft. But, that I know what time it happened and because it was at night it should be pretty easy to figure out who did it. The cleaning crew comes through at 6pm (quite annoying actually) and are usually done by 8pm. So there should have been no-one in the office around the time my iPod grew legs, if anyone was there: they would look awfully suspicious. They say they will get back to me, but since I know their manager I give her a call–to ensure that key card access logs get reviewed and that the security camera recordings are preserved. About half an hour later I get a call saying they know who did it and will handle them later that day when they are scheduled to work. Sweet.

The next morning the manager of the physical security group stops by and returns my iPod unharmed. And she explains that it was a member of the cleaning crew that had come back after his shift to steal electronics. I still feel justified in not having the standard knee-jerk reaction and would give them the benefit of the doubt in the future too! He was given the opportunity to return the stolen property or we would press charges. He immediately returned the iPod during the interview. Of course the guy lost his job. The moral of the story is that stealing music is wrong ;-)

This wasn’t the first time an iPod had been stolen at the office, and it wasn’t the last either–the things are like little stacks of cash laying around, and to someone desperate for money the temptation is just too much. Because of that I decided to do a bit more research and look at what it would take to get the same results but from a Windows box. Unix users have it easy–significant happenings with block devices, such as a hard drive, at the kernel level are logged by default. For most Unix-like systems you can find these in /var/log/dmesg (or by running the dmesg command.)

But how about Windows?

But, alas Windows is the dominant OS out there and is likely to remain that way for a while. The logging on Windows isn’t that great. Sure it is configurable, but it somehow never seems to have the settings in place beforehand that make this type of work easy. I found a way to get the same results on Windows XP, under the right circumstances. Here is what I found under XP Pro SP2, it still seems to work on SP3, but does not work on Vista–sorry, as soon as the iPod is synced the disk is disconnected and you can only get a timestamp of when it was synced, not removed. Continue reading »