XARA, deconstructed: An in-depth look at OS X and iOS cross-app resource attacks

This week, security researchers from Indiana University released details of four security vulnerabilities they discovered in Mac OS X and iOS. The researchers detailed their discoveries of what they call "cross-app resource attacks" (referred to as XARA) in a whitepaper released Wednesday. Unfortunately, there has been a lot of confusion surrounding their research.

If you're not at all familiar with the XARA exploits or are looking for a high-level overview, start with Rene Ritchie's article on what you need to know. If you're interested in slightly more technical detail on each of the exploits, keep reading.

To start, while the vulnerabilities keep getting lumped into a single bucket as "XARA", there are actually four distinct attacks that have been outlined by the researchers. Let's take a look at each one individually.

Malicious OS X Keychain entries

Contrary to what some reports have said, while a malicious app cannot read your existing keychain entries, it can delete existing keychain entries, and it can create new keychain entries that are readable and writeable by other, legitimate apps. This means a malicious app can effectively trick other apps into saving all new password entries to a keychain it controls, and then can read.

The researchers note that one of the reasons iOS is unaffected by this is that iOS doesn't have ACLs (access control lists) for keychain entries. Keychain items on iOS may only be accessed by an app with a matching bundle ID, or group bundle ID (for shared keychain items). If a malicious app created a keychain item that it owned, it would be inaccessible by any other app, making it entirely useless as any sort of honeypot.

If you suspect you may be infected by malware employing this attack, it's fortunately very easy to check the ACL of keychain items.

1. Navigate to Applications > Utilities in OS X, then launch the Keychain Access application.
2. In Keychain Access, you will see a list of your system's keychains on the left, with your default keychain likely selected and unlocked (your default keychain gets unlocked when you log in).
3. In the right pane you can see all of the items in the selected keychain. Right-click on any one of those items and select Get Info.
4. In the window that pops up, select the Access Control tab at the top to see a list of all applications who have access to this keychain item.

Normally, any keychain items stored by Chrome will show "Google Chrome" as the sole application with access. If you've fallen victim to the keychain attack outlined above, any affected keychain items would show the malicious app in the list of applications that have access.

WebSockets: Communication between apps and your browser

In the context of the XARA exploits, WebSockets can be used for communication between your browser and other apps in OS X. (The topic of WebSockets itself extends well beyond these attacks and the scope of this article.)

The specific attack outlined by the security researchers is against 1Password: When you use the 1Password browser extension, it uses WebSockets to communicate with the 1Password mini helper application. For example, if you save a new password from Safari, the 1Password browser extension transmits those new credentials back to the parent 1Password app for safe, persistent storage.

Where the OS X vulnerability comes into play is that any app can connect to an arbitrary WebSocket port, assuming that port is available. In the case of 1Password, if a malicious app can connect to the WebSocket port used by 1Password before the 1Password mini application can, the 1Password browser extension will wind up talking to the malicious application instead of 1Password mini. Neither 1Password mini or the 1Password browser extension currently have a way to authenticate with one another to prove their identities to each other. To be clear, this is not a vulnerability in 1Password, but a limitation with WebSockets as currently implemented.

Additionally, this vulnerability isn't limited to just OS X: The researchers also noted iOS and Windows can be affected (thought it's unclear what a practical exploitation might look like on iOS). It's also important to highlight, as Jeff at 1Password pointed out, that potentially malicious browser extensions can pose a much greater threat than simply stealing new 1Password entries: WebSockets' lack of authentication is dangerous for those using it to transmit sensitive information, but there are other attack vectors that present a more prominent threat at the moment.

For more information, I recommend reading 1Password's write-up.

OS X helper apps traversing sandboxes

Application sandboxing works by limiting an app's access to its own data, and preventing other apps from reading that data. In OS X, all sandboxed apps are given their own container directory: This directory can be used by the app to store its data, and is not accessible by other sandboxed apps on the system.

The directory created is based on the application's bundle ID, which Apple requires to be unique. Only the app that owns the container directory—or is listed in the directory's ACL (access control list)—may access the directory and its contents.

The problem here appears to be lax enforcement of the bundle IDs used by helper applications. While an app's bundle ID must be unique, apps can contain helper applications within their packages, and these helper applications also have separate bundle IDs. While the Mac App Store checks to make sure that a submitted app doesn't have the same bundle ID as an existing app, it seemingly does not check the bundle ID of these embedded helper applications.

