New adware scripts mouse clicks to access OS X Keychain, could lead to password theft
A new version of the long-running Genieo adware has brought with it a new technique for accessing the OS X Keychain without user intervention, a security gray area that could be used by other malicious actors to make off with sensitive data stored in the Mac credential manager.
The adware depends on an OS X feature that is designed to prevent users from being forced to enter their account password multiple times in quick succession. As discovered by Malwarebytes, the Genieo installer asks users to authenticate with their password prior to installation --?but it later mounts a special app that asks for keychain access, prompting a different dialog that asks the user whether to allow or deny that access.
This secondary dialog does not prompt for a password, and the installer simulates a mouse click on the "Allow" button. The entire process takes just a fraction of a second.
Many users are unlikely to notice the window, and even those that do could be prone to ignore it.
Because this behavior does not rely on an OS X flaw, it is particularly dangerous and comes with a high potential for abuse. Such a request could be embedded in any seemingly innocuous file?and is difficult to guard against without changing the behavior of the Keychain request dialog.
Even more worrying, OS X apps can, by design, request access to any Keychain entry they desire. It's left up to the user to decide whether that app should be allowed to have access, so this technique could be used to steal nearly anything that has a known Keychain entry.
Apple has not yet responded to these reports, though they may address the problem before the release of OS X El Capitan.
As always, users should follow common-sense security practices: do not download files from unknown sources, and be wary of e-mails or websites that seem suspicious or non-authentic.
The adware depends on an OS X feature that is designed to prevent users from being forced to enter their account password multiple times in quick succession. As discovered by Malwarebytes, the Genieo installer asks users to authenticate with their password prior to installation --?but it later mounts a special app that asks for keychain access, prompting a different dialog that asks the user whether to allow or deny that access.
This secondary dialog does not prompt for a password, and the installer simulates a mouse click on the "Allow" button. The entire process takes just a fraction of a second.
Many users are unlikely to notice the window, and even those that do could be prone to ignore it.
Because this behavior does not rely on an OS X flaw, it is particularly dangerous and comes with a high potential for abuse. Such a request could be embedded in any seemingly innocuous file?and is difficult to guard against without changing the behavior of the Keychain request dialog.
Even more worrying, OS X apps can, by design, request access to any Keychain entry they desire. It's left up to the user to decide whether that app should be allowed to have access, so this technique could be used to steal nearly anything that has a known Keychain entry.
Apple has not yet responded to these reports, though they may address the problem before the release of OS X El Capitan.
As always, users should follow common-sense security practices: do not download files from unknown sources, and be wary of e-mails or websites that seem suspicious or non-authentic.
Comments
I'm totally lost on how that could be initiated.
Because this behavior does not rely on an OS X flaw, it is particularly dangerous and comes with a high potential for abuse.
Actually it is a design flaw, but not a software bug. The design is defective.
Windows, since NT 3.1 (which derived it from a similar feature from VMS), has had a trusted path. In the early versions, you had to press control-alt-del to enter your password or change it. Vista enhanced this for UAC, which is why the desktop grays out when you need to elevate. The whole point of this is to prevent any application from intercepting keyboard input or manipulating the GUI, solving the exact weakness you see here.
So...don't give it?
So someone entering their password to authenticate is required? Not really a design flaw. If I give access to something like that, I'm at fault not the OS. The fact it's required says Apple did their job.
Nope, its a flaw. You should not be able to access keychain items that don't belong to your app without explicit permission, even after entering your password. This ensures that your app's credentials are protected from compromises in other apps. For example, a flaw in Mail, which is already a system application, should not result in all of your Safari passwords being stolen.
There are also some keychain credentials (certificates) that can be set to require permission every single time. That's by design. (Just like you need to give explicit permission for contacts, location, etc) It's bypassing this.
Damn jailbreakers.
My question has always been; couldn't both/all three buttons/options be the same answer no matter what you clicked?
I'm not a software programmer/writer/developer/scripter/coder/engineer/guru/grand master poobah so maybe that's impossible, and obviously unlikely from a reputable dev, which, obviously, I'm not going around dl-ing random sw, but... Still I basically click the appropriate option with my fingers crossed.
Remember the XProtect in OS X? All Apple need to do is blacklist the app, then report to authority.
On the other hand, I don't understand why OS X has a loophole for app to move my cursor.
I hope this is addressed with rootless in 10.11
Of course it could fix:
Remember the XProtect in OS X? All Apple need to do is blacklist the app, then report to authority.
Exactly. I don't know why MacKeeper and everything from Genieo is not blacklisted by OS X by default.
In order to steal a password don't you have to open Keychain Access, click on show password and enter the admin password?
My Safari Extensions List has no password.
Surely Gatekeeper should have the intelligence to warn the user about the malicious file when it's downloaded anyway? IMO it'd actually be better to delete the file completely and flat out refuse to run it. Why give stupid people a choice when they don't know any better? Power users could still use the Terminal to download the file if they really wanted to. Either that, of when the malware asks for some root permissions/Keychain access, give a really big warning dialog explaining the danger, which requires you to actually type "I UNDERSTAND" before it can be dismissed. People are dumb, this is the kind of thing that's needed to actually stop idiots from just clicking "allow/agree/ok" on everything.
I have no idea why Apple's not blocking MacKeeper or Genieo. Pretty ridiculous, it's not like it's some kind of grey area whether these apps are rogue or not. Apple's even got support documents on how to remove Genieo, and Geniuses remove MacKeeper as soon as they find it.
I have no idea why Apple's not blocking MacKeeper or Genieo.
It actually is blocked, according to my XProtect file dated August 4. They probably changed their code enough to get around the signature.
Really? Where exactly?
"The latest installer is essentially the same as the last one, updated so that it will no longer be blocked by the OS X anti-malware protections".
https://blog.malwarebytes.org/mac/2015/08/genieo-installer-tricks-keychain/
I definitely should install that on my mac, I need it for some reason, I have no clue why?
Ah apologies I thought you meant the AI article. 8-)
Genieo Innovation is an Israeli company, specializing in unwanted software which includes advertising and user tracking software, commonly referred to as a potentially unwanted program, grayware or malware.
I definitely should install that on my mac, I need it for some reason, I have no clue why?
I understand that they partner with e.g. Softonic, and when you download software from there, the installer automatically puts this Genieo crap on your machine as well. So you think you install something, but end up with a little extra.