GitBook: [master] 508 pages and 8 assets modified

This commit is contained in:
CPol 2021-08-11 15:44:56 +00:00 committed by gitbook-bot
parent ce53378418
commit f3506c6903
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
10 changed files with 167 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 566 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 566 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 740 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 800 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 740 KiB

View file

@ -56,6 +56,7 @@
## MacOS
* [MacOS Security & Privilege Escalation](macos/macos-security-and-privilege-escalation/README.md)
* [MacOS MDM](macos/macos-security-and-privilege-escalation/macos-mdm.md)
* [MacOS Red Teaming](macos/macos-security-and-privilege-escalation/macos-red-teaming.md)
* [Mac OS Protocols](macos/macos-security-and-privilege-escalation/mac-os-protocols.md)
* [Inspecting, debugging and Fuzzing Mac OS Software](macos/macos-security-and-privilege-escalation/inspecting-and-debugging-mac-os-apps.md)

View file

@ -0,0 +1,166 @@
# 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\)
![](../../.gitbook/assets/image%20%28564%29.png)
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\)
![](../../.gitbook/assets/image%20%28568%29.png)
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](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](https://iprofiles.apple.com/session)
4. Establish the session \(**`NACKeyEstablishment`**\)
5. Make the request
1. POST to [https://iprofiles.apple.com/macProfile](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
![](../../.gitbook/assets/image%20%28563%29.png)
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**
![](../../.gitbook/assets/image%20%28569%29.png)
* 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**
![](../../.gitbook/assets/image%20%28570%29.png)
### 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**
* [https://www.youtube.com/watch?v=ku8jZe-MHUU](https://www.youtube.com/watch?v=ku8jZe-MHUU)