macOS Launch/Environment Constraints & Trust Cache
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Startbeschränkungen in macOS wurden eingeführt, um die Sicherheit zu erhöhen, indem reguliert wird, wie, wer und von wo ein Prozess gestartet werden kann. Eingeführt in macOS Ventura, bieten sie einen Rahmen, der jede Systembinärdatei in verschiedene Beschränkungs-kategorien einteilt, die innerhalb des Trust-Caches definiert sind, einer Liste, die Systembinärdateien und deren jeweilige Hashes enthält. Diese Beschränkungen erstrecken sich auf jede ausführbare Binärdatei im System und umfassen eine Reihe von Regeln, die die Anforderungen für das Starten einer bestimmten Binärdatei festlegen. Die Regeln umfassen Selbstbeschränkungen, die eine Binärdatei erfüllen muss, Elternbeschränkungen, die von ihrem übergeordneten Prozess erfüllt werden müssen, und verantwortliche Beschränkungen, die von anderen relevanten Entitäten eingehalten werden müssen.
Der Mechanismus erstreckt sich auf Drittanbieter-Apps durch Umgebungsbeschränkungen, beginnend mit macOS Sonoma, die es Entwicklern ermöglichen, ihre Apps zu schützen, indem sie eine Menge von Schlüsseln und Werten für Umgebungsbeschränkungen angeben.
Sie definieren Startumgebungs- und Bibliotheksbeschränkungen in Beschränkungswörterbüchern, die Sie entweder in launchd-Eigenschaftslisten speichern oder in separaten Eigenschaftslisten, die Sie beim Code-Signing verwenden.
Es gibt 4 Arten von Beschränkungen:
Selbstbeschränkungen: Beschränkungen, die auf die laufende Binärdatei angewendet werden.
Elternprozess: Beschränkungen, die auf den Elternprozess (zum Beispiel launchd, der einen XP-Dienst ausführt) angewendet werden.
Verantwortliche Beschränkungen: Beschränkungen, die auf den Prozess, der den Dienst aufruft, in einer XPC-Kommunikation angewendet werden.
Bibliotheksladebeschränkungen: Verwenden Sie Bibliotheksladebeschränkungen, um selektiv Code zu beschreiben, der geladen werden kann.
Wenn ein Prozess versucht, einen anderen Prozess zu starten — indem er execve(_:_:_:) oder posix_spawn(_:_:_:_:_:_:) aufruft — überprüft das Betriebssystem, ob die ausführbare Datei ihre eigene Selbstbeschränkung erfüllt. Es überprüft auch, ob die ausführbare Datei des Elternprozesses die Elternbeschränkung der ausführbaren Datei erfüllt und ob die ausführbare Datei des verantwortlichen Prozesses die verantwortliche Prozessbeschränkung der ausführbaren Datei erfüllt. Wenn eine dieser Startbeschränkungen nicht erfüllt ist, führt das Betriebssystem das Programm nicht aus.
Wenn beim Laden einer Bibliothek ein Teil der Bibliotheksbeschränkung nicht zutrifft, lädt Ihr Prozess die Bibliothek nicht.
Ein LC besteht aus Fakten und logischen Operationen (und, oder..), die Fakten kombinieren.
Die Fakten, die ein LC verwenden kann, sind dokumentiert. Zum Beispiel:
is-init-proc: Ein boolescher Wert, der angibt, ob die ausführbare Datei der Initialisierungsprozess des Betriebssystems (launchd) sein muss.
is-sip-protected: Ein boolescher Wert, der angibt, ob die ausführbare Datei eine Datei ist, die durch den Systemintegritätsschutz (SIP) geschützt ist.
on-authorized-authapfs-volume: Ein boolescher Wert, der angibt, ob das Betriebssystem die ausführbare Datei von einem autorisierten, authentifizierten APFS-Volume geladen hat.
on-authorized-authapfs-volume: Ein boolescher Wert, der angibt, ob das Betriebssystem die ausführbare Datei von einem autorisierten, authentifizierten APFS-Volume geladen hat.
Cryptexes-Volume
on-system-volume: Ein boolescher Wert, der angibt, ob das Betriebssystem die ausführbare Datei vom aktuell gebooteten Systemvolume geladen hat.
Innerhalb von /System...
...
Wenn eine Apple-Binärdatei signiert wird, weist sie ihr eine LC-Kategorie im Trust-Cache zu.
iOS 16 LC-Kategorien wurden umgekehrt und hier dokumentiert.
Aktuelle LC-Kategorien (macOS 14 - Sonoma) wurden umgekehrt und ihre Beschreibungen sind hier zu finden.
Zum Beispiel ist Kategorie 1:
(on-authorized-authapfs-volume || on-system-volume): Muss sich im System- oder Cryptexes-Volume befinden.
launch-type == 1: Muss ein Systemdienst sein (plist in LaunchDaemons).
validation-category == 1: Eine Betriebssystemausführbare.
is-init-proc: Launchd
Sie haben mehr Informationen darüber hier, aber im Grunde genommen sind sie in AMFI (AppleMobileFileIntegrity) definiert, daher müssen Sie das Kernel Development Kit herunterladen, um die KEXT zu erhalten. Die Symbole, die mit kConstraintCategory beginnen, sind die interessanten. Wenn Sie sie extrahieren, erhalten Sie einen DER (ASN.1) kodierten Stream, den Sie mit dem ASN.1 Decoder oder der python-asn1-Bibliothek und ihrem dump.py-Skript, andrivet/python-asn1 dekodieren müssen, was Ihnen eine verständlichere Zeichenfolge gibt.
Dies sind die Launch Constraints, die in drittanbieter Anwendungen konfiguriert sind. Der Entwickler kann die Fakten und logischen Operanden auswählen, die er in seiner Anwendung verwenden möchte, um den Zugriff auf sich selbst einzuschränken.
Es ist möglich, die Umgebungsbeschränkungen einer Anwendung mit zu enumerieren:
In macOS gibt es einige Vertrauensspeicher:
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/BaseSystemTrustCache.img4
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4
/System/Library/Security/OSLaunchPolicyData
Und in iOS sieht es so aus, als wäre es in /usr/standalone/firmware/FUD/StaticTrustCache.img4.
Auf macOS, das auf Apple Silicon-Geräten läuft, wird AMFI sich weigern, eine Apple-signierte Binärdatei zu laden, wenn sie nicht im Vertrauensspeicher ist.
Die vorherigen Vertrauensspeicherdateien sind im Format IMG4 und IM4P, wobei IM4P der Payload-Bereich eines IMG4-Formats ist.
Sie können pyimg4 verwenden, um die Payload von Datenbanken zu extrahieren:
(Eine weitere Option könnte sein, das Tool img4tool zu verwenden, das auch auf M1 läuft, selbst wenn die Version alt ist, und für x86_64, wenn Sie es an den richtigen Orten installieren).
Jetzt können Sie das Tool trustcache verwenden, um die Informationen in einem lesbaren Format zu erhalten:
Der Vertrauenscache folgt der folgenden Struktur, sodass die LC-Kategorie die 4. Spalte ist.
Dann könnten Sie ein Skript wie dieses verwenden, um Daten zu extrahieren.
Anhand dieser Daten können Sie die Apps mit einem Launch-Constraints-Wert von 0 überprüfen, die nicht eingeschränkt sind (hier überprüfen, was jeder Wert bedeutet).
Launch Constraints hätten mehrere alte Angriffe gemildert, indem sie sicherstellen, dass der Prozess nicht unter unerwarteten Bedingungen ausgeführt wird: Zum Beispiel von unerwarteten Standorten oder von einem unerwarteten übergeordneten Prozess aufgerufen wird (wenn nur launchd es starten sollte).
Darüber hinaus mildern Launch Constraints auch Downgrade-Angriffe.
Sie mildern jedoch keine häufigen XPC-Missbräuche, Electron-Code-Injektionen oder dylib-Injektionen ohne Bibliotheksvalidierung (es sei denn, die Team-IDs, die Bibliotheken laden können, sind bekannt).
Im Sonoma-Release ist ein bemerkenswerter Punkt die Verantwortlichkeitskonfiguration des Daemon-XPC-Dienstes. Der XPC-Dienst ist für sich selbst verantwortlich, im Gegensatz zum verbindenden Client, der verantwortlich ist. Dies ist im Feedback-Bericht FB13206884 dokumentiert. Diese Konfiguration mag fehlerhaft erscheinen, da sie bestimmte Interaktionen mit dem XPC-Dienst zulässt:
Starten des XPC-Dienstes: Wenn dies als Fehler angesehen wird, erlaubt diese Konfiguration nicht, den XPC-Dienst über Angreifercode zu initiieren.
Verbinden mit einem aktiven Dienst: Wenn der XPC-Dienst bereits läuft (möglicherweise von seiner ursprünglichen Anwendung aktiviert), gibt es keine Barrieren, um sich mit ihm zu verbinden.
Während die Implementierung von Einschränkungen für den XPC-Dienst vorteilhaft sein könnte, indem sie das Fenster für potenzielle Angriffe verengt, adressiert sie nicht das Hauptanliegen. Die Sicherheit des XPC-Dienstes sicherzustellen, erfordert grundsätzlich eine effektive Validierung des verbindenden Clients. Dies bleibt die einzige Methode, um die Sicherheit des Dienstes zu stärken. Es ist auch erwähnenswert, dass die genannte Verantwortlichkeitskonfiguration derzeit in Betrieb ist, was möglicherweise nicht mit dem beabsichtigten Design übereinstimmt.
Selbst wenn es erforderlich ist, dass die Anwendung von LaunchService (in den übergeordneten Einschränkungen) geöffnet werden muss. Dies kann durch die Verwendung von open (das Umgebungsvariablen setzen kann) oder durch die Verwendung der Launch Services API (wo Umgebungsvariablen angegeben werden können) erreicht werden.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
