Posté par: igor51 le mai 15, 2019, 16:00:18
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 | valign="top"> |
App Masque | valign="top"> |
URL Masque | valign="top"> |
Manifest Masque | valign="top"> |
Plugin Masque | Fixed |
Extension Masque |
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
<plist> <array> ... ... … <dict> … Entries For Another App <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.
Source: Three New Masque Attacks against iOS: Demolishing, Breaking and Hijacking (http://)