On Monday, I wrote about an issue with a Genieo installer that was automatically clicking the Allow button in a keychain access request window, and this has led to a number of other reports and news stories, some of which are calling this the “BrokenChain vulnerability.”
There seems to be a lot of confusion around this issue, so let’s take a closer look at the facts.
There are a number of ways to accomplish the same thing that the Genieo installer was doing. Namely, requesting access to an item in the keychain, and then automatically clicking the Allow button in the window that OS X displays to ask the user whether to grant that access.
Back in 2011, a trojan called DevilRobber appeared. According to security researcher Arnaud Abbati, it used the following simple AppleScript to help it “click” the Allow button in that alert.
This works, but on a modern version of OS X, there’s a fairly significant problem with this. In order for this script to work, the app running the script must have been granted “access for assistive devices.” If you try to run this script in the Script Editor, OS X will prompt you to do that:
Of course, that’s a kind of scary-sounding message, so it’s unlikely that the average user would follow through with the instructions and enable this, especially since that requires multiple steps, including the entry of an admin password. Thus, realistically, this method for clicking the Allow button can be ruled out as a real-world option.
Another technique was described on Tuesday by a couple developers from Myki, according to an article on CSO Online. Their method was to create what was identified as a shell script that “wrapped” an image file.
It’s unclear at this time exactly what this means, as the video doesn’t appear to show a shell script being executed. I have not managed to get in touch with Antoine Vincent Jebara or Raja Rahbani, from Myki, for comment, but in a video posted by Jebara, it looks like they created a simple application and disguised it as an image file.
I’d guess that app probably calls a shell script, which in turn calls a command-line utility like MouseTool or Cliclick. These utilities are capable of moving and clicking the mouse, and therefore can be used to click the Allow button. In my testing, these utilities do not require any kind of admin password to be entered, nor do they need to be given access for assistive devices.
(As a side note, in the real world, attempting to open a downloaded app masquerading as an image would result in the typical OS X quarantine warning, which alerts the user that they’re trying to open an application downloaded from the internet, not an image. In Jebara’s video, this was not shown.)
According to the folks from Myki, they are able to click the Allow button by assuming it to be “10 percent to the right of the centre of the screen and 7 percent below it.” Although that may work on some machines, in my testing, that’s definitely not where it appears on my iMac.
This means that, to be truly effective, an app would need to be able to query the system to find out where that button is. Many folks have said that doing this must require an app to be granted either root permissions (ie, entry of an admin password) or access for assistive devices.
In actuality, however, it turns out that neither of these is true.
I located some sample code on Apple’s site for an app called “Son of Grab,” which does something very interesting… it parses the output from CGWindowListCopyWindowInfo, just as the Genieo installer did. The information it’s able to gather about open windows, without any need for special privileges, is telling:
Topping the list is the keychain access request window on my system, with its exact position plainly exposed. Add the offset to the middle of the button to the coordinates of the window and you have exactly the right on-screen position at which to simulate a click.
So, what does all this mean? Essentially, it means that it actually is possible for a rogue app to access items from the keychain using this vulnerability, without any need for special permissions. That means no admin password request or change to the access for assistive devices settings is necessary. There are a few gotchas, though:
- The use of AppleScript in any form is pretty much out of the question, due to the requirements for making it work. Few users will do what would need to be done.
- The app will not be able to access entries in iCloud Keychain, contrary to what was suggested by Jebara in the CSO Online article. Security on iCloud Keychain is tight, and no app can access anything there unless that app put it there in the first place.
- If the keychain is locked, entering a password to unlock the keychain would be required before the app could do anything to obtain a keychain item. If the user refused to provide that password, that would short-circuit this trick. However, by default, the keychain on OS X uses the same password as the login password, and is unlocked by default as long as the user is logged in.
- The app would only be able to access one specific keychain entry per request. Still, multiple requests could be chained in sequence (though that would run a much higher risk of alerting the user), and even a single compromised password could be a serious problem.
- The attack cannot be embedded inside an image file, as some reports have claimed. It must come in the form of an executable file of some sort, and would thus be subject to the same security restrictions that all other trojans must get around on OS X.
- If you’re cautious about what you download, it will be difficult for a hacker to get you to open a malicious app like this in the first place.
Thus, although this is definitely a concerning issue, the sky is not falling. Exploiting this issue cannot be done without the potential for alerting the user, and far worse can be done without alerting the user in any way at all.
However, it is my opinion that Apple does need to do something to interrupt this chain of events. That could be as simple as requiring the keychain password to be entered for such requests, regardless of whether the keychain is already unlocked. Or they could take a more difficult – but more universal – approach, by isolating this window, and other similar windows, in such a way as to prevent this kind of manipulation.
