ABSTRACT Masque Attack is the name of an iOS vulnerability identified and named by computer security company FireEye, Inc. in July of 2014. FireEye privately informed Apple Inc. of the issue on July 26, 2014 and disclosed the vulnerability to the public on November 10, 2014 through a blog post on their website. The vulnerability is identified to exist on iOS 7.1.1, 7.1.2, 8.0, 8.1 and 8.1.1 beta, and on jailbroken and non-jailbroken iOS devices. The vulnerability consists of getting users to download and install apps that have been deceptively created with the same bundle identifier as an existing legitimate app. The deceptive app can then replace and pose as the legitimate app, as long as the app was not one pre-installed along with iOS (i.e., the default Apple apps) - and thus, the reason FireEye gave for naming the vulnerability "Masque Attack." 1
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ABSTRACT Masque Attack is the name of an iOS vulnerability identified and named by computer security
company FireEye, Inc. in July of 2014. FireEye privately informed Apple Inc. of the issue on July 26,
2014 and disclosed the vulnerability to the public on November 10, 2014 through a blog post on their
website. The vulnerability is identified to exist on iOS 7.1.1, 7.1.2, 8.0, 8.1 and 8.1.1 beta, and on
jailbroken and non-jailbroken iOS devices. The vulnerability consists of getting users to download and
install apps that have been deceptively created with the same bundle identifier as an existing legitimate
app. The deceptive app can then replace and pose as the legitimate app, as long as the app was not one
pre-installed along with iOS (i.e., the default Apple apps) - and thus, the reason FireEye gave for
naming the vulnerability "Masque Attack."
1
CHAPTER 1
1. INTRODUCTION
Masque Attack was described by FireEye mobile security researchers Stefan Esser of SektionEins, and Jonathan Zdziarski. This attack works by luring users to install an app from a source other than the iOS App Store or their organizations’ provisioning system. In order for the attack to succeed, a user must install an untrusted app, such as one delivered through a phishing link.
This technique takes advantage of a security weakness that allows an untrusted app—with the same “bundle identifier” as that of a legitimate app—to replace the legitimate app on an affected device, while keeping all of the user’s data. This vulnerability exists because iOS does not enforce matching certificates for apps with the same bundle identifier. Apple’s own iOS platform apps, such as Mobile Safari, are not vulnerable.
A Masque Attack takes advantage of this behavior by intentionally overwriting an existing app and then attempting to look and behave the same as the original app. Once installed, if the developer of the original app hasn't encrypted their locally stored data, the Masque Attack app could access that data. The fake app could also try and trick you into entering account information by, for example, showing you a fake login page that sends your credentials to a server owned by the attacker.
To avoid Masque and similar attacks, all that's required is to avoid downloading any apps from outside Apple's official App Store, and denying permission for any untrusted app to install.
If you think you've already fallen victim to such an attack, you can check in iOS 7 by navigate to Settings > General > Profiles. Any profiles used to install a non-App Store app will be shown here and can be deleted.
Unfortunately Apple removed the ability to see these profiles on the device in iOS 8, and a tool such as iPhone Configuration Utility or Xcode needs to be used to view and delete installed profiles.
If you suspect you have already installed a Masque app, it can be removed by deleted the affected app and re-installing it cleanly from App Store. Of course, if you do think an app you have was subjected to an attack, you should change all passwords for any associated accounts.
2
1.1 . History
"Masque Attack" is the new name—given by the security firm FireEye—to an old trick intended to fool you into installing malicious apps on your iPhone or iPad. Most recently detailed by security researcher Jonathan Zdziarski, tricks like Masque Attack won't affect most people, but it's worth understanding how it works and, in the event you are targeted, how to avoid it.
Apple has a lot of safeguards built into iOS. A Masque attack tries to get you to circumvent those safeguards and install malicious apps anyway.
In order to make a Masque attack work, an attacker has to:
1. Have an iOS Developer Enterprise Program account or the universal device identifier (UDID) for the device they want to target.
2. Make a malicious app that looks like a popular, existing app. (A fake Gmail app that simply loads the Gmail website in FireEye's example.)
3. Get you to download their fake app from outside the App Store. (For example, by sending you an email with a link in it.)
4. Get you to agree to the iOS popup that warns you the app you're trying to install is from an untrusted source.
Getting a device's UDID is non-trivial and this approach would limit how many devices could be targeted. For this reason, attackers try to get iOS Developer Enterprise Program accounts instead. Enterprise-signed apps can be installed on any device, making enterprise-signed malware easier to distribute and spread. However, Apple has the ability to revoke enterprise certificates at any time, preventing any apps signed by that certificate from ever launching again. That's why this type of attack is much more likely to be used in a targeted manner against a specific individual or group of individuals, than to be exploited in the wild targeting a large group of users.
A Masque attack app is one that overwrites and potentially imitates an existing App Store app (built-in Apple apps can't be overwritten). It does this by using the same bundle ID as the legitimate app. Bundle IDs are identifiers that must be unique between apps on a device. Installing a new app that has the same bundle ID as an existing app will result in the original app being overwritten by the new one.
Apple requires App Store bundle IDs to be unique, which is why this type of attack can't be performed with apps downloaded from the App Store.
It's important to note that this isn't a recent change and isn't a bug—this is how things are designed to work. In fact, this very functionality is used by many developers for legitimate purposes. It works because bundle IDs are not necessarily tied to specific certificates or
developer accounts. Apple may change this in the future to address security issues like this, but it will be difficult to do without having some negative impact on developers.
CHAPTER 2
2.1 How it works
Fig.2.1 How the attack exeutes
Besides the application personification effect, the malicious app will be able to steal all data
saved in the directories shared with the original app (i.e. Local Data Cache, Preferences file,
etc.).
On the other hand, Keychain entries and pre-attack bundle’s file seem to remain safely
4
protected from unauthorized read.
Furthermore, it has been found that the trust alert prompted at the first launch of an enterprise-
signed app can be easily bypassed exploiting the present URL Schemes implementation.
iOS version 7.x and 8.x (< 8.1.3) are affected by this issue on both jailbroken and non
jailbroken devices.
Furthermore, the Masque Attack via URL Scheme Hijacking vulnerability has not yet been
fixed.
2.2 Threat scenarios of the Masque Attack
These are the main threat scenarios of this kind of attack:
Non jailbroken iOS Apple devices are threatened too;
A user may not be conscious of having a malicious app on his device because it replaces one
that is regularly installed;
The malicious app can read all the unencrypted data stored by the previous app, but the
Keychain, and send them to their servers;
The malicious app can mount a phishing attack mimicking the original UI app and it can steal
the related credentials;
The malicious app can be launched although the presence of an alert prompt when launching
enterprise-signed apps for the first time;
The malicious app can hijack the URL Schemes of a legitimate popular app in order to
perform phishing attacks to steal credentials or gather data intended to be shared between two
trusted apps.
CHAPTER 3
5
3. Attack Execution and results of Analysis
3.1 Environment Setup
An enterprise provisioning profile matched with a developer certificate were used to
perpetrate the attack: the public key inside the first file is related to the private key of the
certificate installed on the host where the compilation of the app is performed.
The app is installed on the device via OTA, using a local HTTPS web server.
It has to be noticed the fact that developer certificates and mobile enterprise provisioning
files can be easily found on Internet through ad-hoc Google dorks.
3.2. Attack Execution
The app used as an example for the attack is Twitter, downloadable from the App Store at
the time of writing.
Bundle Identifier of the app Twitter: com.atebits.Tweetie2.
Following a picture related to the pre-attack test device Springboard is shown:
6
Fig.3.2 Preattack Test device
As it is possible to see, the Twitter app downloaded from the App Store results to be
regularly installed.
Connecting to the URL where the web server used for the OTA installation is placed, it is
possible to see the following screen:
Then iOS asks to confirm the download. This application has the name equals to the value of
the key “title” inside the manifest.plist:
Clicking on “Install”, the app’s installation is initialized on the device.
7
Clicking on “Install the App”, iOS accesses the manifest.plist file loaded on the web
server.
Then iOS asks to confirm the download. This application has the name equals to the
value of the key “title” inside the manifest.plist.
Clicking on “Install”, the app’s installation is initialized on the device.
The application presents a different Display Name and default icon in order to make the
substitution clear, but it is possible to use the original icon and name used by the real
Twitter application.
3.3 Masque Attack via URL Schemes
On 19 February 2015 FireEye security researchers have presented a new kind of Masque Attack
exploiting URL Schemes vulnerabilities2.
On iOS 8, whenever a user is launching an enterprise-signed app for the first time, he is asked
to trust or not the new signing party, as can be seen from the following screenshot:
8
Fig.3.3 Attack via URL schema
If a user clicks on “Don’t trust” the app does not open.
It has been discovered that this precaution is not enough: indeed, it is possible to bypass this
alert message exploiting the present implementation of URL Schemes.
This can be demonstrated using the following setup:
An Apple device with iOS 8.1.2 installed
A widespread installed app like, for example, Facebook
An enterprise-signed app registering an URL Scheme identical to that used by the previous
app. So, it is possible to create an enterprise-signed app registering an URL Schemes used by
Facebook, fb://, and bypass the alert prompt calling that URL Scheme to open the malicious
9
app.
Note that, other than Safari, other third-party apps could be using URL Schemes of popular