Researchers have identified a weakness in Apple’s Device Enrollment Program (DEP) which attackers can potentially abuse to enroll any device into an organization’s mobile device management (MDM) server. That rogue device would make it easier for the attacker to move around within the organization’s network.
An administrator would want to automate the process of issuing new devices to employees and getting them set up with organization-specific settings and applications as much as possible. In such an organization, employees would power on their Apple device—such as iPhones, MacBooks, and iPads—and it would be automatically recognized. The employee would be able to step through the self-service process to enroll the device through the organization’s MDM server and receive configuration settings, passwords, and certificates necessary for the network. DEP, the service provided by Apple to help organizations use MDM for Apple devices, makes that automatic recognition possible.
Knowing that device X is enrolled is useful information.
Duo Labs researchers found that DEP relied on the device’s serial number to authenticate to the server. A potential attacker with a device’s serial number—which can be found in any number of ways because serial numbers aren’t intended to be secret—can query the DEP API to discover information about the enrolled devices. That information can be used by the attacker to plan future attacks.
“An attacker armed with only a valid DEP-registered serial number can use it to query the DEP API to glean organizational information,” said James Barclay, a senior R&D engineer at Duo Labs.
When the DEP service receives a request with the serial number, it returns the device’s activation record, which contains information such as the organization’s address, phone number, and email address. While some of that information may not be considered sensitive, it is valuable for the attacker interested in collecting as much information as possible while planning an attack. It may also help attackers put together a social engineering attack to get other types of information.
“If we send the serial number to DEP and it exists, we get this record back. Knowing that device X is enrolled is useful information,” said Rich Smith, director of Duo Labs.
For many organizations using MDM and DEP, the serial number appears to be the only thing protecting the device enrollment workflow from abuse.
It would also be possible to generate a random 12-character string and test it against the DEP API to check if it is a valid serial number and if it is registered with DEP. The API doesn’t limit the frequency of requests, so the attacker can run through a long list of potential strings and see what information gets returned, Smith said.
DEP + MDM = Risk?
Organizations can manage and configure user devices with DEP, but generally rely on MDM for granular controls like rolling out network passwords and granting VPN access to the network. The idea is that if the device is listed with DEP, it can be enrolled into the organization’s MDM server. Duo Labs identified potential points for abuse in the enrollment workflow.
The MDM protocol supports having the user authenticate to the server before starting the process to enroll the device, but it is optional, and many organizations are using DEP with MDM without separate user authentication. There are many reasons for that decision, ranging from wanting to keep self-checkout easy and seamless, to administrators not realizing that DEP’s registration process is not sufficient authentication.
If the attacker has a serial number of a device registered with DEP and can identify an unprotected MDM server, then the attacker can directly enroll that device—with that serial number, or spoofing the device to make it seem as if it has that serial number—with the organization’s MDM server. The configuration could be “keys to the kingdom,” such as VPN credentials and access to restricted applications, or less sensitive.
The extent of the impact depends on how DEP is being used—on its own or with MDM.
“If that MDM server doesn’t require authentication, then I can essentially take any device, spoof the serial number, and contact the MDM server saying, ‘I am a new device, configure me up,’ and get all the relevant configuration,” Smith said. The combination of DEP and MDM lets the attacker into the network with an authorized trusted device, which opens up a world of possibilities for the attacker.
For many organizations using MDM and DEP, the serial number appears to be the only thing protecting the device enrollment workflow from abuse.
Even with the weaknesses in DEP, "there's no question that it still provides value for organizations with large fleets of Apple devices," Barclay said. The benefits of using DEP to make it easier to use MDM to securely configure and manage Apple devices "outweigh the risks associated with this authentication weakness."
DEP Not Designed for Security
Not every enterprise deploying Apple devices in its corporate IT environment uses DEP, but every single one of those that uses DEP is at risk of attackers abusing the service as part of its campaign to get access to the organization’s infrastructure. The extent of the impact depends on how DEP is being used—on its own or with MDM.
Enterprises using DEP with MDM should make sure user authentication is required during MDM enrollment. In fact, regardless of whether the organization is using DEP or some other equivalent registration service, MDM should always require user authentication. There has to be an explicit association between the user to the device before connecting the device to the network. “I need to say, ‘Yes, it’s me, I am allowed on this network,’ as well as ‘Yes, this is my device,’” said Smith.
There's no question that it [DEP] still provides value for organizations with large fleets of Apple devices.
It would also strengthen overall enterprise defenses to stop making the default assumption that devices being managed by MDM are automatically trusted. In sensitive situations, even if the device is under MDM control, enterprises should still verify the device is a trusted device.
Duo Security reached out to Apple in May with the Labs findings, and laid out several recommendations in its technical paper on how to address the issue. Recommendations include moving away from just using serial numbers as the sole authentication factor, adding strong authentication of devices going through DEP, rate-limiting requests to the APIs, and limiting the amount of information returned. These steps would require revisiting the DEP’s design and evaluating the architecture itself. This isn’t a software bug that can just be patched away.
"Some of the recommended remediation steps will require re-architecting how DEP and MDM enrollment work, and could require hardware changes, while others are more straightforward and can be implemented directly by customers using DEP," Barclay wrote.
Even though the issue is specifically with how the organization has set up MDM to use DEP and not a vulnerability in DEP itself, Apple still has a responsibility to its enterprise customers. DEP acts as an authentication broker for MDM, and if it is not supposed to provide any layer of security, Apple has to say that explicitly in its documentation and guidance. Administrators may be under the impression that being enrolled in DEP is sufficient proof that this is a trusted device because it is not specifically stated that DEP is not designed to make any security assurances.
“There is no red exclamation marks stating DEP does not attempt to provide any security,” Smith said.