main file chapters report on "masque attack"
TRANSCRIPT
ABSTRACT Masque Attack is the name of an iOS vulnerability identified and named by computer security
company FireEye, Inc. in July of 2014. FireEye privately informed Apple Inc. of the issue on July 26,
2014 and disclosed the vulnerability to the public on November 10, 2014 through a blog post on their
website. The vulnerability is identified to exist on iOS 7.1.1, 7.1.2, 8.0, 8.1 and 8.1.1 beta, and on
jailbroken and non-jailbroken iOS devices. The vulnerability consists of getting users to download and
install apps that have been deceptively created with the same bundle identifier as an existing legitimate
app. The deceptive app can then replace and pose as the legitimate app, as long as the app was not one
pre-installed along with iOS (i.e., the default Apple apps) - and thus, the reason FireEye gave for
naming the vulnerability "Masque Attack."
1
CHAPTER 1
1. INTRODUCTION
Masque Attack was described by FireEye mobile security researchers Stefan Esser of SektionEins, and Jonathan Zdziarski. This attack works by luring users to install an app from a source other than the iOS App Store or their organizations’ provisioning system. In order for the attack to succeed, a user must install an untrusted app, such as one delivered through a phishing link.
This technique takes advantage of a security weakness that allows an untrusted app—with the same “bundle identifier” as that of a legitimate app—to replace the legitimate app on an affected device, while keeping all of the user’s data. This vulnerability exists because iOS does not enforce matching certificates for apps with the same bundle identifier. Apple’s own iOS platform apps, such as Mobile Safari, are not vulnerable.
A Masque Attack takes advantage of this behavior by intentionally overwriting an existing app and then attempting to look and behave the same as the original app. Once installed, if the developer of the original app hasn't encrypted their locally stored data, the Masque Attack app could access that data. The fake app could also try and trick you into entering account information by, for example, showing you a fake login page that sends your credentials to a server owned by the attacker.
To avoid Masque and similar attacks, all that's required is to avoid downloading any apps from outside Apple's official App Store, and denying permission for any untrusted app to install.
If you think you've already fallen victim to such an attack, you can check in iOS 7 by navigate to Settings > General > Profiles. Any profiles used to install a non-App Store app will be shown here and can be deleted.
Unfortunately Apple removed the ability to see these profiles on the device in iOS 8, and a tool such as iPhone Configuration Utility or Xcode needs to be used to view and delete installed profiles.
If you suspect you have already installed a Masque app, it can be removed by deleted the affected app and re-installing it cleanly from App Store. Of course, if you do think an app you have was subjected to an attack, you should change all passwords for any associated accounts.
2
1.1 . History
"Masque Attack" is the new name—given by the security firm FireEye—to an old trick intended to fool you into installing malicious apps on your iPhone or iPad. Most recently detailed by security researcher Jonathan Zdziarski, tricks like Masque Attack won't affect most people, but it's worth understanding how it works and, in the event you are targeted, how to avoid it.
Apple has a lot of safeguards built into iOS. A Masque attack tries to get you to circumvent those safeguards and install malicious apps anyway.
In order to make a Masque attack work, an attacker has to:
1. Have an iOS Developer Enterprise Program account or the universal device identifier (UDID) for the device they want to target.
2. Make a malicious app that looks like a popular, existing app. (A fake Gmail app that simply loads the Gmail website in FireEye's example.)
3. Get you to download their fake app from outside the App Store. (For example, by sending you an email with a link in it.)
4. Get you to agree to the iOS popup that warns you the app you're trying to install is from an untrusted source.
Getting a device's UDID is non-trivial and this approach would limit how many devices could be targeted. For this reason, attackers try to get iOS Developer Enterprise Program accounts instead. Enterprise-signed apps can be installed on any device, making enterprise-signed malware easier to distribute and spread. However, Apple has the ability to revoke enterprise certificates at any time, preventing any apps signed by that certificate from ever launching again. That's why this type of attack is much more likely to be used in a targeted manner against a specific individual or group of individuals, than to be exploited in the wild targeting a large group of users.
A Masque attack app is one that overwrites and potentially imitates an existing App Store app (built-in Apple apps can't be overwritten). It does this by using the same bundle ID as the legitimate app. Bundle IDs are identifiers that must be unique between apps on a device. Installing a new app that has the same bundle ID as an existing app will result in the original app being overwritten by the new one.
Apple requires App Store bundle IDs to be unique, which is why this type of attack can't be performed with apps downloaded from the App Store.
It's important to note that this isn't a recent change and isn't a bug—this is how things are designed to work. In fact, this very functionality is used by many developers for legitimate purposes. It works because bundle IDs are not necessarily tied to specific certificates or
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