Enterprise iPhones and iPads are still vulnerable to masque attacks because of a fundamental flaw in the way Apple’s mobile operating system iOS launches apps, according to security researchers at FireEye.
In November 2014, the researchers uncovered a major flaw in iOS enabling what they dubbed masque attacks that allowed for malicious apps to replace existing, legitimate ones through a malicious link masquerading as an update for the app.
The researchers said they had notified Apple of a second flaw related to masque attacks, but only part of it has been fixed in the iOS 8.1.3 security content update issued in February 2015.
The so-called masque attack II includes bypassing the iOS “Trust” prompt and hijacking the iOS URL scheme. Although earlier versions remain vulnerable, the iOS 8.1.3 update fixed the trust issues for that version, but all versions remain vulnerable to the iOS URL scheme hijacking, the researchers said in a blog post.
According to FireEye, the iOS app URL scheme lets developers communicate with other apps through a protocol that they define. But by deliberately defining the same URL schemes used by other apps, a malicious app can hijack communications to those apps and mount phishing attacks to steal login credentials.
“Even worse than the first masque attack, attackers might be able to conduct masque attack II through an app in the App Store,” the researchers said.
iOS trust prompt provides inadequate security
The first part of the masque attack II involves bypassing the prompt for trust. When a user clicks to open an enterprise-signed app for the first time, iOS asks whether the user trusts the signing party. The app will not launch unless the user chooses Trust.
More on mobile malware
“Apple suggested defending against masque attacks by the aid of this Don’t Trust prompt. We notified Apple that this was inadequate,” the researchers said.
They discovered that when calling an iOS URL scheme, iOS launches the enterprise-signed app registered to handle the URL scheme without prompting for trust. They found that it does not 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 the user’s Trust or even ignores Don’t Trust requests. An attacker can leverage this issue to launch an app containing a masque attack,” the researchers said.
By crafting and distributing an enterprise-signed piece of malware that registers app URL schemes identical to the ones used by legitimate popular apps, an attacker may hijack the URL schemes of legitimate apps and mimic their user interface to carry out phishing attacks to steal the login credentials, for example.
MORE ON Apple iOS security
“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 an app URL scheme,” the researchers said.
Other methods they discovered to bypass Don’t Trust protection have been acknowledged by Apple in CVE-2014-4494 and fixed in the iOS 8.1.3 security content update.
But, as measured by the App Store on 2 February 2015, 28% of devices use iOS version 7 or lower, which are still vulnerable, the researchers said.
“Of the 72% of 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,” they said.
Shared iOS URL schemes leave users open to phishing attacks
The second part of the masque attack II involves the hijacking of the iOS URL scheme.
According to the 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”.
However, the researchers found that when two apps register the same URL scheme, iOS always launches the same one to handle it.
This means malicious, third-party app developers can register the same URLs as popular app developers and force the iOS device to launch the malicious app instead of the intended one.
But they also found that one app can block another app from handling the same URL scheme if the developer crafts the bundle ID carefully.
The researchers noted that the mechanism of URL scheme handling seems to be treated more like a feature than a bug by the iOS App Store, which allows apps from different developers to share the same URL schemes.
Read about Google Android security
They found that on the iOS App Store, the two apps Bascom Anywhere Filter Browser and Chrome – web browser by Google 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 the Safari browser which uses the scheme “googlechrome://” or “googlechromes://”.
The researchers found that 28 App Store apps all registering the URL scheme “fb://”, which is one of the URL schemes registered by the Facebook app.
Of these 28 apps, 16 are not from Facebook. At least 8,048 App Store apps register the same URL scheme “fb118493188254996” and many of these apps are from different developers, they said.
This means 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 user interface to carry out phishing attacks to steal login credentials or intercept data intended to be shared only between two trusted apps.
The researchers said fixing URL scheme hijacking may not be easy for Apple, but added that they have disclosed only two of four kinds of masque attack they have discovered and reported to Apple. The other two are still being fixed by Apple, the researchers said.