Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Apple

Aussie Researcher Cracks OS X Lion Passwords 165

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."
This discussion has been archived. No new comments can be posted.

Aussie Researcher Cracks OS X Lion Passwords

Comments Filter:
  • by Anonymous Coward on Monday September 26, 2011 @07:52AM (#37514362)
    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.
    • by CaptainJeff ( 731782 ) on Monday September 26, 2011 @08:00AM (#37514430)
      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).
      • Also it does make the brute forcing process many times faster. Generally speaking a system won't let you remotely connect to it and get a password wrong too many times before it locks you out for a bit. Also authentication isn't immediate, so even if it doesn't lock you out, there is a limit to how fast you can test passwords. 1/second would probably be a reasonable upper limit. Get a hash file, and you can do a few orders of magnitude better.

        Now for a good password this doesn't matter. It is the difference

      • by ceoyoyo ( 59147 )

        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.

      • 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

      • I had some pretty good success cracking some Unix passwords with a password list. It was an exercise for a computer security course, where we actually had to break into a target machine. Out of about 40 user accounts I recovered approximately half.
      • 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.

        Could you change it back by replacing the original hash after you've done whatever you wanted to do to their system?

        Now, *that* is a big deal (the degree of which is subject to valid debate).

        Of epic proportions, I'd say.

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

          Could you change it back by replacing the original hash after you've done whatever you wanted to do to their system?

          Why bother? Just install a back door and leave only one sign of tampering rather than fucking with their password. You already HAVE ACCESS TO THEIR ACCOUNT at that stage, don't don't need their password to do anything.

          Now, *that* is a big deal (the degree of which is subject to valid debate).

          Of epic proportions, I'd say.

          Again, why? Or by epic do you mean not really a big deal?

          If I find an open console, unless I'm trying to teach you a lesson about leaving your console unlocked, the last thing I'm going to do is change your password. Only a moron makes it obvious they've owned the account. You leave the p

          • The dscl command might not allow you to change other users' passwords, but if dscl can modify the shadow file without the root password, what prevents something else from doing the same thing but allowing you to change any password?

          • by TheLink ( 130905 )

            Maybe they want root for tradition's sake? I don't know why, but let's just assume that OK?

            So they need to enter the user's password for sudo.

            They do not have the user's password but apparently they can read the hashed version AND they can change the user's password without entering it.

            So they back up the original password, change it, get root do whatever they want as root, then restore the password, and so it won't be obvious to the user that the machine has been pwned.

            Get it now?

      • Re: (Score:3, Insightful)

        by slackergod ( 37906 )

        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 (

      • could get the 'hash' and the 'salt'. then you add the pepper, and your goose is cooked.

    • by ArAgost ( 853804 )
      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.
    • by Ferzerp ( 83619 )

      That *is* what password cracking is....

    • Unlike previous versions of OS X, Lion ships without Java. So the proposed attack vector of a Java Applet has one more distinct hurdle (on top of getting the user to run the code, and having to crack the password): the user must first install Java.
  • by Core Condor ( 2469670 ) on Monday September 26, 2011 @07:59AM (#37514418)
    http://www.techgineering.org/2011/09/22/2489/a-new-exploit-in-os-x-lion-allows-unauthorized-access-to-users-to-change-password/ [techgineering.org] - A New Exploit in OS X Lion Allows Unauthorized Access To Users to Change Password
  • by Sycraft-fu ( 314770 ) on Monday September 26, 2011 @08:02AM (#37514438)

    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.

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

      • If they have accounts on your local machine, especially if it is a laptop, then just send a note to IT, why do I have a user "jimjones" with password "jimj0nes" with access to my laptop... I basically did this to my IT dept a few years back. They pushed out a update that installed VNC in a hidden mode on all PC's. When I found it on my PC, I cracked the password (very week rot-13 type of storage mechanism) emailed one of them a message, "why is vnc installed on my machine with password "hex0515." They

    • by Manip ( 656104 ) on Monday September 26, 2011 @08:12AM (#37514516)
      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.
      • by jamesh ( 87723 ) on Monday September 26, 2011 @08:31AM (#37514670)

        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.

      • L0phtcrack can nab a SAM file from a a running system. I am not sure how it goes about doing that, but it works. I presume it dumps the in-memory copy.

        However, as I said, you have to be an administrator to do it and on UAC enabled systems, you must escalate. As such it is fairly hard to get at.

      • by X.25 ( 255792 )

        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.

        What the ... ?

        What are you smoking?

    • TFA and TFS of course again destroyed all the important parts of the original work [defenceindepth.net]

      The critical part is about half way down. The WTF isn't that the hashes are extractable allowing you to brute force the password at your leisure, it's that there's no challenge to CHANGING the password. There isn't even a need to crack the password in this case and that most definitely IS a panic situation.

  • by Anonymous Coward

    Unlike Snow Leopard

  • Extremely Serious (Score:5, Insightful)

    by Manip ( 656104 ) on Monday September 26, 2011 @08:05AM (#37514466)
    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.
    • by RyuuzakiTetsuya ( 195424 ) <taiki@@@cox...net> on Monday September 26, 2011 @08:15AM (#37514534)

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

    • Re: (Score:3, Interesting)

      by 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

      • by TheLink ( 130905 )
        Did you put the current user's user name after "/Search/Users/" ?

        e.g.
        dscl localhost -passwd /Search/Users/bob

        Where bob is the current user.
    • Re:Extremely Serious (Score:4, Informative)

      by teridon ( 139550 ) on Monday September 26, 2011 @10:31AM (#37516116) Homepage

      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.

    • For the typical Mac user (think Hello Kitty stickers covering their MacBook), the proposed attack vector is a non-issue. In order for a Java applet to run, the attacker needs Java installed on the target system. Lion ships without Java. So, beyond getting the user to run the applet, and beyond having to brute force the passwords, the attacker somehow has to install Java on the target Lion system.
      • by mjwx ( 966435 )

        For the typical Mac user (think Hello Kitty stickers covering their MacBook), the proposed attack vector is a non-issue. In order for a Java applet to run, the attacker needs Java installed on the target system. Lion ships without Java. So, beyond getting the user to run the applet, and beyond having to brute force the passwords, the attacker somehow has to install Java on the target Lion system.

        1. Wait for user to install your infected Hello Kitty screensaver for Mac.
        2. Tell user to install Java (or bundle it, after all if you're installing a virus, why care about Oracle's license agreement).
        3. ?????
        4. Profit, erm, I mean infection... no wait, I mean profit.

        Same old method that has been used on other OS's for decades. No-one has managed to create an effective technological defence for social vectors and likely never will.

  • by bryan1945 ( 301828 ) on Monday September 26, 2011 @08:15AM (#37514536) Journal

    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.

  • Ok, now it's time for a bunch of people to complain about how snide and awful Mac users are, how they think that they're immune to security problems. We'll get a string of posts about how some study indicated that OSX was less secure than Windows, maybe some anecdotal evidence that some slashdotter knew a guy who was a Mac user, and he was an asshole and said something stupid about computers once.

    When we've gotten enough of those, we'll see a backlash of posts rehashing old complaints about Windows and Li

  • 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 (Score:5, Insightful)

      by boristhespider ( 1678416 ) on Monday September 26, 2011 @08:26AM (#37514616)

      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.

      • by nstlgc ( 945418 )
        But... but... Micro$oft!!
      • 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, ...

        If it's Macs you know best, then you also know Lion makes it quite simple to encrypt your hard drive.

        It was the first thing I did after I installed Lion, actually.

        • Just because it's simple to do doesn't mean everyone will have done it... Maybe this kind of thing will help them wake up and start encrypting everything.

      • by sootman ( 158191 )

        An old rule: "If you don't have physical security, you don't have security." You can also set a firmware password [apple.com] so people can't use this trick, or Option to choose another boot device, or T to enter target disk mode, etc. They can still pull the drive out, but short of that, you're more covered.

      • by ais523 ( 1172701 )
        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?
    • by aybiss ( 876862 )
      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
      • A SQL injection and Javascript hack? You obviously don't know what you're talking about. You don't hack a local computer with a "SQL injection attack". I mean, even if the guy had SQL server installed on his computer... oh wait, that's right, you're a moron, why am I trying to explain anything to you. I'm sure you'll "clarify" how a "SQL injection attack" would help compromise a local system.

        Local is easy, If the disk isn't encrypted just reinstall the OS - no matter what OS you're using - now you ha
    • Actually, that's not true. My laptop has BitLocker applies (required by work, but if you have a TPM you may as well use it). The whole drive, including the credential store, is encrypted. Explain to me how you're going to change the credentials on that, please?

      Also, my local Administrator account is password-protected, so Safe Mode isn't going to help you here even if you get that far.

  • by metalgamer84 ( 1916754 ) on Monday September 26, 2011 @08:34AM (#37514690)
    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.
    • ... and if it happens on any linux distro all the Windows and Mac User are just happy to it proves Linux and FOSS in general is inherently much more insecure than OSX/Win7. Well .. that's /., what did you expect?
    • 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.
      • It's easier in windows for the same reason everything is easier in windows. There is a metric shit ton of hacking tools designed to hack that specific platform. Just off the top of my head I can think of at least three 'password recovery' floppy/CD images for windows that will just boot up and reset or grab the password off a windows machine, and I don't have to know how to do anything more than insert the disk and press the power button. I'm sure disks like this have been or will be made for any OS, but

    • by Uberbah ( 647458 ) on Monday September 26, 2011 @11:30AM (#37516788)

      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 [slashdot.org] 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) [slashdot.org]
      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) [slashdot.org]

      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 [slashdot.org], recounted how Jobs screwed Woz [slashdot.org] over a petty amount of money, or called Jobs an unbelievable asshole [slashdot.org].

      So clever.

  • by CapuchinSeven ( 2266542 ) on Monday September 26, 2011 @08:54AM (#37514894)
    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.
    • You'll never get anywhere on Slashdot with that kind of measured attitude.

    • Re: (Score:2, Insightful)

      by 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 doi

      • by TheLink ( 130905 )
        Did you remember to put the current user's user name after "/Search/Users/" ?

        e.g.
        dscl localhost -passwd /Search/Users/bob

        Replace bob with the username of your current logged in user.
    • You aren't talking about 'breaking the password'.

      You're talking about wiping it out or resetting it, which is far different than cracking it.

      • 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.
    • by mgiuca ( 1040724 )

      You're right, any OS by definition has the same problem -- if passwords are stored hashed on the machine and the attacker has physical access, it's game over. But there is a difference here: from what I'm reading, the OS X attacker does not require physical access. So on Linux and Windows, the two ways to get the password hashes is if you are a) the root user, or b) have physical access (boot into a Live CD, etc). On OS X, this exploit can apparently be performed by a non-root user, which means any hacker t

    • You're welcome to take a shot at mine. First step: get past the BitLocker drive encryption. Even if you guess the PIN you still can't boot anything but the installed OS - if you want to boot another OS you either have to first log into Windows and suspend the BitLocker protection, enter a ridiculously long recovery key, or have the full hard drive be encrypted. The last case isn't terribly useful for your goal, unless your plan is to wipe the OS entirely and install a new one on there.

  • 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.
    • by am 2k ( 217885 )

      I just checked, dscl is not a daemon and the suid bit is also not set. This issue seems to be at a lower level.

      • I just checked, dscl is not a daemon

        Correct - as man dscl will tell you, it's the "Directory Service command line utility".

  • by Anonymous Coward on Monday September 26, 2011 @09:30AM (#37515354)

    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 [defenceindepth.net]

    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.

  • ...through an unsuspecting update or upgrade?

  • 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."
  • by bitt3n ( 941736 ) on Monday September 26, 2011 @01:33PM (#37518366)
    when the screen started displaying everything upside down
    • by quenda ( 644621 )

      when the screen started displaying everything upside down

      If only /. supported unicode, I'd have a very witty response, mate.

  • 10002$ dscl localhost -passwd /Search/Users/konohitowa
    New Password:
    Permission denied. Please enter user's old password:

"Imitation is the sincerest form of television." -- The New Mighty Mouse

Working...