Enterprises using Apple’s Device Enrollment Program (DEP) for mobile device management (MDM) enrollment, without adding secondary authentication, are placing themselves at risk for information exfiltration and attacks, according to researchers.
MDM is a common enterprise technology offered by multiple vendors, which is used by enterprises to keep a handle on employees’ mobile device usage. This includes enforcing security policies, standardizing updates, controlling expense management and more, all centralized into one platform. It’s meant to tame the kraken of having multiple kinds of handsets and tablets, all with access to corporate resources, spread out across hundreds or even thousands of geographically disperse workers.
DEP meanwhile is an Apple service designed to make MDM enrollment of iOS, macOS and tvOS devices easier. Unlike more traditional deployment methods, which require the end user or administrator to take action to configure a device and manually enroll it with an MDM server, DEP allows administrators to make that process automatic.
Research from Duo Labs however found that DEP only requires a serial number in order to enroll a device into an organization’s MDM server, which means that an attacker could enroll a rogue device into the system. That device in turn would then be treated as a privileged endpoint, allowing the adversary to lift important information about the organization.
“If the serial number is registered with DEP (which is different than being enrolled in MDM), and the MDM server doesn’t require additional user authentication during enrollment – an attacker could to enroll a device of their choosing into an organization’s MDM server by spoofing a legitimate DEP registered serial number,” explained James Barclay, senior R&D engineer at Duo, in an interview.
Once a device is enrolled, in many cases it is treated as a “trusted” device owned by the organization, and could be used to access sensitive information such as device and user certificates, VPN configuration data, enrollment agents, configuration profiles, and various other internal data and organizational secrets.
“The ability to enroll a chosen device to an organization’s MDM server can have a significant consequence, subsequently allowing access to the private resources of an organization, or even full VPN access to internal systems,” the research team said, in a Thursday post.
Importantly, there’s one big barrier for potential attackers – they must initiate the DEP enrollment before the legitimate user does so, as the DEP only accepts the serial number once for devices. That narrows down the time frame of attack significantly, as a bad actor would need to enroll a device before it has been enrolled by the organization – or, they would need to know the serial number of an existing device.
Duo pointed out in its research that device serial numbers are predictable and easily accessible – via social engineering, brute forcing, or even sometimes they are just listed online.
“If the device has already enrolled in the MDM server, an attacker won’t be able to enroll the device into MDM. In this sense, the attacker has to ‘win the race,’ by enrolling their rogue device before the actual user does,” Barclay said.
However, he added that even if a legitimate device has already been enrolled, the adversary can still advance an attack. The problem here occurs when, upon enrollment, DEP authenticates the device to the DEP API: The API then retrieves an Activation Record. That Activation Record contains organizational information.
“An attacker could use the serial number with the DEP API to retrieve the Activation Record (or DEP profile) and leak information about the organization, or be used in social-engineering attacks to, for example, call the help desk and give them the serial number asking for help ‘re-enrolling’ in the MDM server,” Barclay explained.
He added, “As currently implemented, the DEP service makes available information that would be useful to an attacker purely through the submission of a DEP registered serial number, without requiring any user-level authentication. It also facilitates the easier enumeration of unauthenticated MDM servers through the use of previously obtained or generated serial numbers, which depending on their specific configuration and items they configure could lead to an attacker being able to access protected or internal resources.”
The fix for this weakness is to implement additional requirements for authentication on the MDM server itself, so device enrollment does not merely rely on serial numbers alone. Users can also embrace a “zero-trust” approach, decreasing the level of privileges for devices enrolled in DEP.
Barclay told us, “In the most general sense this feels like an inappropriate usage of a serial number for authentication purposes. Serial numbers are only intended to uniquely identify a particular device, they are not intended to be secret or unpredictable, and as such should never be used to verify the identity of a device. Unfortunately, this is not a unique situation and the incorrect use of serial numbers for authentication purposes has occurred in a variety of scenarios before.”
For its part, Apple told Threatpost that it doesn’t consider it a vulnerability, and that its documentation already recommends that companies apply user authentication or limit access upon preliminary configuration.
Barclay, in framing the issue to Threatpost, explained, “the manner in which the DEP service currently works acts as an attack catalyst that is somewhat unique in the way it lowers the barrier of successful attack against other components not configured in a security-first manner.”
Duo also recommended in its research that Apple can help make their DEP APIs more resilient to misuse by “implementing rate limits on requests and limiting the information returned by the API endpoints.”
Tara Seals contributed to this report.
