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

3

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

apps, as for the Facebook login.

https://www.fireeye.com/blog/threat-research/2015/02/ios_masque_attackre.html

This way iOS launches the enterprise-signed app registered to handle the URL scheme without

prompting for trust, even if the user has always clicked “Don’t Trust”. It doesn’t matter whether

the user has launched that enterprise-signed app before.

This can be used in order to mount phishing attacks and steal credentials when the UI of the

original app is mimicked, or launch the malicious app although the lack of trust by the user.

This vulnerability has been fixed in iOS 8.1.3.

A very detailed list of all the URL Schemes registered by the apps can be found at this link:

http://handleopenurl.com.

It is also important to note that there is another type of Masque Attack that can be

accomplished via URL Schemes Hijacking. In fact, according to iOS Developer Library3, “If

more than one third-party app registers to handle the same URL scheme, there is currently no

process for determining which app will be given that scheme”.

So, the attackers can publish an app directly into the App Store that registers URL Schemes

identical to the ones of legitimate popular apps, with the exception of the ones predefined by

Apple. Through this, attackers can reproduce a legitimate app UI to perform phishing attacks to

steal credentials or gather data intended to be shared between two trusted apps.

This vulnerability has not yet been fixed.

https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/

iPhoneOSProgramming Guide/Inter-AppCommunication/Inter-AppCommunication.html

CHAPTER 4

10

4. Results:

Files accessible by the new app

At this point it is very interesting to verify what files are accessible by the new application.

Clearly, the new application is not able to access files outside its sandbox but it could be able to

access other files left by the previous installation.

Below all the tests performed will be listed and the used code and related log output will be

provided.

4.1 Preferences File

Each application saves its settings inside a file in the sandbox at the Library/Preferences path.

This file is automatically created at the application’s first launch.

The following code was used to verify if the new app can access the preferences file created by

the previous application:

NSUserDefaults *prefs = [NSUserDefaults standardUserDefaults];

NSString *value1 = [prefs stringForKey:@"TCCardRuntimePlatform"];

NSLog(@"Value of the key TCCardRuntimePlatform in the Preferences file: %@", value1);

NSString *value2 = [prefs stringForKey:@"appVersion"];

NSLog(@"Value of the key appVersion in the Preferences file: %@", value2);

NSString *value3 = [prefs stringForKey:@"previousApplicationVersion"];

NSLog(@"Value of the key previousApplicationVersion in the Preferences file: %@", value3);

From the application log it is possible to see that all the value are correctly read:

Twitter[1708] <Warning>: Value of the key TCCardRuntimePlatform in Preferences file:

iPhone-12

Twitter[1708] <Warning>: Value of the key appVersion in Preferences file: 6.21.1

Twitter[1708] <Warning>: Value of the key previousApplicationVersion in Preferences file:

6.21.1

So, the Preferences file created by the substituted application results to be perfectly readable by

11

the new application.

4.2Keychain access

Keychain is a ciphered SQLite database where it is advisable to store sensitive application data

such as passwords.

By default the sandbox on iOS is also enforced for the Keychain: an app can access only its

own Keychain entries.

4.3 Access to the bundle’s files

This check was done to make sure that the old files in the bundle were completely substituted

by the new ones.

The following code was used to verify the version of the new bundle available inside the

Info.plist file:

NSString *appVersion = [[NSBundle mainBundle]

objectForInfoDictionaryKey:@"CFBundleVersion"];

NSLog(@"Bundle App version in Info.plist file: %@", appVersion);

As it is possible to see from the following log, the bundle version displayed is 1 (that was set by

Minded Security on the Xcode project for the new app), while the original version at the time of

writing was the 6.21.1:

Twitter[1708] <Warning>: Bundle App version in Info.plist file: 1

Another test was done to check that files belonging to the old bundle, and surely not present in

the new one, were disappeared.

As an example, searching for the file favorite.vector available in the previous application’s

bundle:

NSString *filePath = [[NSBundle mainBundle] pathForResource:@"favorite"

ofType:@"vector"];

NSString *myText = [NSString stringWithContentsOfFile:filePath];

12

if (myText) {

NSLog(@"favorite.vector exists");

}

NSLog(@"favorite.vector file contents: %@", myText);

The following log is obtained:

Twitter[1708]: (null)

Bundle of the application, as expected, is completely overwritten by that of the new one without

leaving any old files.

