• BLOG
  • iOS URL Scheme Hijacking (XARA) Attack Analysis and Countermeasures

iOS URL Scheme Hijacking (XARA) Attack Analysis and Countermeasures

October 01, 2015

A group of vulnerabilities were announced by team of researchers at Indiana University targeting Apple’s OS X and iOS. It has been referred to as XARA, which based on the white paper stands for “Unauthorized Cross-App Resource Access” and outlines vulnerabilities and methods for accessing information in a legitimate App through interception locally on the device. In terms of iOS, there is an important vulnerability that impacts the iOS URL Scheme used by Apps that could expose credentials and other sensitive information. Let’s explore further.

What is a URL Scheme?

iOS URL Schemes in general allow one App to be opened by other Apps, or essentially inter-app communication. Specific actions can be defined to not only open a URL, but populate what it is you’d like to search, for example coordinates, local donut shops, and much more.

Here's an example: yelp4:///search?terms=Donuts

The problem outlined in the white paper is that “Apple does not enforce the unique naming for App schemes”. Therefore, two completely different apps can use the same identical URL Scheme. Therefore a malicious App can use this to target a legitimate App.

The Attack

The use of URL Scheme Hijacking is actually nothing new. FireEye, for example, outlined some attacks back in February, 2015 that they referred to as the Masque Attack II. And the team that authored the XARA white paper stated that their discoveries date back to the fall of 2014. Information about the original Masque Attack can be found in our MobileIron Blog.

The common thread across all of this is that this flaw can be exposed and leveraged by a malicious App. As previously mentioned, a malicious App can use the same URL Scheme as a legit App. This inter-app interaction essentially allows the URL Scheme to be hijacked and thus used in a phishing attack. Here’s a possible attack flow (note that there are variants):

1. Distribute the malicious App to the User:

  • Post malicious App to AppStore - User unknowingly downloads a malicious App to their device. Note that in the white paper they state that they have loaded Apps to the actual Apple AppStore, so this malicious App currently can be distributed directly through the AppStore and thus doesn't require distribution outside of the AppStore, nor does the device need to be jailbroken.
  • Send link to download through an email or SMS using the original Masque Attack approach

2. User launches App - Normally when a user launches an App for the 1st time, they are prompted with a “Trust” prompt before they can proceed. But in the case of URL Schemes the user is not prompted, and the App is then allowed to proceed with launching the URL scheme.

3. Depending on the malware, the next phase of the phishing attack can occur where credentials are stolen through a fake login, secret access tokens in the URL are accessed, and much more. The white paper outlines a few good examples. FireEye also has two videos on their site that are worth viewing.

Important Note: Apple does reserve some system schemes that can’t be used by 3rd party apps.

How do I protect myself or my users?

We provided a knowledge-base article to our customers that outlines how we protect our customers both with MobileIron and mobile security best practices:

MobileIron's AppConnect technology enables iOS apps to communicate securely with additional authentication and encryption that prevents the issues described in this report. This provides a nice proactive protection against MITM attacks in the following cases:

  • AppConnect Apps communicating with other AppConnect Apps
  • AppConnect Apps communicating with non-AppConnect Apps

We recommend that MobileIron administrators enforce the below iOS best practices for security:

  1. Ensure end users upgrade to the latest iOS versions.
  2. Require passcodes for all end user devices.
  3. Enable jailbreak detection and configure policies to quarantine jailbroken end user devices
  4. If possible, when deploying an enterprise iOS app, do not use a wildcard provisioning profile. Use a provisioning profile associated with an Explicit App ID.
  5. Consider the use of a third-party app reputation service to detect the installation of known malware on end user devices. MobileIron integrates with numerous leading vendors in this area. https://marketplace.mobileiron.com

Additional links and information:

Michael T. Raggo

Michael T. Raggo,

Similar Blogs