Get into OS X account without password and without killing the keychain?
March 29, 2010 7:31 PM   Subscribe

I would like to get root access on a Macbook Air running Mac OS X 10.5.8. Bonus points - without nuking the existing keychain.

A friend and co-worker passed away recently, and I'm trying to get into their account on their computer, a Macbook Air. I know that they'd be OK with this, and I have their spouse's OK as well.

One of my tasks is to recover access to their keychain. I know that the user favored short passwords from a limited alphabet, so I think this is doable. I have other goals, but first, here's what I have to work with.

I have physical access to the machine, and a guest acccount as well.

- The user's account is still logged in and running
- Mac OS X 10.5.8
- filevault is off
- VM is encrypted
- I am logged in as Guest
- I have physical access to the machine
- There is almost certainly not a firewire password
- The user's password may be as short as 5 characters
- Security Update 2010-002 has not been applied
- I have a possibily complete backup of the user's directory

Ideally, I'd like to be logged in as the user, with access to their keychain.

The user's account was logged in until today when we unthinkingly switched to the Guest account and were then prompted for a password to return to the user's account. Is there any way to see if this account is set for auto-login without a password on boot without actually rebooting?

Less than ideal: recover password file and then recover the user or root password using a brute force tool.

Less2 than ideal: establish a secondary account with administrator privileges, or escalate the guest account to admin.

I'm generally knowledgeable about computers and OSs, and fine with trying scripted attacks that exploit known bugs in the OS.

I realize that others could use this information for unethical or illegal purposes. That's not the case here, but I understand if anyone would prefer to correspond with me directly vs here, contact me via my MeMail.
posted by zippy to Computers & Internet (31 answers total) 5 users marked this as a favorite
If you can stand changing the password: this may help.

Alternately, AppleJack has a hidden expert mode (type "x" at the menu) that will turn auto-login off; I don't know if it works the other way. It's just a shell script, so you should be able to look at the source and see what it's doing there.
posted by Pinback at 7:52 PM on March 29, 2010 [1 favorite]

You need to do two things: first, extract the encrypted passwords from the NetInfo database. Second, crack the encrypted passwords by brute force trial and error.

A tool that can help you with this is John the Ripper. The Mac version includes a tool for extracting the passwords, and then you can use John to brute force the recovered encrypted passwords.

While I have never done this against Mac passwords, I have used it against Windows and Linux passwords many times. For a short password, cracking should be easy. I haven't used the Mac password extraction tool, though, so I do not know what kind of access you might need. If you can create a separate Admin account, it should suffice, I suspect.

Good luck, and I am so sorry for your loss.
posted by procrastination at 7:58 PM on March 29, 2010

Response by poster: Hi procrastination, thank you, I didn't know the route to the passwords on OS X. I assume I need an admin account to get the Netinfo db? I don't currently have access to one. I do have full access to the filesystem however, and could load the data onto a machine on which I do have root access if this would let me extract the password db.
posted by zippy at 8:02 PM on March 29, 2010

As for autologin, you can check defaults read /Library/Preferences/ and see if there's a autoLoginUser key there. I don't know where the user's password is stored if autologin is enabled, though. A little poking around suggests it's in /private/etc/kcpassword — it's not in cleartext, but presumably there's enough info there to decrypt the keychain contents.
posted by hattifattener at 8:14 PM on March 29, 2010

Here's an easy way to enable root user using single user mode.

Once you've done so, log in normally as root and go to System Preferences and go to Accounts. I don't have my laptop on me so the verbiage may be off, but there'll be a password section with a possible password hint entered by the user. See if there's one. Root access (or firewire for the matter) allows easy access to backing up his home directory just in case.

In the same area, there will be a section for login options. Check here to see if autologin is on. I've never tried, but you can always try turning on autologin for that user without knowing their password since you're logged in as root and see what happens.

And to answer one of your questions directed at procrastination, logging in as root will get you the privileges an admin user would have.
posted by jmd82 at 8:26 PM on March 29, 2010

