MacOS MDM

Basics

What is MDM (Mobile Device Management)?

Mobile Device Management (MDM) is a technology commonly used to administer end-user computing devices such as mobile phones, laptops, desktops and tablets. In the case of Apple platforms like iOS, macOS and tvOS, it refers to a specific set of features, APIs and techniques used by administrators to manage these devices. Management of devices via MDM requires a compatible commercial or open-source MDM server that implements support for the MDM Protocol.

  • A way to achieve centralized device management

  • Requires an MDM server which implements support for the MDM protocol

  • MDM server can send MDM commands, such as remote wipe or “install this config”

Basics What is DEP (Device Enrolment Program)?

The Device Enrollment Program (DEP) is a service offered by Apple that simplifies Mobile Device Management (MDM) enrollment by offering zero-touch configuration of iOS, macOS, and tvOS devices. Unlike more traditional deployment methods, which require the end-user or administrator to take action to configure a device, or manually enroll with an MDM server, DEP aims to bootstrap this process, allowing the user to unbox a new Apple device and have it configured for use in the organization almost immediately.

Administrators can leverage DEP to automatically enroll devices in their organization’s MDM server. Once a device is enrolled, in many cases it is treated as a “trusted” device owned by the organization, and could receive any number of certificates, applications, WiFi passwords, VPN configurations and so on.

  • Allows a device to automatically enroll in pre-configured MDM server the first time it’s powered on

  • Most useful when the device is brand new

  • Can also be useful for reprovisioning workflows (wiped with fresh install of the OS)

Unfortunately, if an organization has not taken additional steps to protect their MDM enrollment, a simplified end-user enrollment process through DEP can also mean a simplified process for attackers to enroll a device of their choosing in the organization’s MDM server, assuming the "identity" of a corporate device.

Basics What is SCEP (Simple Certificate Enrolment Protocol)?

  • A relatively old protocol, created before TLS and HTTPS were widespread.

  • Gives clients a standardized way of sending a Certificate Signing Request (CSR) for the purpose of being granted a certificate. The client will ask the server to give him a signed certificate.

What are Configuration Profiles (aka mobileconfigs)?

  • Apple’s official way of setting/enforcing system configuration.

  • File format that can contain multiple payloads.

  • Based on property lists (the XML kind).

  • “can be signed and encrypted to validate their origin, ensure their integrity, and protect their contents.” Basics — Page 70, iOS Security Guide, January 2018.

Protocols

MDM

  • Combination of APNs (Apple servers) + RESTful API (MDM vendor servers)

  • Communication occurs between a device and a server associated with a device management product

  • Commands delivered from the MDM to the device in plist-encoded dictionaries

  • All over HTTPS. MDM servers can be (and are usually) pinned.

  • Apple grants the MDM vendor an APNs certificate for authentication

DEP

  • 3 APIs: 1 for resellers, 1 for MDM vendors, 1 for device identity (undocumented):

    • The so-called DEP "cloud service" API. This is used by MDM servers to associate DEP profiles with specific devices.

    • The DEP API used by Apple Authorized Resellers to enroll devices, check enrollment status, and check transaction status.

    • The undocumented private DEP API. This is used by Apple Devices to request their DEP profile. On macOS, the cloudconfigurationd binary is responsible for communicating over this API.

  • More modern and JSON based (vs. plist)

  • Apple grants an OAuth token to the MDM vendor

DEP "cloud service" API

  • RESTful

  • sync device records from Apple to the MDM server

  • sync “DEP profiles” to Apple from the MDM server (delivered by Apple to the device later on)

  • A DEP “profile” contains:

    • MDM vendor server URL

    • Additional trusted certificates for server URL (optional pinning)

    • Extra settings (e.g. which screens to skip in Setup Assistant)

Steps for enrolment and management

  1. Device record creation (Reseller, Apple): The record for the new device is created

  2. Device record assignment (Customer): The device is assigned to a MDM server

  3. Device record sync (MDM vendor): MDM sync the device records and push the DEP profiles to Apple

  4. DEP check-in (Device): Device gets his DEP profile

  5. Profile retrieval (Device)

  6. Profile installation (Device) a. incl. MDM, SCEP and root CA payloads

  7. MDM command issuance (Device)

The file /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/PrivateFrameworks/ConfigurationProfiles.framework/ConfigurationProfiles.tbd exports functions that can be considered high-level "steps" of the enrolment process.

