Protecting Users from iOS App Provisioning Profile Abuse

Recently, we announced the discovery of WireLurker, a new family of malware that abuses app provisioning profiles to install potentially malicious apps on any iOS device, regardless of whether it is jailbroken.  Shortly after, FireEye highlighted the Masque Attack, which also relies on malware apps signed by provisioning profiles and had previously been disclosed by Steffen Esser. Both attacks highlight the importance of provisioning profile management in Mobile Device Management (MDM) solutions.  In this post, we explain how to protect users from iOS app provisioning profile abuse attacks with Palo Alto Networks GlobalProtect Mobile Security Manager product.

Provisioning Profiles on iOS

As stated in the iPhone Developer Program:

“A provisioning profile is a collection of digital entities that uniquely ties developers and devices to an authorized iPhone Development Team and enables a device to be used for testing. A Development Provisioning Profile must be installed on each device on which you wish to run your application code. Each Development Provisioning Profile will contain a set of iPhone Development Certificates, Unique Device Identifiers and an App ID. Devices specified within the provisioning profile can be used for testing only by those individuals whose iPhone Development Certificates are included in the profile. A single device can contain multiple provisioning profiles.” – iPhone Developer Program

Before we continue, we want to highlight several important facts about the provisioning profiles on iOS devices.

First, provisioning profiles are only intended to be used for internal purposes, either testing or enterprise deployment. If a user only installs apps from the Apple App Store, no provisioning profile needs to be installed on their iOS devices.

Second, if a user installs an app that is not from the Apple App Store that is signed by a provisioning profile, this profile will be installed on the iOS device and can be logged by an installed MDM app.

Third, in an enterprise environment, if there is an app signed by a provisioning profile on a managed iOS device, this provisioning profile should be under the control of the company’s IT department. Again, Apple’s policy requires that these profiles only be used internally.

Therefore, if the IT admin observes iOS devices with provisioning profiles not under his/her management, this should be enough to trigger an alarm and initiate response actions.

MDM on iOS

The MDM interface on iOS is very restricted. From the MDM server, an IT admin can only view a brief summary of the apps installed on every device, along with provisioning profiles. FireEye’s Masque Attack blog states:

The MDM interface couldn’t distinguish the malware from the original app, because they used the same bundle identifier. Currently there is no MDM API to get the certificate information for each app. Thus, it is difficult for MDM to detect such attacks.

We agree that with such limited information the MDM server cannot build a correlation between the apps and the provisioning profiles. Without correlation, an IT admin cannot distinguish whether an app is malware or legitimate. However, the provisioning profiles themselves can be used to determine whether malware or unauthorized apps have been installed on the device.

Proposed Approach with MDM on iOS

To detect these attacks, we recommend that IT admins maintain an allowlist and denylist of provisioning profiles.

Under this model, the allowlist contains the provisioning profiles under the company’s management. An example includes a provisioning profile used for internal app development and testing. Managed iOS devices would be allowed to install apps with those provisioning profiles.

The denylist contains publicly known bad/abused provisioning profiles. We also suggest including any expired or revoked provisioning profiles from previous internal use.

As noted above, an IT admin can use MDM solutions to build a mapping between the provisioning profiles installed and the associated devices. For example, this mapping could be built using the GlobalProtect Host Information Profile (HIP) reports collected from managed iOS devices. If the IT admin observes any provisioning profile not in the allowlist or one that is on the denylist, that profile would trigger an alarm. Considering the severe risks outlined in the WireLurker and Masque Attack reports, it would be both reasonable and responsible for an IT admin to initiate action on a device with unwanted provisioning profiles.

To help our users to discover potentially malicious profiles, we’ve developed a tool that interacts with the GlobalProtect Mobile Security Manager command line interface to locate unwanted provisioning profiles.  This tool allows administrators to identify all profiles deployed on devices they control, denylist and allowlist specific profiles and display a list of profiles that require additional attention. The tool is available on GitHub here, and includes a full readme with information on prerequisites and usage instructions.

We would like to thank Marc Benoit, Kevin Steves, Rohan Davuluri, Wayne Fiori, Jen Miller-Osborn, Joby Menon and Siu-wang Leung of Palo Alto Networks for their help and efforts in creating this solution and producing this blog.