macOS Launch/Environment Constraints & Trust Cache
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)
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.
Du definierst Startumgebungs- und Bibliotheksbeschränkungen in Beschränkungswörterbüchern, die du entweder in launchd-Eigenschaftslisten speicherst oder in separaten Eigenschaftslisten, die du beim Code-Signing verwendest.
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: Verwende 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 wird auch überprüft, 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 keine dieser Startbeschränkungen 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 dein 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, wird sie einer LC-Kategorie im Trust-Cache zugewiesen.
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, decodieren müssen, was Ihnen eine verständlichere Zeichenkette 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 von 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 die Verwendung des Tools img4tool sein, 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 Trust-Cache 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 Wert für Startbeschränkungen von 0 überprüfen, was die sind, die nicht eingeschränkt sind (hier überprüfen, was jeder Wert bedeutet).
Startbeschränkungen 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 Startbeschränkungen 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 durch 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 Beschrä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 Beschrä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)
