The Mac Observer published information about a new iOS threat, dubbed “Masque Attack,” which lets attackers replace valid apps with their own malicious apps. Masque Attack affects both non-jailbroken and jailbroken iOS devices running iOS 7.1.1, 7.1.2, 8.0, 8.1, and 8.1.1 beta.
However, before we go any further, let’s talk a little about this “vulnerability” (or as Apple would say, “it’s not a bug, it’s a feature”). To start, nothing here is actually a flaw; there are valid reasons that this exists. Yes, the design opens up a “hole” that can potentially be exploited, but it is also used every day by enterprises.
Following are steps to show how a typical enterprise employee may use this feature.
In the above valid use case, the app keeps working, has access to all the data it had before, and the employee goes about his or her daily activities.
Essentially what this hole is exposing is a design decision made by Apple to keep life easier for enterprises, and a feature many of them use every day.
In order to get to this hole, the attacker must deliver an App ID that has already been installed on the target device. In other words, in FireEye’s example, clicking to install “New Flappy Bird” installs a new Gmail client. If the Gmail client wasn’t already on the device, then the attack is basically meaningless since it didn’t compromise any data.
Moreover, there is a second exploit that Masque Attacks use: Apps that are installed outside of the traditional App Store development process have access to undocumented API’s.
While this is true—perhaps even a dirty little secret—it’s something that enterprises do every day. For example, many enterprises push tools to their IT department to do packet sniffing, wireless network detection, and more. Most of these tools use undocumented API’s, because Apple doesn’t want these API’s exposed to the masses or used in apps on the App Store.
Therefore, while security researchers have documented both of these “holes,” there is nothing here that Apple is most likely going to close without changing the way it deals with enterprises.
Even so, Apple could turn off these bogus apps and the bogus certificate at the flip of a switch, without needing to deploy any operating system updates to do so. They just need to find the malicious enterprise certificate, and then kill it, effectively shutting down the attackers.
iOS 7 enterprise customers can check whether there are apps already installed through Masque Attacks by checking the enterprise provisioning profiles installed on their iOS devices, which indicate the signing identities of possible malware delivered by Masque Attacks, by checking Settings > General > Profiles for “PROVISIONING PROFILES.” If found, deleting a provisioning profile will prevent enterprise signed apps which rely on that specific profile from running.
However, iOS 8 enterprise customers will not show provisioning profiles already installed on the devices.
Apple has changed the rules with iOS 8 so users no longer have to deal with Provisioning Profiles. Provisioning Profiles must now be installed via USB from Xcode, Configurator, or even malware on the Mac as was pointed out by the WireLurker malware, or via MDM or SCEP. The user can’t just install them.
Deleting the suspicious app in iOS 8 also deletes the provisioning profile provided with the app, assuming no other apps need that profile. Profiles automatically get removed by iOS 8 now when they expire.
Nonetheless, it’s possible on iOS 8 that the profile gets imbedded in the app, so if you click Install on the first pop-up, whether from a text or via email, and then click the Trust button when the Untrusted App Developer alert comes up, then the app and the certificate get installed.
The biggest problem at the moment is that iOS 8 users cannot easily identify that they have bogus credentials installed on their device (after doing things that they should not do to begin with).
There are three simple steps to protect yourself from Masque Attacks:
