Slashdot Mirror
"Extremely Critical" OS X Keychain Vulnerability Steals Passwords Via SMS
Mark Wilson writes: Two security researchers have discovered a serious vulnerability in OS X that could allow an attacker to steal passwords and other credentials in an almost invisible way. Antoine Vincent Jebara and Raja Rahbani — two of the team behind the myki identity management security software — found that a series of terminal commands can be used to extract a range of stored credentials. What is particularly worrying about the vulnerability is that it requires virtually no interaction from the victim; simulated mouse clicks can be used to click on hidden buttons to grant permission to access the keychain. Apple has been informed of the issue, but a fix is yet to be issued. The attack, known as brokenchain, is disturbingly easy to execute. Ars reports that this weakness has been exploited for four years.
Watch the video. The SMS is actually an MMS or instant message and he's downloaded a file called "Malicious.app" to the desktop. He then double clicks on that, the dock disappears, and very quickly the "Allow" button is clicked. By default OS X machines come set to allow only Applications from the Mac App Store to run. Most people reduce this security setting to allow applications from "Mac App Store and identified developers" to run. Either way, you'd have to 1) Not notice that this is a .App and not a picture, and 2) Have disabled the default security settings. Otherwise you'd get a big warning saying "You can't open this because of security settings", which would be pretty hard to miss and then you'd have to ignore the warning, change your security settings, re-open the file, not even worry about what the dialog saying "Allow" is and ignore the fact that your dock flashed on and off for no reason.
I agree that you should be required to enter your password to access the keychain, but this is a guy from Beirut shilling for his password management company. Not only that, he doesn't mention which OS versions are affected or anything else. This could very easily be the NULL-pointer dereference exploit posted last week repackaged in a very clumsy way. If it is, why doesn't he say so? Post the exploit code at least so legitimate researchers can pick it apart.
If you run around turning off security features and running random .apps from people willy-nilly on your computer, no matter what OS you're running.
"as long as a user had already allowed the app running the script to control the Mac .. the technique works only when invoked by an application already installed on their systems. There is no evidence the technique can be carried out through drive-by exploits or attacks that don't require social engineering and end-user interaction." ref.
Couple of comments :
- it is a security feature. Apple only approves Apps if they go through the App Store - if they are merely signed by a developer, Apple has no involvement in approval, but there is a credit card identity verification strength chain back to the developer via the signing certificate, and the certificate can be revoked centrally. Thats changing the attack surface, and workable lifetime for the exploit, so it is reasonably to call it a security configuration feature.
- OS X keychain and iOS keychain are different. In OS X, there are multiple keychains, and the level of access depends on configuration. Indeed there is no practical limit to the number of keychains in play. A standard user does not have access to the system keychain. Indeed your keychain doesn't need to be on the boot volume - paranoid OS X users put their keychain on an encrypted USB drive, and need to mount and unlock it , in addition to logging into the computer (so any credential on the drive is subject to 2FA to access)
The actual "exploit" is _bordering_ on the old school "look at all the horrible things you can do if you have root access" exploits as though root access itself is the exploit.
The attack does not work on the default configuration of the OS. In addition, it wouldn't work on a typical hardened configuration.
If you run as an administrator, disable code signing, and explicitly enable the script, then yes it works, but those 3 things turn it from a 100 is percent of the installed base problem, into a much smaller problem.
The