Cracking OSX Lion passwords | Hacker News Reader

Cracking OSX Lion passwords

defenceindepth.net

281 pointseis79 comments

Two points:

1. When it comes to security, from the point of view of an OS vendor, if you have gained unauthorized access to an interactive shell on a target machine it's already "game over, man". You cannot protect against physical access, and you can pretty much assume that there are a plethora of unknown privilege escalation bugs so that any account is effectively a root account. Every company has limited security resources, and at some point there are trade-offs between usability and security. This is why efforts are typically focused on keeping the baddies out.

Once the bad guy gets in, you can only mitigate potential harm. This is the goal of things like File Vault (which will still protect your stollen laptop, assuming you put on a screensaver password). This is also why merely being able to change a password is not nearly as bad as...

2. Being able to recover the plain text of a user's password. I'm not going to discuss how or why, but this was possible on earlier versions of OS X and fixed only in Lion. In this regard, "cracking" passwords is much harder on Lion than it was on Snow Leopard and earlier.

Of course, that sort of level-headed approach to this kind of topic seems to be rarer and rarer on HN these days...unfortunately...

any account is effectively a root account

I'm no security expert, but that doesn't seem right to me.

He means "any account with local access" is effectively a root account, which is true. Resetting passwords is trivial when you can reboot and have an install disk.

Think of any system as a castle. Having access to an interactive shell is like standing outside the King's bedroom. Sure, you might not have the keys to the bedroom door, but you've already made it past the archers, the moat, the drawbridge, the boiling oil, and the King's personal body guards. You don't put a 3 ton door on the King's bedroom and say, "Well, that should keep the invading army out!"

No, you strengthen all of the defenses leading up to the door so you never have to worry about just how strong that door is. That's not to mention that the King probably doesn't appreciate having to swing a 3 ton door every time he wants to go to sleep.

Same idea with computer security. Only give accounts to trusted individuals. Assume anyone with an interactive shell can quickly gain root access. Physical access is even worse. If you can sit at the keyboard, then you control everything. This is why most banks have key servers locked in real physical vaults with 3 ton doors.

Honestly, I'm a little surprised. This is all "Computer Security 101" level stuff here. Getting worked up about "cracking" passwords given local access is akin to worrying about someone spying on you when you visit this site: http://www.josephcrawford.com/2006/11/11/scary-isight-trick/ . If you want some real security research meat to sink your teeth into, the pwn2own contests are always pretty good, especially the most recent one (http://arstechnica.com/security/news/2011/03/pwn2own-day-one...). You might notice, if you read about the pwn2own contest, that the contest is over as soon as the exploit runs arbitrary code on the local machine and successfully breaks out of the application sandbox. At that point, you're knocking on the door...

That an attacker has physical access does mean that your computer is compromised, so you're half right.

If you seriously think having an account on a machine is as good as having the root account, then you should call up every shared hosting provider and let them know. They hand out accounts to any asshole with $10.

I haven't used shared hosting providers in years... but when I did, very few of them allowed shell access, and for very good reason.

Even a properly secured system can be vulnerable to known and unknown privilege escalation bugs.

jballanc didn't say you can't guard against privilege escalation. He said, assume you can't. The point is subtle but important: given limited resources, you should allocate the majority of them to keeping the hacker off your system in the first place.

I'll leave it as an exercise to the reader to compare and contrast the entirely different use cases between a shared hosting server and a desktop machine running OS X.

I can create an account on the machine without having root access. Which gives me a shell. Which means I can exploit a flaw to change root password. Which means I have access to cookies and other fun things. Which means I can probably access that person's gmail which is pretty much game over, man.

Bedroom analogy is wrong. The computer is the castle. They have it. The problem is that your lord knows the secret entrance to your main castle (in the cloud). You want one of two things to happen: Keep the lord safe, or kill the lord so his secrets are gone with him. The attacker formatting the machine, or replacing the hard drive is fine, he already physically has it, just like he can take the vault and throw it outside and make a new one. However you don't want him accessing that vault.

You can also just boot your Mac in single-user mode (Command-S), then mount the main filesystem and type "passwd bob". Much easier and produces the same effect.

