macOS MDM
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Um mehr über macOS MDMs zu erfahren, siehe:
Mobile Device Management (MDM) wird verwendet, um verschiedene Endbenutzergeräte wie Smartphones, Laptops und Tablets zu überwachen. Insbesondere für Apples Plattformen (iOS, macOS, tvOS) umfasst es eine Reihe spezialisierter Funktionen, APIs und Praktiken. Der Betrieb von MDM hängt von einem kompatiblen MDM-Server ab, der entweder kommerziell erhältlich oder Open Source ist und das MDM-Protokoll unterstützen muss. Wichtige Punkte sind:
Zentralisierte Kontrolle über Geräte.
Abhängigkeit von einem MDM-Server, der dem MDM-Protokoll entspricht.
Fähigkeit des MDM-Servers, verschiedene Befehle an Geräte zu senden, z. B. remote Datenlöschung oder Konfigurationsinstallation.
Das Device Enrollment Program (DEP), das von Apple angeboten wird, vereinfacht die Integration von Mobile Device Management (MDM), indem es eine Zero-Touch-Konfiguration für iOS-, macOS- und tvOS-Geräte ermöglicht. DEP automatisiert den Registrierungsprozess, sodass Geräte sofort einsatzbereit sind, mit minimalem Benutzer- oder Verwaltungsaufwand. Wesentliche Aspekte sind:
Ermöglicht es Geräten, sich autonom bei einem vordefinierten MDM-Server bei der ersten Aktivierung zu registrieren.
Primär vorteilhaft für brandneue Geräte, aber auch anwendbar für Geräte, die neu konfiguriert werden.
Erleichtert eine unkomplizierte Einrichtung, sodass Geräte schnell für die organisatorische Nutzung bereit sind.
Es ist wichtig zu beachten, dass die durch DEP gebotene einfache Registrierung, obwohl vorteilhaft, auch Sicherheitsrisiken darstellen kann. Wenn Schutzmaßnahmen für die MDM-Registrierung nicht ausreichend durchgesetzt werden, könnten Angreifer diesen vereinfachten Prozess ausnutzen, um ihr Gerät auf dem MDM-Server der Organisation zu registrieren und sich als Unternehmensgerät auszugeben.
Sicherheitswarnung: Die vereinfachte DEP-Registrierung könnte potenziell die unbefugte Registrierung von Geräten auf dem MDM-Server der Organisation ermöglichen, wenn keine angemessenen Schutzmaßnahmen vorhanden sind.
Ein relativ altes Protokoll, das vor der weit verbreiteten Nutzung von TLS und HTTPS erstellt wurde.
Bietet Clients eine standardisierte Möglichkeit, eine Zertifikatsanforderung (CSR) zu senden, um ein Zertifikat zu erhalten. Der Client wird den Server bitten, ihm ein signiertes Zertifikat zu geben.
Apples offizielle Methode zur Festlegung/Durchsetzung von Systemkonfigurationen.
Dateiformat, das mehrere Payloads enthalten kann.
Basierend auf Property-Listen (der XML-Art).
„kann signiert und verschlüsselt werden, um ihre Herkunft zu validieren, ihre Integrität sicherzustellen und ihren Inhalt zu schützen.“ Grundlagen — Seite 70, iOS Security Guide, Januar 2018.
Kombination aus APNs (Apple-Servern) + RESTful API (MDM Anbieter-Servern)
Kommunikation erfolgt zwischen einem Gerät und einem Server, der mit einem Geräteverwaltungsprodukt verbunden ist
Befehle werden vom MDM an das Gerät in plist-kodierten Dictionaries übermittelt
Überall über HTTPS. MDM-Server können (und sind normalerweise) gepinnt.
Apple gewährt dem MDM-Anbieter ein APNs-Zertifikat zur Authentifizierung
3 APIs: 1 für Wiederverkäufer, 1 für MDM-Anbieter, 1 für Geräteidentität (nicht dokumentiert):
Die sogenannte DEP "Cloud-Service"-API. Diese wird von MDM-Servern verwendet, um DEP-Profile mit bestimmten Geräten zu verknüpfen.
Die DEP-API, die von autorisierten Apple-Wiederverkäufern verwendet wird, um Geräte zu registrieren, den Registrierungsstatus zu überprüfen und den Transaktionsstatus zu überprüfen.
Die nicht dokumentierte private DEP-API. Diese wird von Apple-Geräten verwendet, um ihr DEP-Profil anzufordern. Unter macOS ist das cloudconfigurationd-Binary für die Kommunikation über diese API verantwortlich.
Moderner und JSON-basiert (im Vergleich zu plist)
Apple gewährt dem MDM-Anbieter ein OAuth-Token
DEP "Cloud-Service"-API
RESTful
synchronisiert Geräteaufzeichnungen von Apple zum MDM-Server
synchronisiert „DEP-Profile“ von MDM-Server zu Apple (später an das Gerät geliefert)
Ein DEP „Profil“ enthält:
MDM-Anbieter-Server-URL
Zusätzliche vertrauenswürdige Zertifikate für die Server-URL (optionales Pinning)
Zusätzliche Einstellungen (z. B. welche Bildschirme im Setup-Assistenten übersprungen werden sollen)
Apple-Geräte, die nach 2010 hergestellt wurden, haben in der Regel 12-stellige alphanumerische Seriennummern, wobei die ersten drei Ziffern den Herstellungsort darstellen, die folgenden zwei das Jahr und die Woche der Herstellung angeben, die nächsten drei Ziffern eine eindeutige Kennung bereitstellen und die letzten vier Ziffern die Modellnummer darstellen.
Erstellung des Geräteaufzeichnisses (Wiederverkäufer, Apple): Der Datensatz für das neue Gerät wird erstellt
Zuweisung des Geräteaufzeichnisses (Kunde): Das Gerät wird einem MDM-Server zugewiesen
Synchronisierung des Geräteaufzeichnisses (MDM-Anbieter): MDM synchronisiert die Geräteaufzeichnungen und schiebt die DEP-Profile zu Apple
DEP-Check-in (Gerät): Gerät erhält sein DEP-Profil
Abruf des Profils (Gerät)
Installation des Profils (Gerät) a. inkl. MDM-, SCEP- und Root-CA-Payloads
Ausgabe des MDM-Befehls (Gerät)
Die Datei /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/PrivateFrameworks/ConfigurationProfiles.framework/ConfigurationProfiles.tbd exportiert Funktionen, die als hochgradige "Schritte" des Registrierungsprozesses betrachtet werden können.
Dieser Teil des Prozesses tritt auf, wenn ein Benutzer einen Mac zum ersten Mal bootet (oder nach einer vollständigen Löschung)
oder beim Ausführen von sudo profiles show -type enrollment
Bestimmen ob das Gerät DEP-fähig ist
Aktivierungsdatensatz ist der interne Name für DEP „Profil“
Beginnt, sobald das Gerät mit dem Internet verbunden ist
Angetrieben von CPFetchActivationRecord
Implementiert durch cloudconfigurationd über XPC. Der "Setup-Assistent" (wenn das Gerät zum ersten Mal gebootet wird) oder der profiles-Befehl wird diesen Daemon kontaktieren, um den Aktivierungsdatensatz abzurufen.
LaunchDaemon (läuft immer als root)
Es folgen einige Schritte, um den Aktivierungsdatensatz durch MCTeslaConfigurationFetcher abzurufen. Dieser Prozess verwendet eine Verschlüsselung namens Absinthe
Abrufen des Zertifikats
Initialisiere den Zustand aus dem Zertifikat (NACInit)
Verwendet verschiedene gerätespezifische Daten (d. h. Seriennummer über IOKit)
Abrufen des Sitzungsschlüssels
Sitzung einrichten (NACKeyEstablishment)
Die Anfrage stellen
POST an https://iprofiles.apple.com/macProfile und die Daten { "action": "RequestProfileConfiguration", "sn": "" } senden
Die JSON-Payload ist mit Absinthe (NACSign) verschlüsselt
Alle Anfragen über HTTPs, integrierte Root-Zertifikate werden verwendet
Die Antwort ist ein JSON-Dictionary mit einigen wichtigen Daten wie:
url: URL des MDM-Anbieter-Hosts für das Aktivierungsprofil
anchor-certs: Array von DER-Zertifikaten, die als vertrauenswürdige Anker verwendet werden
Anfrage wird an URL gesendet, die im DEP-Profil angegeben ist.
Ankerzertifikate werden verwendet, um Vertrauen zu bewerten, wenn sie bereitgestellt werden.
Erinnerung: die anchor_certs-Eigenschaft des DEP-Profils
Anfrage ist ein einfaches .plist mit Geräteidentifikation
Beispiele: UDID, OS-Version.
CMS-signiert, DER-kodiert
Signiert mit dem Geräteidentitätszertifikat (von APNS)
Zertifikatskette umfasst abgelaufene Apple iPhone Device CA
Nach dem Abruf wird das Profil im System gespeichert
Dieser Schritt beginnt automatisch (wenn im Setup-Assistenten)
Angetrieben von CPInstallActivationProfile
Implementiert von mdmclient über XPC
LaunchDaemon (als root) oder LaunchAgent (als Benutzer), je nach Kontext
Konfigurationsprofile haben mehrere Payloads zur Installation
Das Framework hat eine pluginbasierte Architektur zur Installation von Profilen
Jeder Payload-Typ ist mit einem Plugin verbunden
Kann XPC (im Framework) oder klassisches Cocoa (in ManagedClient.app) sein
Beispiel:
Zertifikat-Payloads verwenden CertificateService.xpc
Typischerweise wird das Aktivierungsprofil, das von einem MDM-Anbieter bereitgestellt wird, die folgenden Payloads enthalten:
com.apple.mdm: um das Gerät in MDM zu registrieren
com.apple.security.scep: um dem Gerät ein Client-Zertifikat sicher bereitzustellen.
com.apple.security.pem: um vertrauenswürdige CA-Zertifikate im System-Schlüsselbund des Geräts zu installieren.
Die Installation der MDM-Payload entspricht dem MDM-Check-in in der Dokumentation
Payload enthält wichtige Eigenschaften:
MDM-Check-In-URL (CheckInURL)
MDM-Befehlsabfrage-URL (ServerURL) + APNs-Thema, um es auszulösen
Um die MDM-Payload zu installieren, wird eine Anfrage an CheckInURL gesendet
Implementiert in mdmclient
MDM-Payload kann von anderen Payloads abhängen
Ermöglicht Anfragen, die an bestimmte Zertifikate gebunden sind:
Eigenschaft: CheckInURLPinningCertificateUUIDs
Eigenschaft: ServerURLPinningCertificateUUIDs
Wird über PEM-Payload bereitgestellt
Ermöglicht es dem Gerät, mit einem Identitätszertifikat attribuiert zu werden:
Eigenschaft: IdentityCertificateUUID
Wird über SCEP-Payload bereitgestellt
Nach Abschluss des MDM-Check-ins kann der Anbieter Push-Benachrichtigungen über APNs ausgeben
Bei Empfang wird dies von mdmclient verarbeitet
Um nach MDM-Befehlen zu fragen, wird eine Anfrage an ServerURL gesendet
Nutzt die zuvor installierte MDM-Payload:
ServerURLPinningCertificateUUIDs für die Pinning-Anfrage
IdentityCertificateUUID für das TLS-Client-Zertifikat
Wie bereits erwähnt, um ein Gerät in eine Organisation zu registrieren, wird nur eine Seriennummer benötigt, die zu dieser Organisation gehört. Sobald das Gerät registriert ist, werden mehrere Organisationen sensible Daten auf dem neuen Gerät installieren: Zertifikate, Anwendungen, WLAN-Passwörter, VPN-Konfigurationen und so weiter. Daher könnte dies ein gefährlicher Einstiegspunkt für Angreifer sein, wenn der Registrierungsprozess nicht korrekt geschützt ist:
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
