Return of the Masque Attack

Unpatched iOS Vulnerabilities Leave All Users at Risk

Late last year, Lacoon published its insights on two related iOS threats. Wirelurker, one of the first significant malwares to affect non-jailbroken devices, and Masque Attack, the actual vulnerability in iOS that Wirelurker exploits, proved a lethal combination. This post discusses Lacoon’s insights on another aspect of the original Masque Attack, URL Scheme Hijacking.

Masque Attack is unique and particularly dangerous because it takes advantage of a security flaw in iOS that allows an app to be replaced by another app of same Bundle ID – regardless of the developer.

Essentially, Masque enables attackers to replace genuine apps with malware by way of social engineering. Contact can be made via SMS, email, or within a malicious web page. Even more concerning are the facts that once a legitimate app has been replaced with a malicious version, the original user data is still there as well as Masque Attack’s capability to affect non-jailbroken iOS devices.

After learning that, Apple was notified and ultimately fixed some of the issues, but Lacoon decided to take a closer look. Attackers can no longer install malicious apps with the same “bundle identifier” like that of a legitimate app. However, we’ve seen that despite some of the problems being solved, iOS 8.1.3 remains vulnerable to several forms of Masque-based attacks.

Some technical background:

iOS’s URL scheme mechanism is used for inter-app communication. An app can register to a URL scheme (e.g. todolist://) using the Info.plist file. When another app calls the openURL API, iOS will check if the prefix is a registered URL scheme, and if so which app is registered to it. If iOS finds an appropriate app, it will launch it.

An app can register to every URL scheme except the one predefined by Apple (e.g. http, mailto, Facetime, Apple Messenger, etc.). These schemes will always be accessed by Apple’s apps – meaning other apps can’t hijack them.

The problem lies in one of the features of the URL Scheme framework. Although it seems deliberate, the fact that apps from different developers can share the same URL schemes opens the door to malware.

How can an attacker exploit this vulnerability?

It can be used to bypass the “Do you trust this developer” screen, which is displayed the first time the user opens an app signed by an enterprise certificate. The malicious app can register to different URL schemes, and when another app opens the URL matching the scheme, the malicious app will be executed without bringing up the confirmation screen.

A malicious app can hijack an existing scheme so that the malicious app will be launched instead of the intended app. For example, a malicious app can hijack Google Chrome’s URL scheme (e.g. googlechrome://). If and when a user clicks on a link from the within the Gmail app, for example (instead of actively opening chrome), the malicious app will be executed.

It’s important to note that while the first bullet relies on using enterprise certificates to make the malicious apps seem legitimate and verified, the second doesn’t. It can be implemented and exploited when impersonating an app from the regular Apple app store.

What’s our bottom line?

First and foremost, URL Scheme Hijacking (a convenient title for this type of attack) may pose quite a significant challenge for Apple. It’s essentially part of the basic iOS architecture and, therefore, can’t be  eliminated easily.

As we’ve mentioned before, in a world where non-jailbroken devices are also vulnerable to attack, there are several best practices that can help minimize your enterprise’s exposure to social engineering threats. More than anything, sticking to the official Apple App Store can help a lot but even that isn’t 100% foolproof.

Lacoon’s Mobile Security solution is designed to detect apps signed with enterprise certificates, alerting users and their organizations when a potentially malicious app is about to be installed on a supported device.