0x22bb
/
hacktricks
mirror of https://github.com/carlospolop/hacktricks.git
1
2
Fork 0
Code Releases Activity
hacktricks/macos/macos-security-and-privileg.../macos-mdm/README.md

11 KiB
Raw Blame History

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)

{% hint style="danger" %} 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. {% endhint %}

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:

{% content-ref url="enrolling-devices-in-other-organisations.md" %} enrolling-devices-in-other-organisations.md {% endcontent-ref %}

References