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.
Nobody should defend Apple, because it should require the user to enter the password to open the keychain. Instead of users being trained to blindly click to allow access, Apple let's the application writer approve their own accesses.
Apparently this guy will, saying that no OS is secure, never will be, and there will always be security problems.
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.
SMS? This is an apple script exploit on a mac PC. not a mobile device. Nowhere does the article explain that SMS is an attack vector and unless iOS is vulnerable as well,I do not see how it could be.
Silence is a state of mime.
No one is going to get my passwords. They've all been safely keylogged onto Microsoft's ultrasecure telemetry cloud!
"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.
It is only 9 lines of code: http://arstechnica.com/security/2015/09/attacks-accessing-mac-keychain-without-permission-date-back-to-2011/
Then the app has all the accounts and passwords stored in your keychain.
Gosh. You sure told them!
Some of you clowns hate Apple so much, you will believe any unauthenticated negative you read.
I'm mixed on Apple and not fan, but it is always funny watching the "See! See! Apple is insecure too".
And then someone smart posts how ridiculous the claim is by explaining the several asterisks of the supposed exploit.
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
So all the user has to do is have zero understanding of the computer, click allow on everything with out thinking, and ignore stuff that is obviously weird and broken? Sounds like this will work against 30% of the population. Add in that it gets you free porn and you got 10% more.
No. For an app from an unidentified developer, there is no "Allow" option presented. You have to know how to bypass that security setting in order to get the app to run, which is the whole point--the kind of users who blindly click "Allow" to everything are unlikely to know how to do that, and so won't be able to run this kind of app.
Apologist? It's a bug. Real one. Even some gurus are going to get stung by this one.
And you greatly overstate the difficulty of joe dumbass user googling to find out how to allow non-apple apps.
Apologist.
When all you have is a hammer, every problem starts to look like a thumb.
On OS X, this programmatically easier to do, but it's possible with a little more effort in Linux (if using GNOME or KDE and their password stores) and Windows (which is trickiest of all since you specifically deal with an application's store rather than a central one; presumably you'd go for a browser)
On Windows - unlike on OS X and Linux - there is the concept of User Interface Privilege Isolation (UIPI) where a process running with a higher integrity level cannot be remote controlled by a lower-integrity process.
The real vulnerability here is NOT whether the user has allowed the process to run or not or whether it came through the app store nor not. The critical vulnerability is the lack of isolation of the window that is supposed to obtain approval from the interactive user. This lack of isolation means that an OS X application can launch an action that requires approval and then immediately - through script - approve the action itself.
Pointing to the app store approval model is missing the point entirely. Even approved applications can (and do!) contain vulnerabilities. The reason why so many apologists are out in force and try deflecting the problem as "app approval" is because this illustrate an architectural problem within OS X: Even though the same user runs a number of processes, a mechanism for policing what they can do to each other is lacking.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
This is a malicious application (not an image) that has been allowed to run after the user dismissed the gatekeeper dialog that warns about downloading applications, after the user entered their password (to allow the malicious application to control other applications) and it's accessing a keychain item with no ACLs? How is that a flaw in Mac OS X?
Those 9 lines won't actually run without entering an administrator's username and password first to permit Script Editor to control other applications.
Try it.
It is only 9 lines of code: http://arstechnica.com/securit...
Then the app has all the accounts and passwords stored in your keychain.
Yes. If you give that script access first. IOW no, not really. If you instead block it, you have to enable it before it can even ask again.
Of course news about a fake are Fake News.
Note that the default is "Deny" and the only other options is "Open System Preferences" where you have to grant access to the app/script
I can totally see how this could happen without the user noticing.
Of course news about a fake are Fake News.
Apologist? It's a bug. Real one. Even some gurus are going to get stung by this one.
And you greatly overstate the difficulty of joe dumbass user googling to find out how to allow non-apple apps.
Apologist.
Yeah, exactly the same bug as giving an idiot like you access to a computer. Your post if proof of that. And no, this has nothing to do with" allowing non-apple apps" - not even with allowing any apps to run. Which you would have a chance of knowing if TFA didn't hide it behind a lot of scaremongering. But it's actually there. But hey, you at best only read the summary anyway, right?
Of course news about a fake are Fake News.
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.
Except for the fact that this does not need root access, did you actually read and understand this or did you just jump to Apple's defence?
So far, so right. It's actually far more complicated than simply typing in your Admin password: https://support.apple.com/en-u...
And the moral to the story: A) never trust the word of a security researcher who wants to sell you something, and B) you don't have to be a complete moron to be a Apple-Hater, but it sure helps.
Of course news about a fake are Fake News.
It is isolated. In order to interact with it, a user must explicitly permit it by entering an admin's username and password.
Sorry, but that is not isolation. If the prompt require a password rather than just an accept, the launching process can *still* control it remotely through Applescript - it would just not know what to put in the fields. That's not isolation. At best, it is a mitigating factor.
Isolation would mean that any Applescript launched from the process was *barred* from interacting with the approval window.
The vulnerability here is architectural: Windows can be remotely controlled. Ask yourself this: What good is an approval window, if the process can just remote control the approval itself?
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
The "security feature" in this case is just saying you want to run a program that Apple hasn't approved. I can already see the excuse for drive-by malware will be it is your fault for visiting a website Apple didn't approve.
Even when you reduce the GateKeeper settings to the minimum, you still have to answer a Dialog that warns that this is an Application that was downloaded from the internet, and do you want to run it? THEN you have to specifically grant Sudo Permission.
Seriously, what else would you have Apple do, that wouldn't have the Slashdot crowd whine that "You can't run non-Approved Apps"?
Seriously. Damned if they do, and Damned if they don't. Security is, and always will be, a set of tradeoffs.
That's not apologizing; that's recognizing reality, rather than holding something up to an utterly impossible, hypothetical ideal.
If this was happening in Linux, they freetards would be all over blaming the User for being stupid. But when it's Apple, it is always their fault. Again, not apologizing; just observing the typical modus operandi around here.
For conversation above the trivial level, context is relevant.
So while you may hate it, you certainly aren't going to stop it.
I've fallen off your lawn, and I can't get up.