That risk level is not at all on par with this though. That won't help with filevault turned on, and it requires both a reboot and a physical presence at the machine. This can be done remotely with shell access, and discloses hashes from other accounts.

This also won't help with filevault turned on.

In other words, it can be done remotely through a browser exploit.

Unless the Mac has a firmware password. You could just remove that by resetting the PRAM, unless you wanted to go undetected. In that case, you could remove the hard drive, mount it elsewhere, and change the password hash. Is FileVault plus a firmware password the only safe way to keep your Mac?

FileVault by itself is sufficient, at least with Lion. Even if you're able to boot the machine or mount the HD, you'll need the user's original password to decrypt the data. The Password Reset app is useless until you first unlock the encrypted drive.

(I'm pretty sure that pre-Lion's FileVault is in the same case, where you'll still need the user's old password to decrypt their home directory's encrypted dmg, but I'm not 100% certain.)

Enabling Open Firmware password protection disables the ability to boot a Mac into single use mode; it also disables booting from an external hard drive, flash drive, etc.: http://support.apple.com/kb/HT1352

TL;DR:

There is no need to crack the password. You (as non-root user) can just reset the currently logged in user's password by calling:

dscl localhost -passwd /Search/Users/bob

Not any, but the currently logged-in user.

Thanks for the clarification!

Has anyone tried this yet? One of the comments on that blog mention you still have to enter to old password in order to reset.

$ dscl localhost -passwd /Search/Users/bob

New Password: *

Permission denied. Please enter user's old password:

If you are currently logged in as alice, this is correct. However, if you are logged in as bob, you are not prompted for the old password.

In the article, it mentions that the password are hashed using SHA-512. As has been mentioned before, using such a fast hashing scheme for passwords is a terrible idea. Any idea as to why they do it this way? (instead of using bcrypt)

Because it just works.

You're using an apple product. When did they ever claim to be secure? Your life is easier, more magical, full of glass, and very fast! Security is... a little bit of whipped cream on top. So enjoy your gestures on that magic touchpad, don't worry about being safe.

(Sorry, I couldn't resist)

Apple doesn't ignore security, they advertise security enhancements in their products:

"Address space layout randomization (ASLR) has been improved for all applications. It is now available for 32-bit apps (as are heap memory protections), making 64-bit and 32-bit applications more resistant to attack."

"Application sandboxing protects the system by limiting the kinds of operations an application can perform, such as opening documents or accessing the network. Sandboxing makes it more difficult for a security threat to take advantage of an issue in a specific application to affect the greater system."

Part of OS X Lion's new features: http://www.apple.com/macosx/whats-new/features.html#security

Erm... I forgot I was in a place where preemptively apologizing for making a joke isn't enough for people to think you're joking.

I would like to point out though, that the text you just copied are pretty much apple's only words on the topic.

To further my joke even more:

Google search for "easy" on apple.com [1] returns 3.3 million results. Google search for "secure" on apple.com [2] returns .5 million results.

On the internet easy returns 3.6 billion results, and secure 1.25 billion. So on the apple site, you would expect easy to show up 3 times as much as secure. In fact, easy shows up over 6 times as much as secure.

This definitely proves apple cares about security only half as much as the rest of the internet does!

Does netcraft confirm that?

checking netcraft is left as an exercise for the reader

There's a difference between recognizing a joke, and thinking it's funny.

Let's see how much karma I can lose in one thread.

There's a difference between not thinking a joke is funny, and arguing against it as if it weren't a joke, a la tiles.

I downvoted not because you joked, but because you made patently untrue claims and then backed them up with a very poor methodology. So poor that you can't simultaneously be smart enough to read and understand this site and dumb enough to think it's logical to argue this way.

I conclude, therefore, that you're trolling.

I wasn't talking about the downvotes, that's to be expected. I was talking about the humorless replies :)

If we all acted our IQs, all the time, the world would be a very boring place. It's not responsible to buy myself expensive toys, it's not respectable to be sarcastic. Yet we do it anyway.

Trolling is meant to make people angry, I meant to to get a chortle out of at least somebody... but now I know, beyond a shadow of a doubt, that this is not the site for that. Thank you for helping me realize it.

Joking is fine -- as long as you make a point and contribute to the discussion. Throwing out some one-liner about Apple security is not a valuable contribution, and then yes, your jokes weren't funny either.

