MASQUE ATTACK

PREPARED BY:Shakti Chauhan 12xxxxxxx

Ruchika Jain12xxxxxxx

INTRODUCTION TO MASQUE ATTACK

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.

Masque Attack flow:

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.

SECURITY IMPACTS

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.

Attack Executions

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.

Masque Attack via URL Schemes

How to Protect?

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;

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.

REFERENCES

THANK YOU