On the XARA vulnerability on MacOS X and iOS

Just came across this article: Apple CORED: Boffins reveal password-killer 0-days for iOS and OS X, by The Register. Since the news itself did not explain the nature of the attack well enough, I went onto reading the full paper:

Xing, Bai, Li, Wang, Chen, Liao: “Unauthorized Cross-App Resource Access on MAC OS X and iOS” [2]

First, Kudos to those authors.

The authors claim that they were the first to find the following “zero days”.

1. Password Stealing (Keychain access control vulnerability)[MacOS X]
2. Container Cracking (BundleID check failures by the App Store staffs) [MacOS X]
3. IPC Interception (3a. WebSocket non-authentication, and 3b. local OAuth redirect) [MacOS X]
4. Scheme Hijacking [MacOS X, iOS]

Of those, at least 3.b and 4 were known among us at least since November 2013. The OAuth PKCE spec that is almost being finalised and published from IETF is an answer for those vulnerabilities.

1. Password Stealing (Keychain access control vulnerability)[MacOS X]

Out of these four (or five to be more specific) vulnerability, this is by far the most interesting one. This vulnerability arises from combination of two bugs. 

Mac OS X’s key chain is implemented as in FIg. 1. 

Each keychain item has a set of multiple attributes, a credential, and an ACL. ACL stores the list of trusted apps and the operation allowed to them, e.g., read, write, etc. Only the applications in this ACL can access the item, and only accordingly to what has been specified in the ACL.

Only the app that has created the item can set the ACL.

 

The attack scenario is as follows:

1. A malicious app creates a key chain item before the legitimate app and adds the legitimate app to the ACL.
2. When the user installs and start using the legitimate app, the legitimate app starts writing to the keychain item.
3. The malicious app reads out the credential from the keychain item.

You may think that this scenario is unlikely especially for a high impact one such as iCloud since the keychain item is created at the installation time of OS X. However, this is not the case due to another bug around it: i.e.,

“Any app can delete any keychain item”

 

Combined with the bug, the attack scenario becomes:

1. A malicious app deletes the target keychain item.
2. The malicious app creates a key chain item before the legitimate app and adds the legitimate app to the ACL.
3. When the user installs and start using the legitimate app, the legitimate app starts writing to the keychain item.
4. The malicious app reads out the credential from the keychain item.

To avoid this vulnerability, the legitimate app has to read out the ACL and check if any untrusted app is in the ACL before writing anything to it.

This vulnerability does not apply to iOS because there is no ACL in iOS keychain.

2. Container Cracking (BundleID check failures by the App Store staffs) [MacOS X]

Each MacOS X App Store apps has a unique Bundle ID and is confined within the sandbox of that name. The sandbox cannot be read out by any application but with the one with the same Bundle ID. The registration process in the App Store is supposed to check if the Bundle ID has been duplicated, in which case the registration is not allowed.

However, there seems to be a bug in the process. They really do check the Bundle ID of the main app, but if the main app has the sub-app, they are not checking it. So, you can register a malicious app that has a sub app with the same Bundle ID as the target app. The researchers succeeded in actually doing so and has read out everything from the target app’s sandbox.

 

3a. WebSocket non-authentication

There are multiple methods for IPC. Unix socket is a prime example. In the paper, it talks about the IPC using WebScoket.

WebSocket usually is being used over the network, and the client checks the server certificate to see if it is a legitimate one. However, in this attack scenario, a local websocket without any TLS cert is being used. As the result, if the malicious app takes up the legit app’s port before the legit app, it can intercept whatever is being sent to that port through websocket.

1password was given as the example of an app that has this vulnerability. 1password app waits on port 6263 for the communication from its browser extension. The extension gets the password etc. and send it to this port. Unfortunately, there seems no authentication of the server (the app that is running on the port 6263) is happening. So, a malicious app can steal the credentials that are sent to this port.

 

According to the paper, the 1password creator, AgileBits, apparently said that there is no way out for it. I do not know why. If I were them, I would create a keypair at the installation time and give the public key to the browser extension so that the extension can use it to encrypt the payload. Sure, the malicious app can get the payload, but it cannot do anything with it. Maybe I am missing something here.

3b. Local OAuth Redirect

It is similar to 3a, but in this case, instead of using websocket, a redirect to a local webserver is used to communicate with it. The paper uses Pushbullet as an example. This app uses Google SIng Sign On and the redirect URI is localhost:20807. By getting the port before the Pushbullet, the malicious app can get the access token.

Control against this attack is to stop using Implicit Flow and use OAuth PKCE instead. We all knew that using implicit flow like this is insecure from the beginning. It is sad that developers are still using this.

 

4. Scheme Hijacking [MacOS X, iOS]

(Footnote)

[1] http://gigazine.net/news/20150618-ios-os-x-password-killer/

[2] https://sites.google.com/site/xaraflaws/

[3] Sakimura, N., Bradley, J, and N. Agaawal:”Proof Key for Code Exchange by OAuth Public Clients”, IETF, (2015)