Best answer: I was just looking around, and it seems that the NetInfo database went away while I wasn't looking. Instead the passwords are stored in a file in /private/var/db/shadow/hash. If you can mount the drive somehow so you can read that, you can get the encrypted hashes out of that directory.

For cracking them you could buy the professional version of John the Ripper for OS X. It seems to be about $40.

Or you can take a look at this blog post:

It seems to make sense to me, though I have never done it. You definitely need admin access to the file system to get the hashes out. It is more work that the John package. I just tested what is in there, and the command:

dscl localhost –read /Search/Users/username | grep GeneratedUID | cut –c 15-

does tell you which file in the /private/var/db/shadow/hash to look at for a particular user's hash. Replace username with the account name. I was able to run that without admin privileges, so you might can do that from the Guest account before you shutdown to mount the volume.

Then get access to the file with the name extracted above, and run this command with result being the long string produced above:

cat /var/db/shadow/hash/result | cut –c 169-216

If you want, I have a pretty powerful Mac Pro I can use to try and crack the passwords if you can extract them. It might be a day or so before I get it up and running. You can MeMail me if that will help.
posted by procrastination at 8:30 PM on March 29, 2010

Best answer: If I were in your place, I'd simply reboot to see if the account will auto login, and if it doesn't, then I'd recover the passwd file (actually a dump of the local ds store) and crack it. In my experience, that's your best bet, and it's pretty easy when you have full control of the machine like you do.

I say to crack the password rather than to replace it because most folks leave their keychains set to auto unlock at login, and further, the login pass is generally the same as the keychain pass. If you instead replace or remove the user's login password, you'll destroy the hash for that original password, and I'm not aware of a good way to brute force a keychain password, so if you nuke the hash for the password, you will (as far as I know) be destroying any chance of getting the keychain data back.

To get access to the hash, you could simply enable the root account by booting into the installer and using the password reset utility on it. You're then clear to log in to the OS as root, and fire up Terminal to do the cracking. If the owner really preferred simple password, it will likely only take seconds for the actual crack.

There are pretty good instructions here, which will walk you through all but getting the root account up and running.

On preview: I was beaten to it. Also, you won't be able to enable auto-login for the user if you log in with root - you'd need to know the password to do it. And the free version of John will crack it just fine, so don't feel like you have to buy the pro one.
posted by unsound at 8:33 PM on March 29, 2010

Best answer: Quick follow up - jmd82's link is somewhat outdated and refers to OS X 10.1, based on the build number included within. The nidump command was removed in version 10.5, and can no longer be used to dump the password hashes. I would also avoid changing the user password you are interested in. I am not convinced it will change the Keychain password as well, and you risk overwriting the hash before you can get it for cracking.
posted by procrastination at 8:35 PM on March 29, 2010

Best answer: And to be really paranoid, I would try and dupe the whole disk ahead of messing with things, if you can, just to have a backup.

Ok, gotta go to bed. Good luck! Please let us know if it works, I am very curious now.
posted by procrastination at 8:37 PM on March 29, 2010

Good call, procrastination. It's been a while since I've had to do that.
posted by jmd82 at 8:57 PM on March 29, 2010

You can easily change the password for this account by booting into single user mode (hold down Cmd-S during bootup). When you get a prompt:
  1. Type fsck -fy
  2. Type mount -uw /
  3. Type launchctl load /System/Library/LaunchDaemons/
  4. Type dscl . -passwd /Users/username newpassword(replacing username and newpassword with the appropriate info)
  5. Reboot and log in as the user with the new password.

posted by pmbuko at 9:53 PM on March 29, 2010 [2 favorites]

Best answer: To determine whether the computer is set to auto-login, run this command:

defaults read /Library/Preferences/ autoLoginUser
posted by pmbuko at 10:00 PM on March 29, 2010

Changing the account's password won't allow you to read the contents of the keychain, though, which appears to be zippy's real goal; that's why I looked for the kcpassword file.