It's bad, but it's not that bad. SHA is widely supported, and not that bad, yet.

Also this is protecting desktop computers, where cracking hashes is not a common security problem. Getting the machine stolen in starbucks is probably much more common for this type of machine.

Macs are not used exclusively as desktops.

It would be interesting to see if this was possible in OSX Lion Server.

Server is no longer a separate product. I have Server installed on this desktop and the example command works as described.

No exclusively, no. But massively. I'd guess, what 90%, of OSX installs are desktop/laptop/residential market/

Despite all the ranting on HN about bcrypt, pretty much no one actually uses it. Not linux, not windows, not apple.

OpenBSD uses it :)

No, OpenSUSE for example is using bcrypt.

See: http://www.openwall.com/crypt/

Most everybody uses some form of slow hashing. Bcrypt is a particularly secure and convenient form of slow hashing, which is why people recommend it so much, but there are other schemes possible. For example, you can take a cryptographic hash function and iterate it a few thousand times.

Apple uses a key strengthening algorithm on their passwords, similar in concept to Bcrypt - I think they've increased the number of rounds past the 1000 mentioned since this paper came out: http://people.cis.ksu.edu/~sakthi/src/data/filevault_sakthi....

If you've already compromised an account and have access as that user, it's likely that what you're going after isn't going to be their password...

