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. 

図1)MacOS Xのキーチェンの構造
Fig.1 KeyChain structure on MacOS X [SOURCE: Xing et al.: “Unauthorized Cross-App Resource Access on MAC OS X and iOS”]
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]

There is yet another inter app communication mechanism for MacOS X and iOS. It is called Custom Scheme. You can create a custom scheme like “abcd123” for the called app and have the calling app open “abcd123://?param1=xyz” etc. to invoke the called app and pass the parameter.

Unfortunately, there is no control onto the use and registration of the custom scheme on an iOS device. As the consequence, a malicious app can register the same custom scheme as the target app, which makes it possible to hijack the communication about half of the times. Note that the malicious app can then re-invoke the target app using the same mechanism so that the user would not notice. It is a man-in-the-midlle attack.

We knew this attack at least since 2013. OAuth working group at IETF has been working on it and a standard called OAuth PKCE is almost ready to be published, which mitigates the risk.

So, the control here again is to stop using Implicit Flow and use PKCE instead.



[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)


3 Replies to “On the XARA vulnerability on MacOS X and iOS”

  1. Hi, I’m Megan and I work for AgileBits, the makers of 1Password.

    I just wanted to clarify here that the attack described in this research is not directed at the encrypted 1Password database. For our security expert’s thoughts on this article, please see our blog: https://blog.agilebits.com/2015/06/17/1password-inter-process-communication-discussion/. If you have further questions, we’d love to hear your thoughts in our discussion forums: https://discussions.agilebits.com.

    1. Hi Megan, sorry for my tardy reply. I am travelling with limited internet connection.

      Indeed, the attack does not compromise the 1password stored data. For the Japanese version of my blog, I have created a separate entry (http://www.sakimura.org/2015/06/3111/ ) describing it as well as the fact that it is easier and more reliable to do MITB rather than having a process waiting at the designated port, etc.

      Maybe I should translate it into English as well.



      1. Hi Nat,

        Thanks so much for getting back to me! It’s great to hear that you’ve been investigating this issue. I’m not a security expert, or a developer, but if you have thoughts on ways that we might work around this vulnerability, our team would love to hear about it. You’re welcome to send an email in to support+social@agilebits.com so we can continue this conversation.

        Have a great day,

        Megan O’Brien
        Level 60 Support Sorceress at AgileBits

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.