"Extremely Critical" OS X Keychain Vulnerability Steals Passwords Via SMS 123
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.
Wait for it... (Score:1, Troll)
So who will defend Apple this time or attempt to minimize this or attempt to claim that other OSes are worse so that this is, seemingly, less significant. No OS is secure, it never will be and it only gets worse when you connect it to another device. There will always be security problems.
Not because I care so much but because I am easily amused...
Re: Wait for it... (Score:2, Insightful)
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.
Re: (Score:1)
Somebody will if this is like very other thread on the subject. It seems to be a matter of pride. Use the OS that suits the task at hand best for you and practice safe hex. I suspect part of the problem has been the goal of making the computer a device for amusement instead of a computational device as its goal. Aiming for the lowest common denominator can not be a good thing in this field. It just can't be - at least not from my perspective. That's not to say it needs to be overly complex. Maybe it is time
Re: (Score:1)
Actually, this 'bug' *does* require that the user enters a password. It requires that the user enters the *administrator* password to grant the malware app permission to control the computer. That has to happen *before* this attack will work. The attack 'works' because someone has explicitly granted root access to the malware.
Re: (Score:3, Funny)
Apparently this guy will [slashdot.org], saying that no OS is secure, never will be, and there will always be security problems.
Re:Wait for it... (Score:5, Insightful)
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.
Re: Wait for it... (Score:2, Informative)
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.
Re: (Score:3)
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.
Re: Wait for it... (Score:5, Informative)
It is only 9 lines of code: http://arstechnica.com/securit... [arstechnica.com]
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.
Re: Wait for it... (Score:5, Insightful)
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.
Re: (Score:2)
Top-poster much?
Re: (Score:3)
For conversation above the trivial level, context is relevant.
So while you may hate it, you certainly aren't going to stop it.
Re: (Score:2)
Interlaced replies usually happen when someone tries to inject too many points in a single message. This shows poor aptitudes for synthesis and lack of focus, and does not facilitate communication as the exchange becomes a mess after only 1-2 replies. Shortsighted and sub-optimal.
Re: (Score:2)
Nonsense.
Re:Wait for it... (Score:5, Informative)
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.
Re: (Score:3, Informative)
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.
Re:Wait for it... (Score:5, Insightful)
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?
Re: (Score:1)
You fail as a developer if your solution is, don't let stupid people on computers.
Re: (Score:2)
Apologist? It's a bug. Real one. Even some gurus are going to get stung by this one.
So, anyone who clarifies an error on this subject is automatically an apologist???
Re: (Score:2)
Apple astroturfers with mod points churn my stomache.
Re: (Score:2)
Apple astroturfers with mod points churn my stomache.
Actually, that's your ulcer. You still keep too much of that hate inside - go full postal.
Re: (Score:2)
You just left a slime on the internet that won't wash off.
Re:Wait for it... (Score:5, Informative)
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
Re: (Score:1)
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?
He just jumped to Apple's defence.
Good, I don't see an issue with Apple users getting it in the nether hole because of blind fandom.
Re: (Score:1)
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?
He just jumped to Apple's defence.
Good, I don't see an issue with Apple users getting it in the nether hole because of blind fandom.
I do have an issue with faithful Apple cultists abusing their moderating privileges
Re: (Score:3)
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... [apple.com]
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.
Re: (Score:3, Insightful)
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 apolog
Re: (Score:2)
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.
The default is to allow applications from Mac App Store and identified developers. But you're right about the rest.
Re: (Score:1)
No, the default is app store only.
2nd option is the one you said.
3rd option is allow all apps.
Re: (Score:2)
No, the default is app store only.
2nd option is the one you said.
3rd option is allow all apps.
But it is important to note that, even on the weakest setting, the User is still required to grant "First Run" privileges. So even if the User has done everything to de-fang GateKeeper, s/he still has to be "complicit" for the Exploit to Run.
At that point, how much responsibility can be heaped on Apple, versus the User?
Re: (Score:1)
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.
brain fart?
Re: (Score:2)
Can you name any? I have several games on OS X and none of them require me to disable Gatekeeper.
Re: (Score:2)
Thank you. From the tone/writing style of the story, I was wondering whether this was written by a first year CS student or somebody trying to sell something. More clutter adding to the poor SNR on /.
Re: (Score:2)
It's being actively exploited in the wild: http://arstechnica.com/securit... [arstechnica.com]
The trojan app installs itself by clicking the "allow" button itself, so fast that the user doesn't have time to deny it permission. It installs adware on the user's machine without their consent.
I'm surprised that Apple didn't use a special type of window for this request. On Windows the UAC requests are done in such a way that this couldn't happen - apps can't grab the window's handle and send simulated clicks.
The SMS thing is str
Re: (Score:2)
Apple does use a special type of window that can only be interacted with if a user enters an administrator's username and password.
It says that's exactly what the user is doing in that Ars article. And UAC won't prevent an application running as SYSTEM from issuing commands that require SYSTEM.
Re: (Score:2)
TFA shows an Applescript script that clicks the "accept" button. That doesn't seem very well protected.
Re: (Score:2)
The 'researchers' had to specifically and literally disable the default security protections on their machine in order to have that happen.
Otherwise, it would have popped up a window refusing to run the application at all, instead demanding that you go into System Preferences to allow that specific application.
It's like cutting the brake lines on a Toyota, then showing a video of it running into something while claiming that the car company has a serious brake design problem. :/
Re: (Score:2)
Yeah, the AppleScript only works after the user has entered the administrator's username and password to allow it to use accessibility features to control other applications
Re: (Score:3)
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?
Re: (Score:2)
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.
Exactly.
I would bet that the people that are on here declaring gloom and doom and "Apple doesn't care about Security", etc. are some of the very same people who will defend Android to the death when a user clicks-through the "Permissions" list when Installing an App, saying that it is the User's responsibility to be vigilant about granting Permissions.
Guess what? Social Engineering works, and will likely continue to work, on certain people, and it is damn-near impossible to protect all users from themse
Egg asploded in your face again (Score:3, Insightful)
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.
Re: (Score:1)
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.
You mean, that's the only "asterisk" that you want to admit-to?
But the Reality is far different.
Grow up. Or better yet, just STFU, hater.
Re: (Score:2)
Re: (Score:1)
I have used macs for years but I sure as hell won't defend Apple on this one. FOUR YEARS and they've said NOTHING? Instead, they withhold security updates for any system 3 years or more old. Frankly, I am dead sick and tired of the maroons that blame users for not using the very newest upgrade. Totally aside from the feeling of utter violation incurred from forced upgrades, the fact is that unlike Microsoft, Apple has recently gone out of their way to break applications on every new release, forcing develop
Do you even computer? (Score:5, Informative)
Re: (Score:3, Informative)
It is then possible to intercept a user's password and send it to the attacker via SMS or any other means
pretty far stretch if you ask me...
Re: (Score:2)
It is then possible to intercept a user's password and send it to the attacker via IrDA or any other means
There. Much more relevant.
Re: (Score:2)
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.
Actually, if you watch the video, the only thing you can really see is that Malicious App sends a SMS with the password it "stole" - via Twillo obviously: https://www.twilio.com/sms [twilio.com]. But hey, clickbait is clickbait - and it worked. Oh, did it work.
Re: (Score:3)
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.
Not to support the obvious shill-article; but I believe that, since OS X 10.10 (Yosemite), Macs have been able to receive/send SMS and MMS messages [apple.com] that are routed through Apple's iMessage service.
Having said that, I still believe that the amount of disabling of security by the User, and the Granting of Permissions by the User puts this Exploit solidly in the "Yawn" territory.
Re: Do you even computer? (Score:3)
My iPhone is paired with my Mac and the Messages applications on my iPhone and Mac are linked as well. When my phone is near my Mac I do indeed get SMS messages on my Mac, as iMessage and Gtalk, other people probably do the same.
Doesn't Android do that too with Hangouts or something?
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:1)
It's a fake. The real thing is in the private collection of a Saudi prince who also owns the cocks of Ayrton Senna, Patrick Swayze, Rick James and a few others. He had those cocks surgically attached to each other, side by side, in the shape of a pan flute. He calls it the Zamfir Shrine and if you offer him a good deal on a gold-plated Ford Festiva he may agree to let you play with it. Or so I heard.
Re: (Score:1)
Hey faggot, I'm having a hard time understanding you with Jobs' rotting cancer cock in your mouth.
Wow, what an erudite discussion. That's what keeps me coming back to Slashdot; the stimulating verbal intercourse.
That's why I use Windows 10 (Score:3, Funny)
No one is going to get my passwords. They've all been safely keylogged onto Microsoft's ultrasecure telemetry cloud!
Re: (Score:1)
Re: (Score:1)
Passwords are protected at the bottom of the stairs.
Vulnerability not really extremely critical .. (Score:5, Informative)
Re: (Score:1)
So just build it into any of the thousands of otherwise useful open source apps out there and wait for people to install it on their own. That approach has worked wonders in the past.
User: "I wonder how my network is doing. Ooh this cool app will give me a list of hosts on my LAN and also tell me how much bandwidth my computer is using. Cool!" *click*. Done.
The same basic approach works everywhere (Score:1)
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). the The trick is really just getting a user to run the executable in the first place.
Note that you don't use SMS to attack, just to transmit the data. OS X makes it simple to use SMS, but other systems cou
Re: (Score:2)
the addition of sms into the article is bizarre. it almost sounds like a bizarre ios tie in to an article that has nothing to do with that.
oh well, years old flaw.. so yeah, that's what it is.
Re: (Score:3)
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 mea
Re: (Score:2)
It is isolated. In order to interact with it, a user must explicitly permit it by entering an admin's username and password.
Re: (Score:3)
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
Re: (Score:2)
Uhm, the username and password entry is required before the controlling app even gets a chance to control anything, an admin has to approve the controlling.
That is, the approval window (let's call it B) the article is talking about showing is not the approval window (that requires an admin's username and password, let's call it A) shown in order to allow one application to control another. A is shown before B is shown.
Re: (Score:2)
Re: (Score:1)
I filed a bug with Apple about the ease of spoofing the Keychain authorisation and privilege elevation dialogs against OS X 10.2. Maybe by 10.11 they'll fix it...
Apple bug or security reports are like petitions on whitehouse.gov. If they notice them at all, it's to mock them. Sadly, the same is true of Android. Still no pinless pairing after how many years of people asking for it on the same two bug reports?
Re: (Score:2)
on X11 most security dialogs are grabbing keyboard, which should disable any input except the mouse and keyboard from interacting with the window.
So that makes it impossible to send keypresses to security dialogs.
Re: (Score:2)
Re: (Score:2)
in linux it's horribly easy.
The keystore is not locked if your are logged in (i.e. screensaver is off).
So a simple 3 lines script is enough to read all your passwords.
This bug has been signalled multiple times.
I never store my passwords in the keystore.
Re: (Score:2)
On a bigger picture note - security needs to be more important for the end user. I think people tend to think that smart phones are less likely to be exploited than a PC and that bad things won't happen. People need to understand how to secure their phones and what behavior they should guard against.