... although, if you were to nab the password file and their keychain file (which contains passwords to other accounts that they access) which is generally encrypted with the same password (the system nags you if it's not the same), you could potentially do some real damage.

The paper is about FileVault, not user accounts.

This feels a little bit like a naughtily published zero-day exploit.

I'm disappointed the post doesn't mention any appropriate disclosure to Apple prior to publication. Sure, it's not an out-right crack of the shaddow password algo but this vector could still be used in damaging ways.

Not really. There's no privilege escalation. You can only change user's password if you're already logged-in as user. That's bad, but it's only going to happen if you literally walk away from a terminal and someone else sits down.

Or run a malicious script?

There are far more damaging "malicious scripts" one could trick someone into running, such as "cd; rm -rf *".

Like I said, it's not good, but it's not what I would call a "security hole" because there is no escalation of privilege. I like Raymond Chen's take on the topic: http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...

"Like I said, it's not good, but it's not what I would call a "security hole" because there is no escalation of privilege."

Doesn't the end of the article suggest that without admin access, you could just reset the password for any admin user, then be able to log in as them? Sounds like priv escalation to me.

Edit: Actually, reading further comments, it seems you can only reset the password of the currently logged in user without reauthentication, so you can only get admin privs if you've already got a console with admin privs. I'm wrong.

Actually. Any application can do this and use the new password to become super-user. Really useful for a virus I reckon.

Exactly how can it use the new password to become super-user? You can't assume that everyone runs only the default admin user on their OS X system.

The file includes all password hashes, including root. So crack that, then you have superuser.

By default, Mac OS X disables the root user: http://support.apple.com/kb/ht1528

That said, reset or crack any admin's password and you can go to town with sudo.

Default user can use sudo with it's password. That's all you really need.

If sudo works the same way on Mac's as it does on Linux, then anyone in the sudoers file could give a rogue application root access.

It does, and, the only user there, by default, is the first user of the system - the administrator. Not all people use this as their main user.

By default, most do, and what happens by default is what matters to virus writers.

Not everyone, but I'd reckon MOST people do.

How? The problem he mentions at the end of the post only applies to the currently logged-in account. If you can change root's password, then you're already root, and don't need to change root's password to gain access.

Apple doesn't compensate security researchers, so I am not disappointed or surprised. In fact, they just ignore people half the time.

If it was a bug in a Google product, you can bet that he would have coordinated his disclosure with a fix.

Totally agree with this. Apple really ignore most security advisories, and I am speaking from experience.

Just from looking at Apple’s security page, it’s pretty clear they don’t ignore security issues: http://support.apple.com/kb/HT1222. Organizations and researchers are even acknowledged in the release notes: http://support.apple.com/kb/HT4826.

Like a lot of things, Apple does things quietly and on their own schedule without a lot of hoopla.

Compensation is irrelevant - if you bothered to sniff around a specific vendor's security and you discover an exploit then you really should disclose it. Such is the lore of white-hatism.

Sure many don't do the above, but the OP author is presenting himself as white-hat/legitimate.

And as informed users, we should consider carefully giving our business to vendors who don't go out of their way to encourage private disclosure --- a zero-day on a vendor is a zero-day on all of it's customers.

Sorry, but no. Compensation is highly relevant. Do you work for free? Or do you just not consider security research to be worth anything?

Although there are various opinions on the best way to disclose bugs, your view of what it means to be "whitehat/legitimate" is not actually consistent with the infosec industry, so please do not misuse the terms to throw judgments at others.

We can easily spin it the other way too after all - one could say that the largest, most profitable company in the world has a moral obligation to compensate those that are protecting their users where they failed to.

For reference: http://www.digitalbond.com/about-us/vulnerability-disclosure... http://erratasec.blogspot.com/2011/09/finally-responsible-di... http://www.securityfocus.com/brief/933 http://trailofbits.com/2009/03/22/no-more-free-bugs/

Yes I do work sometimes for free - its called Open Source - and sometimes I see my labor implemented into commercial projects. That's fine by me. I take from the well more than I give to it.

I entirely agree that Apple should be compensating those that disclosure exploits appropriately - I didn't say otherwise. But if you have a status quo where a vendor won't compensate and you have a zero-day opportunity, I say the appropriate thing is to inform the vendor first anyway (you can always disclosing publicly if you get no response). I fight for the user and all that.

Disclosing it publicly zero-day doesn't make you any money anyway.

Full disclosure is the only responsible sort of disclosure.

Apple, like Microsoft, has the tendency to sweep things under the rug when they feel it is unlikely the situation will become public. The only way to correct this behavior is release what you find to the public and as fast as possible.

Hmmm, surely 'Responsible Disclosure'[1] is the only responsible sort of disclosure - so named because it is, er, responsible.

[1] - http://en.wikipedia.org/wiki/Responsible_disclosure

TL:DR of above link: "[responsible disclosure] is like full disclosure, with the addition that all stakeholders agree to allow a period of time for the vulnerability to be patched before publishing the details"

It should be noted that anyone can edit wikipedia, and this pejorative term has fortunately been rejected by researchers and vendors alike. Even by Microsoft: http://www.theregister.co.uk/2010/07/22/microsoft_coordinate...

I've pasted some other definitions of "responsible disclosure" in a different reply.

Just because they call it "responsible disclosure" doesn't mean it is responsible.

I can call myself a shark. That doesn't make it so.

I know this isn't the same, but I feel like mission control set to a hot corner bypasses the password screen from time to time. I never really notice it though

I suppose it's different if an unauthenticated user can perform a password change with the system powered on, but similar things can be done with Windows and a Linux live cd with some tools, and Linux passwords can be changed in "single user" mode.

You can also just pop in the OS X cd and change the password at boot.

You can not decrypt Filevault that way, though.

Does this problem allow file vault access? Unless I read it wrong (totally reasonable in my jet lagged state), this won't reset your keychain either.

I'm wondering the same thing. I use filevault, but I don't feel like messing it up by changing the password this way.

I wonder if you can reset the password and use that password to simply disable the filevault.

Btw. My five cents. Write a script to: 1. change current users password to X 2. sudo "something really bad" 3. use password X

And there is a virus that can do anything on a mac. If you can change the password of the current user and he/she is an administrator, then any application can escalate to SU.

Yea with this I'd be worried about something doing that, making a new hidden user and then setting the password on the original account back leaving no immediately visible signs that anything is wrong.

Reverting the pw assumes you knew it in the first place, and thus didn't need to change/reset it.

The article also shows how you can obtain the current password hash without knowing the password - so you might be able to stash that away, and then surgically put the old hash back once you're root.

`dscl` should change the FileVault disk password for the associated user as well.

Note that if you're able to run `dscl`, the disk has already been unlocked and is insecure. You may as well just copy any interesting data while you're there.

You can easily disable the ability to boot an Mac OS X CD or DVD and change the password using Open Firmware password protection: http://support.apple.com/kb/HT1352

Reply on news.ycombinator.com