Aussie Researcher Cracks OS X Lion Passwords

daria42 writes "Thought your Mac was secure running Apple's latest operating system? Think again. Turns out that in some respects Lion is actually less secure than previous version of Mac OS X, due to some permission-tweaking by Apple that has opened up a way for an attacker to crack your password on your Lion box. The flaw was discovered by an Australian researcher who has previously published a guide to cracking Mac OS X passwords. Sounds like Apple had better get a patch out for this."

Comments

Not really cracking the passwords.

[Anonymous Coward]

He's not really cracking the passwords. He's just found a way to read the hash and salt from each users shadow file without root privileges. It's fairly serious, but the hashes still need to be brute-forced.

Re:Not really cracking the passwords.

[CaptainJeff]

Most common approach to password cracking = brute force, targeting the specific hash (with the specific salt) of the account you're trying to crack. Step one of such an attack = determining the hash and salt that you're targeting. Which is what he figured out. If he's now bruteforcing those hashes, then he absolutely is cracking the passwords (well, he's trying to anyway).

But your basic point is right...he's figured out a way to capture hash/salt data, which he still should not be able to do. Since Lion uses SHA-256 hashes for its shadow file, that cracking attempt is still going to be quite difficult.

The more important part of this article is that under some circumstances, you can change the password of the logged in user without entering the current password. Now, *that* is a big deal (the degree of which is subject to valid debate).

Re:Not really cracking the passwords.

[Anonymous Coward]

for this to work, a particular java app must be installed and run on a website which is run on the Mac OS X computer. .

No, that's just one attack vector suggested in the article to illustrate how this could be abused.

This is all possible, but basically FUD

ANY application which runs with a regular user permission CAN access the hashes for ALL the user passwords on the system.
That's not FUD. Also, the method described is not just possible, that's exactly how many infections occur these days.

Re:Not really cracking the passwords.

[ArAgost]

What TFA forgot to mention is that the attacker can change the password without breaking a sweat. So while still not straightforward (you have to get the user to execute your applet), there is no need to brute force.

Re:Not really cracking the passwords.

[ceoyoyo]

SHA-512, according to the article.

It's definitely an oversight, but should be fixed pretty quickly. The one line fix at the end of the article (restricting permissions on dscl) seems reasonable.

Re:Not really cracking the passwords.

[Dell Brandstone]

Addendum (also, this problem is not just bad because of the password hash exposure):
You could argue that brute forcing passwords is not the most common approach. For example, harvesting a million accounts and walking away with the passwords that can be cracked through an efficient "smart dictionary" attack, and abandoning the other ones, is probably bar far the most common harvesting strategy.

It's sort of like putting a club on your car.. It's not that they can't steal your car... but there's an easy to steal one next to yours.

So having a hash+salt with SHA-512, and a secure password? If you have a cryptographically strong password, this is a low severity aspect of the problem. The other issue is being able to use the same dscl subsystem to *change* passwords, under certain circumstances, without using credentials. If you can change the logged-in user's password, su to them, sudo /bin/sh, and then reinstall the old salt/hash into the compromised account, you can effectively root the box without damaging the target user's credentials.

Re:Not really cracking the passwords.

[slackergod]

Actually, the fact that OSX uses SHA512 makes it easy to crack the password (compared to the alternatives).

OSX uses SHA512(salt+password) to generate it's hashes. SHA2 was specifically designed to be highly parallelizable and fast on modern processors, which means brute force attacks are going to proceed very quickly. And as time goes on, and average processor speed increases, that amount of time per cpu (and per $) keeps dropping.

There are four modern password hashing schemes worthy of note: SHA512-Crypt (this is NOT simply SHA512), BCrypt, PBKDF2, and SCrypt.
All of these schemes use a variable number of rounds of their underlying cryptographic operation. This allows the algorithm to stay the same, but the cpu-cost to be increased per hash as computers get faster, or if a user is particularly paranoid and wants to make it take longer to crack.

Many of them (such as PBKDF2) even have properties that make them resistant to preimage attacks on the underlying hash function.

