Report on Masque attack on iOS

1. 1
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."

2. 2
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 sourceother 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 toolsuch as iPhone Configuration Utility or Xcode needs to be used to view and
delete installed profiles.
If you suspectyou 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 forany
associated accounts.

3. 3
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 approachwould limit how many
devices could be targeted. Forthis 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

4. 4
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.).

5. 5
On the other hand, Keychain entries and pre-attack bundle’s file seem to remain safely
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:
replaces one that is regularly installed;
all the unencrypted data stored by the previous app, but
the Keychain, and send them to their servers;
can steal the related credentials;
launching enterprise-signed apps for the first time;
to perform phishing attacks to steal credentials or gather data intended to be shared
between two trusted apps.

6. 6
CHAPTER 3
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:

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

8. 8
 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:

9. 9
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:
evice with iOS 8.1.2 installed
pp like, for example, Facebook
-signed app registering an URL Scheme identical to that used by the
previous app. So, it is possibleto create an enterprise-signed app registering an URL
Schemes used by Facebook, fb://, and bypass the alert prompt calling that URL

10. 10
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 Facebooklogin.
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’tmatter 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 fordetermining 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 reproducea 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/iPhoneOSPr
ogramming Guide/Inter-AppCommunication/Inter-AppCommunication.html

11. 11
CHAPTER 4
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 sandboxbut it could
be able to access other files left by the previous installation.
Below all the tests performed will be listed and the used codeand related log output
will be provided.
4.1 PreferencesFile
Each application saves its settings inside a file in the sandboxat the
Library/Preferences path. This file is automatically created at the application’s first
launch.
The following codewas 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);

12. 12
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.
4.2Keychainaccess
Keychain is a ciphered SQLite database where it is advisable to store sensitive
application data such as passwords.
By default the sandboxon 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 codewas 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 possibleto see from the following log, the bundle version displayed is 1 (that
was set by Minded Security on the Xcodeproject 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

13. 13
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.
4.4Accessto the files in the sandbox
The last test was dedicated to checking which files in the sandboxcould be accessed
by the new application.
In particular, the codeused 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 possibleto infer that the new application is able to access the files that were in
the sandboxof the previous installed app.

14. 14
CHAPTER 5
5. 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 bythe new one are
the following:
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 possibleto 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

15. 15
also prompts for trust when first opening an enterprise-signed application improving
codesignature 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:
>= 8.1.3 as suggested above. Note that the
URL Schemes Hijacking vulnerability has not yet been fixed
-party sources other than Apple’s official App Store or
the user’s own organization
-up from a third-party web page
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:
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.
available. Note that in this way only users with an iOS version >= 8.2 will be able to
run the application
sandboxfile and store sensitive information on the Keychain only, as this is a safe
place against this kind of attack.
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

16. 16
Service
(https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptua
l/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid
/T P40008194-CH101-SW3).
backdoorinside, 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. Seethe following
link for an implementation idea: http://stackoverflow.com/questions/11726672/access-
appidentifier-prefix-programmatically .

17. 17
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 bytwo 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.
Bundle Identifier: Bundle Identifier is the unique string that precisely identifies a single
application. It is typically composedbytwo parts:
1. One related to the company identifier
2. One related with the productname inserted during the setting of the Xcodeproject.