On DEP, MDM, device identity, and authentication
Recently there’s been increased attention on the security of DEP and MDM. In August at Black Hat, Max Bélanger and me presented our deep dive into MDM & DEP, titled “A Deep Dive into macOS MDM (and How it can be Compromised)”. In that research, we laid out the first documented overview of every stage of the device bootstrap process, and did a deep dive into a certain step of the bootstrap process. In September, Duo presented their own security research at Ekoparty on a different stage of the bootstrap process, titled “MDM Me Maybe: Device Enrollment Program Security”.
Since Duo’s research was released, I’ve noticed a lot of confusion about both the vulnerability and the mitigations they suggested. This post is about clarifying those misunderstandings, and publishing our recommendations on how to safely implement the second mitigation they proposed. Here’s a summary of what we’ll cover:
- The security research performed by Max & I, which laid out all the stages of the bootstrap process, and included a deep dive into a vulnerability we found in one of the stages.
- The security research recently performed by Duo, which focuses on a different stage of the bootstrap process, and allows for spoofing a device’s serial number to Apple’s DEP API.
- The difference between identity, authentication, and authorization.
- The two mitigations suggested by Duo for the vulnerability they found.
- The attacks that are still possible when the second mitigation (mitigation #2) described by Duo is not implemented carefully.
- Fleetsmith’s secure device approval implementation, which has existed in our product from the beginning, and which is essentially a careful implementation of mitigation #2.
- Our recommendations to other MDM vendors on how to safely implement mitigation #2.
Bootstrap overview
In our research, Max and I released the first known documentation that describes every stage of the bootstrap process for DEP and MDM. Duo’s summarized descriptions of each of the stages were an improvement on our original descriptions, so I’ll quote them here while including our diagram:
1. Apple, (or an Apple Authorized Reseller), creates a device record through the DEP API.
2. The organization using DEP to bootstrap MDM enrollment assigns the device to their MDM server in Apple Business Manager. [Apple School Manager may also be used at this step -- Ed].
3. The MDM server retrieves the device record through the DEP API, then creates a DEP profile.
4. The device authenticates to the DEP API, then retrieves its Activation Record.
5. The device authenticates to the MDM server to retrieve a Configuration Profile containing an MDM Enrollment Payload, Certificate Payload, and SCEP Payload.
6. The device requests and receives its client certificate through SCEP.
7. The device authenticates to the MDM server with the client certificate retrieved during step six. MDM commands can then be sent to the device via APNs.
We focused on stages 4–7 in our talk, and specifically on whether man-in-the-middle network attacks are possible at each stage. At a majority of stages, we found that CA pinning is possible but not mandatory, with an important exception — the MDM command used to download and install an application onto device. That command, called InstallApplication, does not support pinning, and we found a man-in-the-middle attack was possible. This vulnerability exists at step 7 of the process, since it’s an MDM command. InstallApplication is still supported by Apple in macOS (at least for the time being). In response to our responsible disclosure of the vulnerability to them, Apple created a new MDM command named InstallEnterpriseApplication that supports pinning. If you’re interested in reading more about our research, check out the excellent writeup by Lily Newman at Wired and our Black Hat whitepaper and slides.
MDM Me Maybe: Device Enrollment Program Security
As mentioned in the introduction, last month Duo published the results of their recent security research in a paper titled “MDM Me Maybe: Device Enrollment Program Security”. Their research focused on determining whether Apple’s DEP servers could be tricked into returning the DEP “activation profile” for any serial number. The impact they described is an attacker’s device fetching sensitive corporate data (such as the corporate WiFI password), if a device can be auto-enrolled.
The vulnerability we disclosed in our research existed at step 7 of the bootstrapping process, while the vulnerability Duo found exists at step 4. Duo suggested two mitigations to their vulnerability, and each mitigation targets different stages of the bootstrap process.
Sources of confusion
There are two sources of confusion in discussions about the recent research by Fleetsmith and Duo:
- Lack of clarity around which stage of the bootstrap process is being discussed.
- Lack of understanding of the subtle difference between identity, authentication, and authorization.
The first source of confusion can be addressed with some simple tables to map the vulnerabilities and suggested mitigations back to the bootstrap stages:
Fleetsmith research
Duo research
The second source of confusion is a bit more tricky to clear up, but can be resolved by making sure we’re all on the same page as to subtle differences between identity, authentication, and authorization.
Identification, Authentication, Authorization
Many grapple with the concept of authentication in information security. What tends to happen is that they confuse authentication with identification or authorization. — Daniel Miessler
Daniel Miessler’s blog post titled “Security: Identification, Authentication, and Authorization” is the most clear and concise explanation I’ve seen on this topic. If you’re not deeply familiar with the conceptual differences, take a minute and go read the post — it’s short and very well written.
Finished? Great! Let’s move on :)
Device attestation vs. enrollment authentication
With the concepts of identity, authentication, and authorization now clearly defined, let’s revisit the DEP vulnerability found by Duo, along with their suggested mitigations.
Vulnerability
The vulnerability described by Duo demonstrates how an attacker can claim the identity of any other device, and the DEP API has no way of strongly authenticating the claimed identity (represented by the device serial number). This is because the only piece of information used to identify a device is its serial number, and there are are no strong guarantees in place to authenticate that claim of device identity.
Mitigation category #1 — Remediation (Apple)
The first mitigation proposed by Duo addresses the vulnerability directly. It makes it so that any devices containing a T2 chip would be unable to be spoofed, since the server/API would enforce hardware-backed device attestation. To be clear, this mitigation implements strong authentication on the device identity claim. It requires changes on both the client and server side — changes must be made in bridgeOS and macOS such that the device’s identity assertion is backed by the T2. Duo explains it like this:
As part of future improvements to DEP and MDM on macOS, Apple could leverage the UID (Unique ID) that’s generated in the Secure Enclave on the T1 and T2 chips to uniquely identify the device as part of the DEP enrollment process. This could provide cryptographic assurance of the identity of a given device before enrolling it into an organization’s MDM server via DEP. One of the downsides of this approach, however, is that only newer Mac computers have these chips built-in. At the time of this writing, only the following Mac computers ship with either the T1 or T2.
Duo also listed some other improvements Apple could make in their post, but they’re not directly relevant to this blog post. Check out their full post if you’re interested!
Mitigation category #2 — Remediation (Customers)
The second set mitigation proposed by Duo does not address the vulnerability directly, since it does not add strong, hardware-backed authentication to the device’s identity claim. Instead, this second mitigation relies on reducing the likelihood that an attack will be successful by strongly tying a user authentication to a given enrollment attempt, and ensuring that devices aren’t allowed to retrieve MDM configurations until they’ve been explicitly approved by an administrator.
The danger of not sweating the details when implementing mitigation #2
Since mitigation #2 only strongly authenticates device enrollments, but does not address authentication of device identity, an attack is still possible under certain conditions. It relies on exploiting a subtle implementation detail of mitigation #2, which is ensuring that subsequent re-enrollment attempts for a given device serial number must also require explicit administrator approval. If approval isn’t required, then it doesn’t matter whether strong authentication has been added to the enrollment process, because while attack #1 wouldn’t work for new devices, it would work for serial numbers associated with devices that have already been enrolled. It would work like this:
Stage 1: Valid enrollment
- A user within a company authenticates to an MDM enrollment portal with their legitimate company account, and successfully enrolls their device.
- The admin reviews and approves the enrollment attempt.
Stage 2: Invalid re-enrollment
- An attacker repeatedly tries to “re-enroll” a serial number associated with the previously approved device (step 1 above) by finding a device that’s been previously enrolled by brute forcing serial numbers.
- The attacker eventually tries a serial number that has been previously re-enrolled. Since the MDM solution sees that the device with that serial number has already been enrolled, it automatically returns the MDM enrollment profile, resulting in the attacker’s device being successfully enrolled.
Fleetsmith’s device enrollment implementation
Though we didn’t anticipate the exact vulnerability discovered by Duo, we spent a lot of time and effort into thinking through the entire class of attacks related to device enrollment while building out that core product functionality, and thus we found ourselves reading through their suggested mitigation and nodding our heads, as we realized we’d already built it. Here’s an overview on how self-serve device enrollment has worked in Fleetsmith from day 1:
- The user authenticates to the Fleetsmith enrollment portal with their IdP credentials (e.g. G Suite, Office 365)
- When a user downloads the MDM enrollment
.mobileconfigfile, three things happen: a) we reserve a device ID in our database; b) we extract the user ID from the current user session, and associate it with the reserved device ID; c) we generate and include an HMAC containing certain information, the most relevant of which is:
- A nonce
- The current timestamp
- The Fleetsmith customer ID
- The reserved device ID
3. When the device checks into Fleetsmith for the first time, we validate that it sends us a valid HMAC, and then allow the device to “claim” its previously reserved device UUID. The key for the HMAC is securely stored in Hashicorp Vault, which we use as our production secrets management system.
In sharing our implementation, we’re hoping it can act as a reference point for other vendors who may just be starting on improving this area of their product.
Secure implementation checklist for mitigation #2
MDM vendors must make numerous changes to ensure their implementation is secure. Here’s an implementation checklist:
- Limit device enrollments to only authorized users. In Fleetsmith, the only users that can enroll devices are those have been imported to Fleetsmith. G Suite or Office 365 users that haven’t been imported are blocked from logging in and cannot download an MDM enrollment
.mobileconfig. - Include information related to the enrollment within the MDM enrollment payload, and validate it upon device check-in. Again, we stuff information into an HMAC which we sign with a key stored in secrets management, and then validate the HMAC upon device check-in.
- Do not allow automated device enrollment based solely on serial number. Since serial numbers are the thing that is spoofable, it won’t matter if you implement strong enrollment verification if you then still allow devices to auto-enroll purely based on their serial number without explicit admin approval.
- Do not allow automated device re-enrollment based solely on serial number. Re-stating from earlier in this post: relying solely on device serial number should not be used to automate re-enrollment, since doing so allows a complete bypass of the mitigation (you’re back to being vulnerable).
A note on re-enrollment
Some vendors provide an option to disable automatic re-enrollment, but don’t enable it by default. We believe that products should be secure by design, and thus believe the correct approach is to remove this option entirely. If that’s not possible for some reason, we suggest vendors change their default setting for re-enrollment to the secure option, so that device enrollment process is at least “secure by default” out of the box. Our related recommendation is that MDM vendors should then display a warning message if the user tries to change the setting to allow automatic re-enrollment. The message would educate the user on attacks they’re opening themselves up to by enabling automatic re-enrollment, and ask them to confirm (“Are you really sure you want to lower your security by changing this setting?”) before saving the change.
Conclusion
Phew! We covered a lot of ground in this post. To recap, we covered:
- The DEP vulnerability described by Duo, which allows for spoofing a device’s serial number to the DEP API
- The difference between identity, authentication, and authorization
- The mitigations suggested by Duo
- The attacks that are still possible when mitigation #2 is not implemented carefully
- Fleetsmith’s secure device approval implementation, which has existed in our product from the beginning, and which is essentially a careful implementation of mitigation #2
- Our recommendations to other MDM vendors on how to safely implement mitigation #2
The great research performed by James Barclay, Pepijn Bruienne, and Todd Manning at Duo Labs shows the importance of authenticating device enrollments — something that not every MDM vendor does. Without strong authentication around the device enrollment process, attackers can enroll any device they want, and gain access to sensitive company information delivered to devices via MDM, including things such as the corporate WiFi password or VPN credentials. And as we saw the Target breach a few years ago, remote network access (such as VPN) can be a powerful foothold for an attacker.
Last but not least, it’s worth calling out that strongly authenticating device enrollment does not directly address the device spoofing vulnerability that Duo identified — only Apple has the power to address that issue. We’ve got our fingers crossed that they’ll make strong device attestation a reality in a future release of macOS! 🤞🏻
Acknowledgements
Duo thanked several important individuals and we’d like to thank them as well. Duo’s research built on the earlier work of Pepijn Bruienne, Jesse Peterson and Victor Vrantchan, and they were the first to discover the weaknesses in DEP authentication covered in Duo’s paper. We also previously thanked Victor Vrantchan, Pepijn Bruienne, Jesse Peterson, and Michael Lynn in our Black Hat talk for their research, open source work, and contributions to the Mac security community.
References
A Deep Dive into macOS MDM (and how it can be compromised) by Jesse Endahl & Max Bélanager
MDM Me Maybe: Device Enrollment Program Security by James Barclay
Security: Identification, Authentication, and Authorization by Daniel Miessler
