iOS Masque Attack Revived: Bypassing Prompt for Trust and App URL Scheme Hijacking

In November of last year, we uncovered a major flaw in iOS we dubbed “Masque Attack” that allowed for malicious apps to replace existing, legitimate ones on an iOS device via SMS, email, or web browsing. In total, we have notified Apple of five security issues related to four kinds of Masque Attacks. Today, we are sharing Masque Attack II in the series – part of which has been fixed in the recent iOS 8.1.3 security content update [2].

Masque Attack II includes bypassing iOS prompt for trust and iOS URL scheme hijacking. iOS 8.1.3 fixed the first part whereas the iOS URL scheme hijacking is still present.

iOS app URL scheme “lets you communicate with other apps through a protocol that you define.” [1] By deliberately defining the same URL schemes used by other apps, a malicious app can still hijack the communications towards those apps and mount phishing attacks to steal login credentials. Even worse than the first Masque Attack [3], attackers might be able to conduct Masque Attack II through an app in the App Store. We describe these two parts of Masque Attack II in the following sections.

Bypassing Prompt for Trust

When the user clicks to open an enterprise-signed app for the first time, iOS asks whether the user trusts the signing party. The app won’t launch unless the user chooses “Trust”.  Apple suggested defending against Masque Attack by the aid of this “Don’t Trust” prompt [8]. We notified Apple that this was inadequate.

We find that when calling an iOS URL scheme, iOS launches the enterprise-signed app registered to handle the URL scheme without prompting for trust. It doesn’t matter whether the user has launched that enterprise-signed app before. Even if the user has always clicked “Don’t Trust”, iOS still launches that enterprise-signed app directly upon calling its URL scheme. In other words, when the user clicks on a link in SMS, iOS Mail or Google Inbox, iOS launches the target enterprise-signed app without asking for user’s “Trust” or even ignores user’s “Don’t Trust”. An attacker can leverage this issue to launch an app containing a Masque Attack.

By crafting and distributing an enterprise-signed malware that registers app URL schemes identical to the ones used by legitimate popular apps, an attacker may hijack legitimate apps’ URL schemes and mimic their UI to carry out phishing attacks, e.g. stealing the login credentials. iOS doesn’t protect users from this attack because it doesn’t prompt for trust to the user when launching such an enterprise-signed malware for the first time through app URL scheme. In Demo Video 1, we explain this issue with concrete examples.

We’ve also found other approaches to bypass “Don’t Trust” protection through iOS springboard. We confirmed these problems on iOS 7.1.2, 8.1.1, 8.1.2 and 8.2 beta. Recently Apple fixed these issues and acknowledged our findings in CVE-2014-4494 in the iOS 8.1.3 security content [2]. As measured by the App Store on 2 Feb 2015 [4], however, 28% devices use iOS version 7 or lower, which are still vulnerable. Of the 72% iOS 8 devices, some are also vulnerable given that iOS 8.1.3 came out in late January 2015. We encourage users to upgrade their iOS devices to the latest version as soon as possible.

iOS Masque Attack: Bypassing Apple’s Prompt for Trust

A demonstration of how enterprise-signed iOS apps that bypass the Apple App Store can also bypass the built-in “Do you trust the developer…” security prompt. (video - 2:13 min)

URL Scheme Hijacking

According to iOS Developer Library, “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” [1]. However, when two apps register the same URL scheme, iOS always launches the same one to handle it in our experiments using multiple iOS versions and device models. Furthermore, one app can block another app from handling the same URL scheme if the developer crafts the bundle id carefully.

The mechanism of URL scheme handling seems more like a “feature” instead of a “bug” for iOS App Store which allows apps from different developers to share the same URL schemes. On iOS App Store, the two apps “BASCOM Anywhere Filter Browser” [5] and “Chrome - web browser by Google” [6] both registered the URL schemes “googlechrome://” and  “googlechromes://”. With both apps installed, an iOS 8.1.3 device launches “BASCOM Anywhere Filter Browser” instead of Google’s Chrome browser when the user clicks on a link shown in Safari browser which uses the scheme “googlechrome://” or  “googlechromes://”.

We’ve also seen 28 App Store apps all registering the URL scheme “fb://”, which is one of the URL scheme registered by the Facebook app. 16 of these 28 apps are not from Facebook. At least 8048 App Store apps register the same URL scheme “fb118493188254996” and many of these apps are from different developers.

Attackers can either publish an “aggressive” app into the App Store, or craft and distribute an enterprise-signed/ad-hoc malware that registers app URL schemes identical to the ones of legitimate popular apps. Through this , attackers can mimic a legitimate app’s UI to carry out phishing attacks to steal login credentials or gather data intended to be shared between two trusted apps.

As an example, the Chrome web browser by Google [6] registers four URL schemes:

"com.google.sso.75882956776-quflk872g5nq29l4p16ql1u6956mehe1", "googlechrome", "googlechromes", "googlechrome-x-callback", "com.google.sso.chrome". One enterprise-signed app that registers the same set of URL schemes on iOS 8.1.3 and earlier versions is able to hijack web links when the user clicks them from the emails in Gmail app, from web pages displayed by Safari or from SMS messages. Demo Video 2 describes one such attack scenario.

Previous studies [9] have also recognized the risk in the way iOS handling the URL schemes. However, bypassing prompt for trust gave enterprise-signed apps the leverage to exploit this issue silently.

iOS Masque Attack: URL Scheme Hijacking

A demonstration of what happens when a malicious app uses the same URL scheme as your favorite popular applications to hijack your browsing sessions. (video - 2:06 min)

Conclusions

Both App Store and iOS treat it as a feature to allow apps from different developers to bear the same URL schemes. Fixing URL scheme hijacking may not be easy for Apple. With this article and a previous one [3], we have disclosed two out of four Masque Attacks, with the other two still being fixed by Apple. As suggested in our VB’14 paper [7], Apple may improve its architecture to collaborate with security vendors for a better enterprise-level security solution. We address this problem in this article to help users better protect themselves.

We thank FireEye team member Joshua Chang for his help in creating the demo videos and Kyrksen Storer for improving this blog.

 

[1] https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html

[2] http://support.apple.com/en-us/HT204245

[3] https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html

[4] https://developer.apple.com/support/appstore/

[5] https://itunes.apple.com/us/app/bascom-anywhere-filter-browser/id390471792?mt=8

[6] https://itunes.apple.com/us/app/chrome-web-browser-by-google/id535886823?mt=8

[7] https://www.virusbtn.com/virusbulletin/archive/2014/11/vb201411-Apple-without-shell

[8] http://support.apple.com/en-us/HT6584

[9] http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes-apples-ios/