The first time an app is launched, OS X creates a container directory for it. If the container directory for the app's bundle ID already exists—likely because you've launched the app already—then it's linked to that container's ACL, allowing it future access to the directory. As such, any malicious program whose helper app uses the bundle ID of a different, legitimate app will get added to the legitimate app container's ACL.

The researchers used Evernote as an example: Their demonstration malicious app contained a helper app whose bundle ID matched Evernote's. When opening the malicious app for the first time, OS X sees that the helper app's bundle ID matches Evernote's existing container directory, and gives the malicious helper app access to Evernote's ACL. This results in the malicious app being able to completely bypass OS X's sandboxing protection between apps.

Similar to the WebSockets exploit, this is a perfectly legitimate vulnerability in OS X that should be fixed, but it's also worth remembering that greater threats exist.

For example, any application running with normal user permissions can access the container directories for every sandboxed app. While sandboxing is a fundamental part of iOS's security model, it's still being rolled out and implemented in OS X. And even though tough adherence is required for Mac App Store apps, many users are still accustomed to downloading and installing software outside of the App Store; as a result, much greater threats to sandboxed application data already exist.

URL scheme hijacking on OS X and iOS

Here we arrive at the sole iOS exploit present in the XARA paper, though it also affects OS X: Apps running on either operating system can register for any URL schemes they wish to handle—which can then be used to launch applications or pass payloads of data from one app to another. As an example, if you have the Facebook app installed on your iOS device, entering "fb://" in Safari's URL bar will launch the Facebook app.

Any app can register for any URL scheme; there is no enforcement of uniqueness. You can also have multiple apps register for the same URL scheme. On iOS, the last application that registers the URL is the one that gets called; on OS X, the first application to register for the URL is the one that gets called. For this reason, URL schemes should never be used to transmit sensitive data, as the recipient of that data is not guaranteed. Most developers who use URL schemes know this and would likely tell you the same.

Unfortunately, despite the fact that this sort of URL scheme hijacking behavior is well-known, there are still many developers that use URL schemes to pass sensitive data between apps. For instance, apps that handle sign-in through a third-party service may pass oauth or other sensitive tokens between apps using URL schemes; two examples mentioned by the researchers are Wunderlist on OS X authenticating with Google and Pinterest on iOS authenticating with Facebook. If a malicious app registers for a URL scheme being used for the above purposes, then it may be able to intercept, use, and transmit that sensitive data to an attacker.

All that said, you can help protect yourself from URL scheme hijacking if you're paying attention: When URL schemes are called, the responding application gets called to the foreground. This means that even if a malicious app intercepts the URL scheme intended for another app, it will have to come to the foreground to respond. As such, an attacker will have to do a bit of work to pull off this sort of attack without being noticed by the user.

In one of the videos provided by the researchers, their malicious app attempts to impersonate Facebook. Similar to a phishing website that doesn't look quite like the real thing, the interface presented in the video as Facebook may give some users pause: The app presented isn't logged in to Facebook, and its UI is that of a web view, not the native app. If the user were to double-tap the home button at this point, they would see that they are not in the Facebook app.

Your best defense against this type of attack is being aware and staying cautious. Be mindful of what you're doing and when you have one app launching another, keep an eye out for strange or unexpected behavior. That said, I want to reiterate that URL scheme hijacking is nothing new. We haven't seen any prominent, widespread attacks exploiting this in the past, and I don't anticipate we'll see them pop up as a result of this research either.

What's next?

Ultimately, we'll have to wait and see where Apple goes from here. Several of the above items seem like bonafide, exploitable security bugs to me; unfortunately, until Apple fixes them, your best bet is to stay cautious and monitor the software you install.

We may see some of these issues fixed by Apple in the near future, while others may require deeper architectural changes that require more time. Others may be mitigated with improved practices from third-party developers.

The researchers developed and used a tool called Xavus in their whitepaper to help detect these types of vulnerabilities in apps, though at the time of this writing I could not find it available anywhere for public use. In the paper, however, the authors also outline mitigation steps and design principles for developers. I would highly recommend that developers read the research paper to understand the threats and how it may impact their apps and users. Specifically, section 4 goes into depth on the hairy details regarding detection and defense.

Finally, the researchers also have a page where they link to their paper as well as all demonstration videos which can be found here.

If you're still confused, or have a question about XARA, leave us a comment below and we'll try to answer it to the best of our ability.