hacktricks/macos/macos-security-and-privilege-escalation/macos-mdm.md

7.7 KiB
Raw Blame History

MacOS MDM

Basics

What is MDM Mobile Device Management?

  • 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?

  • Allows a device to automatically enroll in pre-configured MDM server the first time its powered on
  • Most useful when the device is brand new
  • Can also be useful for reprovisioning workflows **wiped** with fresh install of the OS

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?

  • Apples 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 server**s + 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
  • 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 devices 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

References