
Cracking OSX Lion passwords - eis
http://www.defenceindepth.net/2011/09/cracking-os-x-lion-passwords.html
======
jballanc
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...

~~~
keypusher
_any account is effectively a root account_

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

~~~
jballanc
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...](http://arstechnica.com/security/news/2011/03/pwn2own-day-one-safari-
ie8-fall-chrome-unchallenged.ars)). 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...

~~~
jessedhillon
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.

~~~
js2
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.

------
kulpreet
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.

~~~
lawnchair_larry
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.

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

------
KonradKlause
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

~~~
scott_s
Not _any_ , but the currently logged-in user.

~~~
KonradKlause
Thanks for the clarification!

------
maximilian
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)

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

~~~
KonradKlause
No, OpenSUSE for example is using bcrypt.

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

------
dotBen
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.

~~~
scott_s
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.

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

~~~
hackermom
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.

~~~
jfriedly
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.

~~~
hackermom
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.

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

------
emehrkay
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

------
drivebyacct2
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.

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

~~~
moe
You can not decrypt Filevault that way, though.

~~~
SoftwareMaven
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.

~~~
hmottestad
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.

~~~
simcop2387
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.

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

~~~
caf
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.