4.4Access to the files in the sandbox

The last test was dedicated to checking which files in the sandbox could be accessed by the new

application.

In particular, the code used to read the content of the Documents folder is presented next. This

directory is where you write data that the application generates during runtime and that you

want to persist between runs of the application. Moreover, it is backed up when the device is

synchronized with iTunes or iCloud.

So it is possible to infer that the new application is able to access the files that were in the

sandbox of the previous installed app.

CHAPTER 5

5. Remediation

Masque Attack is one of the few attacks also effective on non jailbroken Apple iOS device and

13

so it is a very interesting topic to analyze.

In this paper it was successfully verified that a legit application on a device can be overwritten

with a malware app that has the same bundle identifier. This app can be installed by the user via

OTA using an enterprise provisioning profile (stolen ones are not difficult to find).

The files belonging to the previous application that can be accessed by the new one are the

following:

Preferences File

Files in the sandbox (Documents, Library/Preferences, Library/Caches, etc.)

Bundle files are instead completely substituted by the new installation.

Furthermore, the access on Keychain entries related to the previous installation is forbidden due

to the fact that is not possible to forge a provisioning file with an arbitrary AppID, unless the

vulnerability .

Moreover, it has been discovered that the alert that prompts the user when an enterprise-signed

app is launched for the first time can be easily bypassed leveraging the present implementation

of URL Schemes.

As a last thing, it is notable that at this time the URL Scheme Hijacking vulnerability has not

yet been fixed.

On 27 Jan 2015, Apple released iOS 8.1.3. This update fixes this vulnerability

(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4493); moreover now iOS also

prompts for trust when first opening an enterprise-signed application improving code signature

validation (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-20144494) also when URL

Schemes are used.

So, it is advisable to use only Apple devices with iOS >= 8.1.3 in order to surely defense from

this threat. Note that the URL Schemes Hijacking vulnerability has not yet been fixed.

iOS users can protect themselves from Masque Attack by following these 4 steps:

Update iOS on the device to a version >= 8.1.3 as suggested above. Note that the URL

Schemes Hijacking vulnerability has not yet been fixed

14

Don’t install apps from third-party sources other than Apple’s official App Store or the user’s

own organization

Don’t click “Install” on a pop-up from a third-party web page

When opening an app, if iOS shows an alert with “Untrusted App Developer”, click on

“Don’t Trust” and uninstall the app immediately. Nevertheless note that this alert can be

bypassed if iOS >= 8.1.3 is not installed.

iOS developers can mitigate the impact of Masque Attack on their apps and users following

(a mix of) these advice:

On the app first launch check if the app is installed on a device that has iOS 8.1.3 onwards. If

this is not the case, alert the users of the possible threat. In order to do that check the [UIDevice

currentDevice].systemVersion property.

On the Xcode app project, set the Deployment target to 8.2 when it will be available. Note

that in this way only users with an iOS version >= 8.2 will be able to run the application

Enforce the use of all the best practices for writing secure iOS code: cipher all the sandbox

file and store sensitive information on the Keychain only, as this is a safe place against this kind

of attack.

Think about using a push notification service in order to check if an app is already on the

device or it has been uninstalled. In particular, check the related Feedback Service

(https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptua

l/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/T

P40008194-CH101-SW3).

In a scenario where an attacker could reuse the original binary and insert only a backdoor

inside, a mitigation might be found implementing a check at the start of the application in order

to verify the AppID of the app. If the AppID is not equal to the right hardcoded one, the app

closes. This assumes that the AppID of the malware app is different from the original one and

that the check is not bypassed. See the following link for an implementation idea:

http://stackoverflow.com/questions/11726672/access-appidentifier-prefix-programmatically .

15

GLOSSARY

Mobile provisioning :A mobile provisioning profile4 creates an association between an

application and a developer/organization: that is, a link between a developer certificate and an

AppID is created. More on AppID in the next section.

AppID: The AppID is an important asset of the code-signing process. It specifies which are the

applications authorized by the profile to be signed and launched. This identifier is a string

composed by two parts:

1. The Team ID, provided by Apple and unique for each development team

16

2. The bundle identifier of the single application. The AppID is located inside the provisioning file.

Bundle Identifier: Bundle Identifier is the unique string that precisely identifies a single

application. It is typically composed by two parts:

1. One related to the company identifier

2. One related with the product name inserted during the setting of the Xcode project.

17