Step 4: DEP check-in - Getting the Activation Record

This part of the process occurs when a user boots a Mac for the first time (or after a complete wipe)

or when executing sudo profiles show -type enrollment

  • Determine whether device is DEP enabled

  • Activation Record is the internal name for DEP “profile”

  • Begins as soon as the device is connected to Internet

  • Driven by CPFetchActivationRecord

  • Implemented by cloudconfigurationd via XPC. The "Setup Assistant" (when the device is firstly booted) or the profiles command will contact this daemon to retrieve the activation record.

    • LaunchDaemon (always runs as root)

It follows a few steps to get the Activation Record performed by MCTeslaConfigurationFetcher. This process uses an encryption called Absinthe

  1. Retrieve certificate

    1. GET https://iprofiles.apple.com/resource/certificate.cer

  2. Initialize state from certificate (NACInit)

    1. Uses various device-specific data (i.e. Serial Number via IOKit)

  3. Retrieve session key

    1. POST https://iprofiles.apple.com/session

  4. Establish the session (NACKeyEstablishment)

  5. Make the request

    1. POST to https://iprofiles.apple.com/macProfile sending the data { "action": "RequestProfileConfiguration", "sn": "" }

    2. The JSON payload is encrypted using Absinthe (NACSign)

    3. All requests over HTTPs, built-in root certificates are used

The response is a JSON dictionary with some important data like:

  • url: URL of the MDM vendor host for the activation profile

  • anchor-certs: Array of DER certificates used as trusted anchors

Step 5: Profile Retrieval

  • Request sent to url provided in DEP profile.

  • Anchor certificates are used to evaluate trust if provided.

    • Reminder: the anchor_certs property of the DEP profile

  • Request is a simple .plist with device identification

    • Examples: UDID, OS version.

  • CMS-signed, DER-encoded

  • Signed using the device identity certificate (from APNS)

  • Certificate chain includes expired Apple iPhone Device CA

Step 6: Profile Installation

  • Once retrieved, profile is stored on the system

  • This step begins automatically (if in setup assistant)

  • Driven by CPInstallActivationProfile

  • Implemented by mdmclient over XPC

    • LaunchDaemon (as root) or LaunchAgent (as user), depending on context

  • Configuration profiles have multiple payloads to install

  • Framework has a plugin-based architecture for installing profiles

  • Each payload type is associated with a plugin

    • Can be XPC (in framework) or classic Cocoa (in ManagedClient.app)

  • Example:

    • Certificate Payloads use CertificateService.xpc

Typically, activation profile provided by an MDM vendor will include the following payloads:

  • com.apple.mdm: to enroll the device in MDM

  • com.apple.security.scep: to securely provide a client certificate to the device.

  • com.apple.security.pem: to install trusted CA certificates to the device’s System Keychain.

  • Installing the MDM payload equivalent to MDM check-in in the documentation

  • Payload contains key properties:

    • MDM Check-In URL (CheckInURL)

    • MDM Command Polling URL (ServerURL) + APNs topic to trigger it

  • To install MDM payload, request is sent to CheckInURL

  • Implemented in mdmclient

  • MDM payload can depend on other payloads

  • Allows requests to be pinned to specific certificates:

    • Property: CheckInURLPinningCertificateUUIDs

    • Property: ServerURLPinningCertificateUUIDs

    • Delivered via PEM payload

  • Allows device to be attributed with an identity certificate:

    • Property: IdentityCertificateUUID

    • Delivered via SCEP payload

Step 7: Listening for MDM commands

  • After MDM check-in is complete, vendor can issue push notifications using APNs

  • Upon receipt, handled by mdmclient

  • To poll for MDM commands, request is sent to ServerURL

  • Makes use of previously installed MDM payload:

    • ServerURLPinningCertificateUUIDs for pinning request

    • IdentityCertificateUUID for TLS client certificate

Attacks

Enrolling Devices in Other Organisations

As previously commented, in order to try to enrol a device into an organization only a Serial Number belonging to that Organization is needed. Once the device is enrolled, several organizations will install sensitive data on the new device: certificates, applications, WiFi passwords, VPN configurations and so on. Therefore, this could be a dangerous entrypoint for attackers if the enrolment process isn't correctly protected:

pageEnrolling Devices in Other Organisations

References

PreviousMac OS ArchitectureNextEnrolling Devices in Other Organisations

Last updated