Finally, SCrypt has the unique property of being "memory hard"... it's rounds don't just require a certain amount of time, but a certain amount of memory*time. This makes parallelizing the attack much more costly, as each CPU has to get it's own dedicated amount of memory for the attack.

All of the above are so much tougher to brute force, that the cost of OSX's hash scheme is barely worth notice by comparison. I'm not sure why OSX is using what it is... Linux uses SHA512-Crypt, BSD uses BCrypt, WPA2 and many other things use PBKDF2... all would have been better choices.

Here's the full details.

[Core Condor]

http://www.techgineering.org/2011/09/22/2489/a-new-exploit-in-os-x-lion-allows-unauthorized-access-to-users-to-change-password/ - A New Exploit in OS X Lion Allows Unauthorized Access To Users to Change Password

Re:Here's the full details.

[spydir31]

Even better is the researchers' own blog post

Not good, but not a panic situation

[Sycraft-fu]

So looking at it, basically what it comes down to is you can effectively get at the shadow file as any user. That does indeed mean you can get the hashes to attempt to crack passwords. This isn't a good situation, and isn't how it should be. On any UNIX you should have to be root to get at the shadow file, on Windows you must be an administrator (and running elevated, if UAC is on) to get at the SAM file.

However, do note that it is just a set of hashes. So you still have to crack the password. So long as the passwords are good, this really doesn't get you anywhere. If you've ever messed with this you find that things quickly get impossible so long as passwords are reasonably long. As such, if you have good passwords, this isn't a huge problem.

That said, I think we'll want to send out a warning to our Mac types today since they seem to think Macs make them immune to security issues and as such are prone to bad passwords. Perhaps this can help convince them to adopt better password standards since, really, that is one of the big keys to good security these days.

Re:Not good, but not a panic situation

[boristhespider]

If you don't value your job too highly, you could even do a demonstration by deliberately exploiting the exploit to get their hashes, cracking their passwords, and email each of them an archive encrypted with their own password. When they unlock it they find a text file saying "CHANGE YOUR PASSWORD YOU MORON". Depending on your bosses you may well get fired for this, but it would help convince people that actually they're not as safe as all that.

Re:Not good, but not a panic situation

[Manip]

The SAM file on Windows is impossible to retrieve while the Windows kernel is running. The kernel has an exclusive read/write lock on the file and any attempt to access it will be denied. It is possible to read an NTFS file-system outside of the OS even while the OS is running but we're talking about deep-file system inspection.

Re:Not good, but not a panic situation

[jamesh]

The SAM file on Windows is impossible to retrieve while the Windows kernel is running. The kernel has an exclusive read/write lock on the file and any attempt to access it will be denied. It is possible to read an NTFS file-system outside of the OS even while the OS is running but we're talking about deep-file system inspection.

You meant any attempt by a user without admin privileges of course. VSS solved the backup-open-files problems a long time ago.

Extremely Serious

[Manip]

I was expecting to read one of the normal fear-mongering stories that we often see on /. (e.g. "Drop Box sends passwords in plain text!!") but actually this is one of the most serious OS level holes I've seen in years. Not only can you retrieve the password for any user on the system but you can also reset their password without having to know what it was.

People have posted "they're still hashes so you still have to break them" which is of course true, but if you keep reading down he shows you how to reset the other user's password without ever having to know them.

Re:Extremely Serious

[RyuuzakiTetsuya]

Worst?! XP had that flaw that let you install Vista.

Re:Extremely Serious

[Anonymous Coward]

Password reset doesn't work for my OS X installation. . .

$ dscl localhost -passwd /Search/Users/
New Password:
Permission denied. Please enter user's old password:
passwd: DS error: eDSAuthFailed
  DS Error: -14090 (eDSAuthFailed)
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.7.1
BuildVersion: 11B26

Re:Extremely Serious

[teridon]

Not only can you retrieve the password for any user on the system but you can also reset their password without having to know what it was.

According to the FTFA, you can only reset passwords for the currently logged in user. It doesn't say anything about resetting other user's passwords:

