Three New Masque Attacks against iOS: Demolishing, Breaking and Hijacking
In the recent release of iOS 8.4, Apple fixed several vulnerabilities including vulnerabilities that allow attackers to deploy two new kinds of Masque Attack (CVE-2015-3722/3725, and CVE-2015-3725). We call these exploits Manifest Masque and Extension Masque, which can be used to demolish apps, including system apps (e.g., Apple Watch, Health, Pay and so on), and to break the app data container. In this blog, we also disclose the details of a previously fixed, but undisclosed, masque vulnerability: Plugin Masque, which bypasses iOS entitlement enforcement and hijacks VPN traffic. Our investigation also shows that around one third of iOS devices still have not updated to versions 8.1.3 or above, even 5 months after the release of 8.1.3, and these devices are still vulnerable to all the Masque Attacks.
We have disclosed five kinds of Masque Attacks, as shown in the following table.
Name | Consequences disclosed till now | Mitigation status |
App Masque | * Replace an existing app * Harvest sensitive data | Fixed in iOS 8.1.3 [6] |
URL Masque | * Bypass prompt of trust * Hijack inter-app communication | Partially fixed in iOS 8.1.3 [11] |
Manifest Masque | * Demolish other apps (incl. Apple Watch, Health, Pay, etc.) during over-the-air installations | Partially fixed in iOS 8.4 |
Plugin Masque | * Bypass prompt of trust * Bypass VPN plugin entitlement * Replace an existing VPN plugin * Hijack device traffic * Prevent device from rebooting * Exploit more kernel vulnerabilities | Fixed in iOS 8.1.3 |
Extension Masque | * Access another app’s data * Or prevent another app to access its own data | Partially fixed in iOS 8.4 |
Manifest Masque Attack leverages the CVE-2015-3722/3725
vulnerability to demolish an existing app on iOS when a victim
installs an in-house iOS app wirelessly using enterprise provisioning
from a website. The demolished app (the attack target) can be either a
regular app downloaded from official App Store or even an important
system app, such as Apple Watch, Apple Pay, App Store, Safari,
Settings, etc. This vulnerability affects all iOS 7.x and iOS 8.x
versions prior to iOS 8.4. We first notified Apple of this
vulnerability in August 2014.
Extension Masque Attack can break the restrictions of app data container. A malicious app extension installed along with an in-house app on iOS 8 can either gain full access to a targeted app’s data container or prevent the targeted app from accessing its own data container. On June 14, security researchers Luyi, Xiaofeng et al. disclosed several severe issues on OS X, including a similar issue with this one [5]. They did remarkable research, but happened to miss this on iOS. Their report claimed: “this security risk is not present on iOS”. However, the data container issue does affect all iOS 8.x versions prior to iOS 8.4, and can be leveraged by an attacker to steal all data in a target app’s data container. We independently discovered this vulnerability on iOS and notified Apple before the report [5] was published, and Apple fixed this issue as part of CVE-2015-3725.
In addition to these two vulnerabilities patched on iOS 8.4, we also disclose the detail of another untrusted code injection attack by replacing the VPN Plugin, the Plugin Masque Attack. We reported this vulnerability to Apple in Nov 2014, and Apple fixed the vulnerability on iOS 8.1.3 when Apple patched the original Masque Attack (App Masque) [6, 11]. However, this exploit is even more severe than the original Masque Attack. The malicious code can be injected to the neagent process and can perform privileged operations, such as monitoring all VPN traffic, without the user’s awareness. We first demonstrated this attack in the Jailbreak Security Summit [7] in April 2015. Here we categorize this attack as Plugin Masque Attack.
We will discuss the technical details and demonstrate these three kinds of Masque Attacks.
Manifest Masque: Putting On the New, Taking Off the Old
To distribute an in-house iOS app with enterprise provisioning wirelessly, one has to publish a web page containing a hyperlink that redirects to a XML manifest file hosted on an https server [1]. The XML manifest file contains metadata of the in-house app, including its bundle identifier, bundle version and the download URL of the .ipa file, as shown in Table 1. When installing the in-house iOS app wirelessly, iOS downloads this manifest file first and parse the metadata for the installation process.
<a href="itms-services://?action=downloadmanifest&url=https://example.com/manifest. plist">Install App</a>
<plist> <array> <dict> ... <key>url</key> <string>https://XXXXX.com/another_browser.ipa</string> ... <key>bundle-identifier</key> <string>com.google.chrome.ios</string> … <key>bundle-version</key> <string>1000.0</string> </dict> <dict> … Entries For Another App </dict> <array> </plist> |
Table 1. An example of the hyperlink and the manifest file
According to Apple’s official document [1], the bundle-identifier field should be “Your app’s bundle identifier, exactly as specified in your Xcode project”. However, we have discovered that iOS doesn’t verify the consistency between the bundle identifier in the XML manifest file on the website and the bundle identifier within the app itself. If the XML manifest file on the website has a bundle identifier equivalent to that of another genuine app on the device, and the bundle-version in the manifest is higher than the genuine app’s version, the genuine app will be demolished down to a dummy placeholder, whereas the in-house app will still be installed using its built-in bundle id. The dummy placeholder will disappear after the victim restarts the device. Also, as shown in Table 1, a manifest file can contain different apps’ metadata entries to distribute multiple apps at a time, which means this vulnerability can cause multiple apps being demolished with just one click by the victim.
By leveraging this vulnerability, one app developer can install his/her own app and demolish other apps (e.g. a competitor’s app) at the same time. In this way, attackers can perform DoS attacks or phishing attacks on iOS.
Figure 1. Phishing Attack by installing “malicious Chrome” and demolishing the genuine one
Figure 1 shows an example of the phishing attack. When the user clicks a URL in the Gmail app, this URL is rewritten with the “googlechrome-x-callback://” scheme and supposed to be handled by Chrome on the device. However, an attacker can leverage the Manifest Masque vulnerability to demolish the genuine Chrome and install “malicious Chrome” registering the same scheme. Other than requiring the same bundle identifier to replace a genuine app in the original Masque Attack [xx], the malicious chrome in this phishing attack uses a different bundle identifier to bypass the installer’s bundle identifier validation. Later, when the victim clicks a URL in the Gmail app, the malicious Chrome can take over the rewritten URL scheme and perform more sophisticated attacks.
What’s worse, an attacker can also exploit this vulnerability to demolish all system apps (e.g. Apple Watch, Apple Pay UIService, App Store, Safari, Health, InCallService, Settings, etc.). Once demolished, these system apps will no longer be available to the victim, even if the victim restarts the device.
Here we demonstrate this DoS attack on iOS 8.3 to demolish all the system apps and one App Store app (i.e. Gmail) when the victim clicks only once to install an in-house app wirelessly. Note that after rebooting the device, all the system apps still remain demolished while the App Store app would disappear since it has already been uninstalled.