Presumably, if the user's keychain is currently unlocked, it would be possible to dump the memory of the relevant security daemon and extract the keychain's password from its memory image. That's a kind of theoretical possibility though.
posted by hattifattener at 10:45 PM on March 29, 2010

Response by poster: The user's keychain is not unlocked. That is, when I did have access to their account yesterday, when I tried to open items in the keychain, it prompted me for a password.

hattifattener, re autologin, here's what I see:

$ defaults read /Library/Preferences/
RetriesUntilHint = 3;
lastUser = loggedIn;
lastUserName = Guest;
showInputMenu = 1;

posted by zippy at 2:10 AM on March 30, 2010

Response by poster: unsound writes: I say to crack the password rather than to replace it because most folks leave their keychains set to auto unlock at login, and further, the login pass is generally the same as the keychain pass. If you instead replace or remove the user's login password, you'll destroy the hash for that original password,

Yes, I would like to get into the keychain, and I am fairly sure the user used the same password for login and keychain access. So I think this means that any attempts I make at escalating my access should not involve reseting the user's current password.

procrastination writes: to be really paranoid, I would try and dupe the whole disk ahead of messing with things

Good idea! Is there a simple way to invoke dd to do this, or should I just tell Carbon Copy Cloner to make a full image backup?
posted by zippy at 2:18 AM on March 30, 2010

Just have CCC do it.
posted by edd at 3:06 AM on March 30, 2010 [1 favorite]

I normally use dd or dcfldd to dupe disks, but carbon copy cloner should work. Then you can try different things and if they don't work, restore to the original state. I would bet that cracking the password will work, though, based on what you said.
posted by procrastination at 5:28 AM on March 30, 2010 [1 favorite]

I think you may be making this more complicated than it needs to be.

That link has instructions on resetting an admin password for a Mac. For a mac with an optical drive, this is as easy as booting up with the latest install CD and using the password reset utility. It's a little more complicated with a MacBook Air, but if you've got another mac around with an optical drive, you should be fine and the link addresses this for you.

Once you've reset the password for the account, you should then have access to the keychain via the Keychain Access utility, which will allow you to display any passwords stored in there. You will probably have to have the system change the keychain password to match the new admin password, but that should not be a problem.
posted by ursus_comiter at 7:27 AM on March 30, 2010

ursus_comiter, I saw that when I was poking around last night, but I also saw this:

which implies that changing the admin password that way does not change the keychain password. I would think, though I haven't tested it, that at that point you would need the old password to get into the Keychain. Unless I am missing something?
posted by procrastination at 8:23 AM on March 30, 2010

I believe that what happens is that when you're logged in to the account and do something to access the keychain, the system will reset prompt you for the current admin password and after receiving that will then reset the keychain password to match it.
posted by ursus_comiter at 10:38 AM on March 30, 2010

Strike the word reset from that.
posted by ursus_comiter at 10:38 AM on March 30, 2010

The first instance.
posted by ursus_comiter at 10:39 AM on March 30, 2010

Although that's not what the support document says. I wonder what happens if, after you've changed the account password that way, you then change it again using the Accounts panel in System Preferences.
posted by ursus_comiter at 10:42 AM on March 30, 2010

No, if you reset the login password while booted from the installer, the keychain password will not get changed. You only get prompted to update its password if you change the login password while logged into the account - i.e., during a legitimate, user-initiated password change. If the two get out of sync, the system can't change it.

I looked around some more, and there's at least one program out there intended to brute force a keychain: CrowbarKC. That said, I have no experience with it, but have had good results from recovering the login password via the methods in my last comment.
posted by unsound at 2:02 PM on March 30, 2010

Response by poster: Followup question - so this being a Macbook Air, there's no firewire port or firewire mode, so if I want to make a complete image of the disk, can I do that from single-user root more? Or is there some other method where I can bypass the Guest account restrictions to copy the whole darn disk at the low (dd) level?
posted by zippy at 2:46 PM on March 30, 2010