It appears Directory Services in Lion no longer requires authentication when requesting a password change for the current user [emphasis mine]

Still not good, but not nearly as bad as you suggest. Now, all that said, I don't have a Lion system on which to test resetting another using password using dscl. I can only hope it doesn't work.

Does sound kind of serious, maybe

[bryan1945]

Here is a bit from TFA-
"This means, according to the researcher, that it might be possible for an attacker to crack a users’ Lion password by attacking their system through a Java app hosted online. The attack vector would still require the owner of the computer running Mac OS X to allow the Java app to run — but it is possible."

It's not exactly a 1-2-3 step action. Also, the article never said he actually cracked any passwords, though he claims-

"Dunstan noted that due, no doubt, to Lion’s relatively short time being available for use, he could not find any major cracking software supporting the ability to crack encrypted passwords in the operating system — but he has published a simple script which allows users to do so. "

Little bit more backup would be a good thing, here.

So not serious

[aybiss]

You can change the password for any user on a Windows box without ANY credentials, provided you have physical access. Seems we have forgotten this while everyone is fear-mongering about what someone can do over the 'net.

Re:So not serious

[boristhespider]

You can change the root password on a Mac box without ANY credentials, provided you have physical access, Seems we have forgotten this while everyone is fear-mongering about what someone can do over the 'net.

Sorry for the sarcasm, but basically once someone has physical access to your computer you're basically boned unless you've encrypted your drive. It's Macs I know best, and it's trivial: boot to single user mode (command+S at start), mount in the file system as read/write (it even gives onscreen instructions for doing this) and then change the root password. I imagine something very similar can be done in Linux if there's an easy way to get it into single-user mode. Besides, on any machine to which you have physical access you can always boot a live distro and at the very least access the hashes if not easily take full control of the system.

Re:So not serious

[aybiss]

In fact, let me clarify by example:

1 - Compromise system
2 - Replace OS code with some that allows access to said file

OR

1 - Compromise system
2 - Install something like the WinPE layer that allows access to said file

OR

1 - Compromise system
2 - Perform complicated SQL injection and Javascript hack that allows access to said file

Notice how the first step is always 'compromise system'? Whether that involves standing in front of it or breaking RSA... suddenly it's like, "Oh noes, I can see teh files that make up the system I currently use to operate my boxen!"

Re:So not serious

[ais523]

On Linux, interrupt the boot process at the bootloader prompt, choose to edit the kernel command line, then add "single" to the end of it and continue the boot process. It boots into single user mode, and the same way as on the Mac, will allow you to change arbitrary users' passwords (including root) without further authentication. I'm pretty sure that this is deliberate; physical access = game over, so why not make it easy for a sysadmin to recover a lost password?

Re:So not serious

[BitZtream]

Just for reference, booting in single user mode to reset a password is not 'hacking'.

Interesting contrast I notice here

[metalgamer84]

Its interesting how when OSX has a security hole, everyone downplays it as "not that serious, no big deal". In contrast, if this same issue happened with XP/Vista/7, then the entire /. crowd would be jumping on the bandwagon of Microsoft bashing, "OMG another MS security hole! See people, Windows is crap!". Its funny how people will defend their preference and bash their competitors, even though the root issue can be the same for both. Anyhoo, just an observation.

Re:Interesting contrast I notice here

[CapuchinSeven]

It's easier on Windows frankly, but I agree that they shouldn't be defended and fanboying your own choice of OS over another just because they are as bad as each other, is not a good idea.

Re:Interesting contrast I notice here

[aybiss]

Has anyone discovered a good BeOS or OS/2 hack recently?

Re:Interesting contrast I notice here

[Uberbah]

Its interesting how when OSX has....

What's interesting is how every time Apple screws something up or does something unpopular, some clever guy pops in to post the requisite "now if this were Microsoft, you'd all be up in arms" post. Nevermind the same comment has been posted eleventy billion times before on this blog for more than 10 years.

