tl;dr

The User Enrollment MDM option added with iOS 13 does not restrict MDM-deployed certificates to MDM-deployed applications, and in the absence of additional controls such as certificate pinning these certificates are, surprisingly, trusted by personally installed apps. When using User Enrollment on the organization’s Wi-Fi, it is possible for a Corporate Intrusion Detection System to collect personal data by monitoring intercepted traffic.

Background

Many organizations use a Mobile Device Management (MDM) solution to manage access to company resources from mobile phones. As a cost savings measure, some organizations do not supply their employees with work phones, but instead follow a practice known as Bring Your Own Device (BYOD). In BYOD situations, the employer will often deploy a less restrictive MDM solution, which allows the employer to manage the employee’s personal phone.

Typically, the MDM is used to enforce basic security hygiene practices on the user’s phone, with the aim of protecting sensitive corporate data. For example, the MDM can set minimum lock screen password strength requirements, configure mail accounts, VPNs, and so on. iOS now provides a BYOD-specific solution called User Enrollment to help protect a user’s privacy from the organization, while still allowing the organization some measure of control over how the work data on the phone is accessed. Apple provide some details on what the MDM can and can’t see. For example, the MDM can see the device name, serial number, and phone number, but it is not supposed to be able to see personal mail, Safari browser history or the device location.

However, an MDM can also install root certificates onto the employee device. Modern computing devices (including phones and computers) use a set of several hundred root certificates in order to establish that a given website or server represents who it claims to be representing. If someone can install their own root certificate on a device, they can impersonate any site. When paired with TLS traffic interception technology that is often deployed in corporate workplaces, this raises questions as to whether an employer could intercept network traffic originating from a user’s personal applications on their BYOD device.

This blog post covers NCC Group’s research into whether this type of traffic interception is, in fact, possible. Spoiler: It is.

Setup

Setting up User Enrollment is not entirely straightforward due to the requirement for Managed Apple IDs, which are a separate organization-owned Apple ID from the personal Apple ID. Creating one of these requires a valid business with a D-U-N-S number (a unique nine-digit business ID) in order to get access to Apple Business Manager, used not only to create managed Apple IDs, but also as part of the MDM configuration and for purchasing apps and books in bulk. Any MDM provider that supports User Enrollment is expected to be similarly affected, so this blog post is not written with a specific MDM in mind. Our test iPhone was running iOS 14.3 during the enrollment process, and later upgraded to 14.4.

Once a device has been enrolled in the MDM, we deployed a newly generated root certificate from Burp Suite Professional onto the user’s device and configured this in our test MDM configuration. As can be seen in the Certificate Trust Settings screenshot, it is not possible for a user to disable trust in any certificates that were installed by the MDM profile even when using User Enrollment for BYOD devices. This goes against the intended purpose of User Enrollment in that a user cannot disable the MDM-deployed root certificate for their personal apps.

Results

Put simply, in these types of BYOD scenarios, there is no easy way for a user to know whether their connection to a website is secure. The screenshot below shows what the user sees when visiting the https://example.com website.

In our Burp Suite Professional window, however, we see both the request to the site as well as the content in the response. This illustrates that the root certificate installed by the MDM is accepted by an application handling personal data on the user’s device, and that it is possible to collect Safari traffic while connected to the organization’s Wi-Fi. While this should be expected behaviour in a corporate-owned device setting, it might be a surprising result when signing up for a BYOD program with user enrollment because of the descriptions provided on what the MDM can and cannot access. It is also vastly different from the way MDM solutions work on Android, which uses a separate managed certificate store that is not used by personal apps.

Although this evidence was gathered using Burp Suite, the true impact of this issue appears when an organization uses a Corporate Intrusion Detection System (IDS) or Transport Layer Security Inspection (TLSI). Combining these technologies with the ability to push arbitrary root certificates onto the user device would enable the employer to intercept all network traffic originating from the user.

Beyond the evidence presented above, NCC Group also tested several apps from the app store as well as a custom application to demonstrate that the certificates are also trusted by apps other than Apple-provided apps.

Mitigation

Users

There is little that users can do to prevent this, except to use separate phones for work and personal data. In addition to deploying root certificates, User Enrollment also allows the MDM to add a trusted Wi-Fi network to the device. This network will be automatically joined if the MDM configuration says it should be.

Developers

It should already be well-understood that there are a number of ways to intercept traffic for iOS applications. This includes manually configuring proxies, using firewall rules to redirect traffic, and installing user-trusted root certificates. These are often used during the development process, but without certificate pinning an application cannot stop an MDM in combination with a TLSI device from collecting all of the app’s traffic. To mitigate this, implement certificate pinning for any critical domains in use by your application. See Identity Pinning: How to configure server certificates for your app for more details from Apple on recommended ways to do this. Note that this will not protect against all attacks, such as attacks able to compromise the kernel or modify the application’s code.

IT Administrators

While user privacy is not usually the top concern of an MDM administrator, collecting large amounts of personal data on users does carry risks. If for example a TLSI device inadvertently collects a user’s social media passwords, this collection might be in contravention of local employee privacy laws. The decision to utilize BYOD and iOS user enrollment in the first place indicates that the enterprise is not aiming to collect such data from mobile devices with access to corporate data. If that were the goal one of the other MDM options would be a stronger choice. Furthermore, despite some historical compromises certificate authorities do try to ensure strong access controls are placed on their root certificates, likely beyond what many organizations are capable of with their own custom root certificates. If the root certificate is ever compromised, an attacker would be able to use this against all of the devices managed by the MDM. It is possible to use name constraints (see RFC 5280, or Enforcing name constraints on a private CA) to make it impossible to use any of the MDM-deployed certificates to be used for the purposes of traffic interception. Also, if the list of domains being used is not known ahead of time any updates to the list will in many cases require generating a new root certificate which then generates all certificates in use which are then deployed to all servers in use.

Apple

Restrict MDM-deployed root certificates to only those apps that were installed via the MDM. Do not allow MDM-deployed root certificates to interact with the user’s personal apps.

References

Nick Galloway

NCC Group Consultant

iOS User Enrollment and Trusted Certificates