Yeah, that is going to be a pain. Some forensics people I know take the drive out of the laptop and mount it in a USB or Firewire enclosure, but that might be overkill for your purpose. I would try one of two things:

- Get a USB hub and put a CD drive on it, then boot from CD. The hub is so you can also have an external USB drive to copy to. This keeps you from booting from the drive that you are trying to copy. Not a big deal in this case, most likely, but it is the cleaner way to do it

- Boot into single user mode with an external USB drive to copy to. You will probably have to put the dd program on the external drive if it isn't installed, though my mac has dd in /bin/dd.

In either case, be really careful about the dd command lines. It is easy to make a mistake that will cause the laptop disk to get overwritten from the external drive.
posted by procrastination at 5:47 PM on March 30, 2010

Best answer: If you've got another Mac, and an external USB drive, I'd try this:
Use the secondary machine to share a Mac OS X install DVD with the Air. Once the Air is booted from that, and the USB drive is connected to the Air, fire up Disk Utility. In Disk Utility, select the Air's hard drive (probably "Macintosh HD"). Next, go to the File menu, and choose New… -> Disk Image from "Macintosh HD". Choose to save the image to the USB drive, and you're good.

This method is slower than using CCC, but will make a faithful image which you can use to undo anything bad that happens by way of Disk Utility's restore option.

I've never tried this in this specific setup (and, in fact, have never booted an Air via disk sharing) but if disk sharing behaves like I think and gives you the same options as booting from a local install DVD, it should work.
posted by unsound at 7:13 PM on March 30, 2010

Response by poster: - Boot into single user mode with an external USB drive to copy to. You will probably have to put the dd program on the external drive if it isn't installed, though my mac has dd in /bin/dd.

Good point, procrastination. If possible, I would mount the source disk read-only before running dd.
posted by zippy at 8:28 PM on March 30, 2010

Response by poster: unsound, that's an awesome Rube Goldbergian idea re USB and DVDs. I like it!
posted by zippy at 8:30 PM on March 30, 2010

Response by poster: Summary: Thank you everyone. I recovered the user's login with the suggestions posted here.

This is what I did (after several wrong turns)

- enabled Remote Install Mac OS X on a second Mac
- booted Macbook Air holding down option

note: I had to disable WPA on my wireless network for the Air to be able to login to the network. It could not successfully use my network's password.

- wait a loooong time to boot over wireless
- on the Air, select Utilities and run the Disk Utility
- make a read-only DMG of the hard drive and save onto an attached USB drive
- now, eject/unmount USB HD and shutdown air
- mount new drive image on 2nd Mac
- use procrastination's tips to find password on mounted image
- create a dummy password file containing password hash
- feed it to John the Ripper, using Openwordlist's "all" dictionary

Less than one second later, I had the password :0

Unfortunately, my friend used a different login and keychain password, so now I'm running a dictionary attack on the keychain file using CrowbarKC and the 'all' dictionary above.

CrowbarKC doesn't appear to do creative mangling of the dictionary input, unlike John the Ripper, so I think it's unlikely to find the keychain password. Also, it's slower than John the Ripper. Eyeballing it, I'd say it does 50 password attempts a second on my machine. John the Ripper did over 360k password attempts in under a second. Not to bash Crowbar, just saying that it takes longer.

Thank you again for all your help. You made my day and helped out my friend's spouse, too.
posted by zippy at 11:20 PM on April 6, 2010

Thanks Zippy and Proscrastinator! I'm stuck after mounting the drive image on 2nd Mac. Procrastinator's tip can help me get the password file on my 2nd Mac, but how to craft dscl command to query the mounted image?

Right now, using:
dscl localhost –read /Search/Users/username | grep GeneratedUID | cut –c 15-

which again return files for the 2nd Mac, not the mounted disk.

Can you help?
posted by gottaknow at 6:45 PM on August 29, 2010

« Older help me install my monitor sans cd   |   I'm looking for "badges" from other environmental... Newer »
This thread is closed to new comments.