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:

Enrolling Devices in Other Organisations

References

• https://www.youtube.com/watch?v=ku8jZe-MHUU
• https://duo.com/labs/research/mdm-me-maybe