Adware Simulates Mouse Events to Access Keychain
“What they’re basically doing is using provided system calls to get the location of the [permission] window and the location of the OK button in the window,” Thomas Reed, Malwarebytes’ director of Mac offerings, told Ars. “Then they’re simulating a mouse click. I’m surprised nobody thought of that before.”
[…]
The discovery also underscores a potential weakness that could be exploited by other unwanted adware or, worse, by outright malicious espionage trojans. For instance, it’s not hard to imagine a trojan disguised as a benign program that remains dormant for some period of time. Then, when the machine isn’t in active use, the app asks for permission to access a password for iCloud or Gmail and in the blink of the eye approves the request. Unless end users have overridden default Mac settings, the app would now be in possession of the credentials.
As you can see there from that pseudo-code (generated from the assembly code by Hopper Disassembler), the installer is using three calls to CGCreateMouseEvent: one to move the mouse, one to simulate a mouse down and one to simulate a mouse up. (This is done after another routine parses the information returned by CGWindowListCopyWindowInfo to find out where the button is.)
Ultimately, it seems that this window is probably one that shouldn’t show up in that list of windows. However, I’m not enough of an expert at the inner workings of OS X to know how that would affect the Accessibility features of OS X, or if it would at all.
It doesn’t seem that simple, though, because the window is already frontmost with the Allow button as the default. Presumably, the app could just simulate a Return key event. This window does not appear very frequently, so perhaps a solution would be for it to ask for your password.
5 Comments RSS · Twitter
Can this sort of thing be prevented without disabling the functionality that a lot of utilities like Keyboard Maestro need?
I don't think I could live without Keyboard Maestro.
“the threat posed by Genieo is offset by the fact that the extensions list is only accessed after an end user has downloaded the app, clicked on it, and entered a system password”
So those affected by this have already been fooled into installing untrusted third party software, and it sounds like they even had to enter their admin password.
I wonder if a similar trick would work to click the 'Open' button of the Open panel, and would bypass sandboxing (well, at least for the folder/file selected in the panel by default). Hopefully, sandboxed aps cannot send keyboard/mouse events outside of the app willy-nilly.
(I realize it's a rhetorical question to start with because why bother sandboxing your nefarious app and then work around the sandbox when you can just distribute the same non-sandboxed nefarious app)