Case in point: the iCon 'book banning' story from 6 1/2 years ago, where publishing house Wiley had their books pulled after they wrote what Jobs obviously viewed as an unflattering biography:

Balanced.. (Score:5, Insightful)
by Flaming Death (447117)

If this were a MS story of Bill Gates doing the same, there would be the usual crazy outbreak of 'MS evil empire' type banter. However, because its Apple , the response is a mild - 'oh its ok, hes the Apple man hes allowed to'. Where is the balance? I think somewhere in between to be honest - Jobs and Gates are simply very ruthless business persons, and yet here at Slashdot there is a decided overflow towards Apple.

Or:

Bill Gates and Microsoft (Score:4, Insightful)

I agree that these guys have a right to some privacy. Most interesting to me is that the comments here on /. are generally supportive so far. What a different thread it would be if this had been Bill Gates and Microsoft instead of Steve Jobs and Apple.

Nevermind the many highly rated comments suggesting Jobs back off, recounted how Jobs screwed Woz over a petty amount of money, or called Jobs an unbelievable asshole.

So clever.

Linux and Windows are just as bad.

[CapuchinSeven]

It's trivial to break the password on a Windows machine, in fact a hell of a lot easier on a Windows machine, if you have physical access. I'll happily do it, and have done it, in about 10 seconds with a boot USB or CD if the machine so too old for USB. A friend assures me a Linux box isn't that much harder. I use Linux, OSX and Windows in one form or another for my given needs but I feel that the REAL issue here shouldn't be "it's easier to do this on Windows, it's all anti-Apple FUD", but rather "we shouldn't be fanboys to any company/brand/make/type, there is no excuse for bad QA and security auditing in any OS". Ultimately though, physical access is the death of any OS.

Re:Linux and Windows are just as bad.

[Anonymous Coward]

I quote you.
It is interesting, though, that not all of us succeed in changing current user's password with dscl localhost -passwd /Search/Users/. I tested it on two Lion installs, and it did not work (well it actually asked for current password, as it should do). At the same time, dscl localhost -read /Search/Users/ | grep ShadowHashData returns 0 bytes, on build 11C62.
This somehow makes the anti-Apple FUD theory a lil bit stronger, IMHO. Before blindly quoting what people writes on their blog, sometime doing some first-person (easy) test can be a good idea.

Re:Linux and Windows are just as bad.

[CapuchinSeven]

The password isn't broken here either, it still has to be brute forced and a strong password makes this whole thing totally useless, that still doesn't excuse OSX allowing access to the hash but still, you have to brute force the password. He's worked out how to access the hash/salt which is impressive and requires Apple to take a serious look but still makes it harder to do this than it is to get into a Windows machine, which is totally and utterly trivial to do.

Well there's your problem...

[neorush]

This sounds like a typical PEBKAC coding error. The dscl is probably (not much of a mac user here) running as root for indexing and such , but of course you do not need to be root to run it. Reminds me of when locate used to return / index all files, including ones that you did not have permission to, and of course now we have slocate. This is the kind error crops up in Microsoft vulnerabilities all the time. Its like they just didn't think it through from the black hat perspective at all.

Changing password without any challenge

[Bloody Peasant]

Agreed; and what most here have totally missed is the fact that there is no "existing password" challenge if you use dscl localhost... as TFA says right at the end, almost as an afterthought.

While it's possible...

[Anonymous Coward]

Either it's already been patched, as I'm running the developer builds of 10.7.2, or there's an issue in his particular setup vs. a normal install that's allowing this to happen.

Stepping through the information on his own blog at: http://www.defenceindepth.net/2011/09/cracking-os-x-lion-passwords.html

When performing his "dscl localhost -read /Search/Users/" I do NOT get the dsAttrTypeNative:ShadowHashData result UNLESS I have root privileges through sudo. Not even for my own user.

Face Palm

[wzinc]

FTA: "The attack vector would still require the owner of the computer running Mac OS X to allow the Java app to run — but it is possible."

I knew some Australian hacked my mac

[bitt3n]

when the screen started displaying everything upside down