macOS Sandbox
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)
MacOS Sandbox (anfänglich Seatbelt genannt) beschränkt Anwendungen, die innerhalb des Sandboxes ausgeführt werden, auf die erlaubten Aktionen, die im Sandbox-Profil festgelegt sind, mit dem die App ausgeführt wird. Dies hilft sicherzustellen, dass die Anwendung nur auf erwartete Ressourcen zugreift.
Jede App mit der Berechtigung com.apple.security.app-sandbox
wird innerhalb des Sandboxes ausgeführt. Apple-Binärdateien werden normalerweise innerhalb eines Sandboxes ausgeführt, und alle Anwendungen aus dem App Store haben diese Berechtigung. Daher werden mehrere Anwendungen innerhalb des Sandboxes ausgeführt.
Um zu kontrollieren, was ein Prozess tun oder nicht tun kann, hat der Sandbox Hooks in fast jede Operation, die ein Prozess versuchen könnte (einschließlich der meisten Syscalls), unter Verwendung von MACF. Allerdings kann der Sandbox, abhängig von den Berechtigungen der App, permissiver mit dem Prozess sein.
Einige wichtige Komponenten des Sandboxes sind:
Die Kernel-Erweiterung /System/Library/Extensions/Sandbox.kext
Das private Framework /System/Library/PrivateFrameworks/AppSandbox.framework
Ein Daemon, der im Userland läuft /usr/libexec/sandboxd
Die Container ~/Library/Containers
Jede sandboxed Anwendung hat ihren eigenen Container in ~/Library/Containers/{CFBundleIdentifier}
:
Innerhalb jedes Bundle-ID-Ordners finden Sie die plist und das Datenverzeichnis der App mit einer Struktur, die dem Home-Ordner ähnelt:
Beachten Sie, dass selbst wenn die Symlinks vorhanden sind, um aus dem Sandbox zu "entkommen" und auf andere Ordner zuzugreifen, die App dennoch Berechtigungen haben muss, um auf sie zuzugreifen. Diese Berechtigungen befinden sich in der .plist
in den RedirectablePaths
.
Die SandboxProfileData
ist das kompilierte Sandbox-Profil CFData, das in B64 kodiert ist.
Alles, was von einer Sandbox-Anwendung erstellt oder geändert wird, erhält das Quarantäneattribut. Dies verhindert einen Sandbox-Bereich, indem Gatekeeper ausgelöst wird, wenn die Sandbox-App versucht, etwas mit open
auszuführen.
Die Sandbox-Profile sind Konfigurationsdateien, die angeben, was in dieser Sandbox erlaubt/verboten ist. Es verwendet die Sandbox Profile Language (SBPL), die die Scheme Programmiersprache nutzt.
Hier finden Sie ein Beispiel:
Überprüfen Sie diese Forschung um weitere Aktionen zu überprüfen, die erlaubt oder verweigert werden könnten.
Beachten Sie, dass in der kompilierten Version eines Profils die Namen der Operationen durch ihre Einträge in einem Array ersetzt werden, das von der dylib und dem kext bekannt ist, wodurch die kompilierte Version kürzer und schwerer lesbar wird.
Wichtige Systemdienste laufen ebenfalls in ihrem eigenen benutzerdefinierten Sandbox, wie der Dienst mdnsresponder
. Sie können diese benutzerdefinierten Sandbox-Profile einsehen unter:
/usr/share/sandbox
/System/Library/Sandbox/Profiles
Andere Sandbox-Profile können unter https://github.com/s7ephen/OSX-Sandbox--Seatbelt--Profiles überprüft werden.
App Store-Apps verwenden das Profil /System/Library/Sandbox/Profiles/application.sb
. Sie können in diesem Profil überprüfen, wie Berechtigungen wie com.apple.security.network.server
einem Prozess erlauben, das Netzwerk zu nutzen.
SIP ist ein Sandbox-Profil, das in /System/Library/Sandbox/rootless.conf als platform_profile bezeichnet wird.
Um eine Anwendung mit einem spezifischen Sandbox-Profil zu starten, können Sie Folgendes verwenden:
Beachten Sie, dass die von Apple verfasste Software, die auf Windows läuft, keine zusätzlichen Sicherheitsvorkehrungen hat, wie z.B. die Anwendungssandbox.
Beispiele für Umgehungen:
https://desi-jarvis.medium.com/office365-macos-sandbox-escape-fcce4fa4123c (sie können Dateien außerhalb der Sandbox schreiben, deren Name mit ~$
beginnt).
Es ist möglich, alle Überprüfungen zu verfolgen, die die Sandbox jedes Mal durchführt, wenn eine Aktion überprüft wird. Erstellen Sie dazu einfach das folgende Profil:
Und dann einfach etwas mit diesem Profil ausführen:
In /tmp/trace.out
können Sie jede Sandbox-Prüfung sehen, die jedes Mal durchgeführt wurde, wenn sie aufgerufen wurde (also viele Duplikate).
Es ist auch möglich, die Sandbox mit dem -t
Parameter zu verfolgen: sandbox-exec -t /path/trace.out -p "(version 1)" /bin/ls
Die Funktion sandbox_set_trace_path
, die von libsystem_sandbox.dylib
exportiert wird, ermöglicht es, einen Trace-Dateinamen anzugeben, in den Sandbox-Prüfungen geschrieben werden.
Es ist auch möglich, etwas Ähnliches zu tun, indem man sandbox_vtrace_enable()
aufruft und dann die Protokollfehler aus dem Puffer mit sandbox_vtrace_report()
abruft.
libsandbox.dylib
exportiert eine Funktion namens sandbox_inspect_pid, die eine Liste des Sandbox-Zustands eines Prozesses (einschließlich Erweiterungen) liefert. Allerdings können nur Plattform-Binärdateien diese Funktion verwenden.
MacOS speichert System-Sandbox-Profile an zwei Orten: /usr/share/sandbox/ und /System/Library/Sandbox/Profiles.
Und wenn eine Drittanbieteranwendung das com.apple.security.app-sandbox Recht hat, wendet das System das /System/Library/Sandbox/Profiles/application.sb Profil auf diesen Prozess an.
In iOS wird das Standardprofil container genannt und wir haben keine SBPL-Textdarstellung. Im Speicher wird diese Sandbox als Erlauben/Verweigern-Binärbaum für jede Berechtigung aus der Sandbox dargestellt.
Es könnte für Unternehmen möglich sein, ihre Apps mit benutzerdefinierten Sandbox-Profilen auszuführen (anstatt mit dem Standardprofil). Sie müssen das Recht com.apple.security.temporary-exception.sbpl
verwenden, das von Apple genehmigt werden muss.
Es ist möglich, die Definition dieses Rechts in /System/Library/Sandbox/Profiles/application.sb:
zu überprüfen.
Dies wird den String nach diesem Recht als ein Sandbox-Profil eval.
Das sandbox-exec
-Tool verwendet die Funktionen sandbox_compile_*
aus libsandbox.dylib
. Die Hauptfunktionen, die exportiert werden, sind: sandbox_compile_file
(erwartet einen Dateipfad, Parameter -f
), sandbox_compile_string
(erwartet einen String, Parameter -p
), sandbox_compile_name
(erwartet einen Namen eines Containers, Parameter -n
), sandbox_compile_entitlements
(erwartet Entitlements plist).
Diese umgekehrte und Open-Source-Version des Tools sandbox-exec ermöglicht es, dass sandbox-exec
in eine Datei das kompilierte Sandbox-Profil schreibt.
Darüber hinaus kann es, um einen Prozess innerhalb eines Containers einzuschränken, sandbox_spawnattrs_set[container/profilename]
aufrufen und einen Container oder ein bereits vorhandenes Profil übergeben.
Auf macOS, im Gegensatz zu iOS, wo Prozesse von Anfang an durch den Kernel sandboxed sind, müssen Prozesse selbst in die Sandbox optieren. Das bedeutet, dass ein Prozess auf macOS nicht durch die Sandbox eingeschränkt ist, bis er aktiv entscheidet, sie zu betreten, obwohl Apps aus dem App Store immer sandboxed sind.
Prozesse werden automatisch aus dem Userland sandboxed, wenn sie starten, wenn sie das Recht haben: com.apple.security.app-sandbox
. Für eine detaillierte Erklärung dieses Prozesses siehe:
Erweiterungen ermöglichen es, einem Objekt weitere Berechtigungen zu geben und rufen eine der folgenden Funktionen auf:
sandbox_issue_extension
sandbox_extension_issue_file[_with_new_type]
sandbox_extension_issue_mach
sandbox_extension_issue_iokit_user_client_class
sandbox_extension_issue_iokit_registry_rentry_class
sandbox_extension_issue_generic
sandbox_extension_issue_posix_ipc
Die Erweiterungen werden im zweiten MACF-Label-Slot gespeichert, der von den Prozessanmeldeinformationen zugänglich ist. Das folgende sbtool
kann auf diese Informationen zugreifen.
Beachten Sie, dass Erweiterungen normalerweise von erlaubten Prozessen gewährt werden, zum Beispiel wird tccd
das Erweiterungstoken von com.apple.tcc.kTCCServicePhotos
gewähren, wenn ein Prozess versucht hat, auf die Fotos zuzugreifen und in einer XPC-Nachricht erlaubt wurde. Dann muss der Prozess das Erweiterungstoken konsumieren, damit es hinzugefügt wird.
Beachten Sie, dass die Erweiterungstoken lange Hexadezimalzahlen sind, die die gewährten Berechtigungen kodieren. Sie haben jedoch die erlaubte PID nicht fest codiert, was bedeutet, dass jeder Prozess mit Zugriff auf das Token von mehreren Prozessen konsumiert werden kann.
Beachten Sie, dass Erweiterungen auch sehr mit Rechten verbunden sind, sodass das Vorhandensein bestimmter Rechte automatisch bestimmte Erweiterungen gewähren kann.
Laut diesem können die sandbox_check
-Funktionen (es ist ein __mac_syscall
) überprüfen, ob eine Operation erlaubt ist oder nicht durch die Sandbox in einer bestimmten PID, Audit-Token oder eindeutige ID.
Das Tool sbtool (finden Sie es hier kompiliert) kann überprüfen, ob eine PID bestimmte Aktionen ausführen kann:
Es ist auch möglich, den Sandbox zu suspendieren und wieder zu aktivieren, indem die Funktionen sandbox_suspend
und sandbox_unsuspend
aus libsystem_sandbox.dylib
verwendet werden.
Beachten Sie, dass zur Aufruf der Suspend-Funktion einige Berechtigungen überprüft werden, um den Aufrufer zu autorisieren, sie aufzurufen, wie:
com.apple.private.security.sandbox-manager
com.apple.security.print
com.apple.security.temporary-exception.audio-unit-host
Dieser Systemaufruf (#381) erwartet ein String-Argument als ersten Parameter, das das Modul angibt, das ausgeführt werden soll, und dann einen Code im zweiten Argument, der die auszuführende Funktion angibt. Der dritte Parameter hängt dann von der ausgeführten Funktion ab.
Der Funktionsaufruf ___sandbox_ms
umschließt mac_syscall
, indem im ersten Argument "Sandbox"
angegeben wird, genau wie ___sandbox_msp
ein Wrapper von mac_set_proc
(#387) ist. Einige der unterstützten Codes von ___sandbox_ms
finden sich in dieser Tabelle:
set_profile (#0): Wendet ein kompiliertes oder benanntes Profil auf einen Prozess an.
platform_policy (#1): Erzwingt plattformspezifische Richtlinienprüfungen (variiert zwischen macOS und iOS).
check_sandbox (#2): Führt eine manuelle Überprüfung einer bestimmten Sandbox-Operation durch.
note (#3): Fügt eine Annotation zu einer Sandbox hinzu.
container (#4): Fügt einer Sandbox eine Annotation hinzu, typischerweise zur Fehlersuche oder Identifikation.
extension_issue (#5): Generiert eine neue Erweiterung für einen Prozess.
extension_consume (#6): Verbraucht eine gegebene Erweiterung.
extension_release (#7): Gibt den Speicher frei, der an eine verbrauchte Erweiterung gebunden ist.
extension_update_file (#8): Ändert Parameter einer bestehenden Dateierweiterung innerhalb der Sandbox.
extension_twiddle (#9): Passt eine bestehende Dateierweiterung an oder ändert sie (z.B. TextEdit, rtf, rtfd).
suspend (#10): Unterbricht vorübergehend alle Sandbox-Prüfungen (erfordert entsprechende Berechtigungen).
unsuspend (#11): Setzt alle zuvor suspendierten Sandbox-Prüfungen fort.
passthrough_access (#12): Erlaubt direkten Durchgriff auf eine Ressource, umgeht Sandbox-Prüfungen.
set_container_path (#13): (nur iOS) Setzt einen Containerpfad für eine App-Gruppe oder eine Signatur-ID.
container_map (#14): (nur iOS) Ruft einen Containerpfad von containermanagerd
ab.
sandbox_user_state_item_buffer_send (#15): (iOS 10+) Setzt Metadaten im Benutzermodus in der Sandbox.
inspect (#16): Bietet Debug-Informationen über einen sandboxed Prozess.
dump (#18): (macOS 11) Dumpt das aktuelle Profil einer Sandbox zur Analyse.
vtrace (#19): Verfolgt Sandbox-Operationen zur Überwachung oder Fehlersuche.
builtin_profile_deactivate (#20): (macOS < 11) Deaktiviert benannte Profile (z.B. pe_i_can_has_debugger
).
check_bulk (#21): Führt mehrere sandbox_check
-Operationen in einem einzigen Aufruf durch.
reference_retain_by_audit_token (#28): Erstellt eine Referenz für ein Audit-Token zur Verwendung in Sandbox-Prüfungen.
reference_release (#29): Gibt eine zuvor gehaltene Audit-Token-Referenz frei.
rootless_allows_task_for_pid (#30): Überprüft, ob task_for_pid
erlaubt ist (ähnlich wie csr
-Prüfungen).
rootless_whitelist_push (#31): (macOS) Wendet eine Manifestdatei für den Systemintegritätsschutz (SIP) an.
rootless_whitelist_check (preflight) (#32): Überprüft die SIP-Manifestdatei vor der Ausführung.
rootless_protected_volume (#33): (macOS) Wendet SIP-Schutzmaßnahmen auf eine Festplatte oder Partition an.
rootless_mkdir_protected (#34): Wendet SIP/DataVault-Schutz auf einen Verzeichnis-Erstellungsprozess an.
Beachten Sie, dass die Kernel-Erweiterung in iOS alle Profile hardcodiert im __TEXT.__const
-Segment enthält, um zu verhindern, dass sie geändert werden. Folgendes sind einige interessante Funktionen aus der Kernel-Erweiterung:
hook_policy_init
: Es hookt mpo_policy_init
und wird nach mac_policy_register
aufgerufen. Es führt die meisten Initialisierungen der Sandbox durch. Es initialisiert auch SIP.
hook_policy_initbsd
: Es richtet die sysctl-Schnittstelle ein und registriert security.mac.sandbox.sentinel
, security.mac.sandbox.audio_active
und security.mac.sandbox.debug_mode
(wenn mit PE_i_can_has_debugger
gebootet).
hook_policy_syscall
: Es wird von mac_syscall
mit "Sandbox" als erstem Argument und einem Code, der die Operation im zweiten angibt, aufgerufen. Ein Switch wird verwendet, um den auszuführenden Code entsprechend dem angeforderten Code zu finden.
Sandbox.kext
verwendet mehr als einhundert Hooks über MACF. Die meisten Hooks überprüfen nur einige triviale Fälle, die es ermöglichen, die Aktion auszuführen; andernfalls rufen sie cred_sb_evalutate
mit den Anmeldeinformationen von MACF und einer Zahl, die der Operation entspricht, die ausgeführt werden soll, sowie einem Puffer für die Ausgabe auf.
Ein gutes Beispiel dafür ist die Funktion _mpo_file_check_mmap
, die mmap
hookt und die überprüft, ob der neue Speicher beschreibbar sein wird (und wenn nicht, die Ausführung erlaubt), dann überprüft, ob er für den dyld Shared Cache verwendet wird, und wenn ja, die Ausführung erlaubt, und schließlich wird sb_evaluate_internal
(oder einer seiner Wrapper) aufgerufen, um weitere Erlaubnisprüfungen durchzuführen.
Darüber hinaus gibt es von den Hunderten von Hooks, die die Sandbox verwendet, drei, die besonders interessant sind:
mpo_proc_check_for
: Es wendet das Profil an, wenn nötig, und wenn es zuvor nicht angewendet wurde.
mpo_vnode_check_exec
: Wird aufgerufen, wenn ein Prozess die zugehörige Binärdatei lädt, dann wird eine Profilüberprüfung durchgeführt und auch eine Überprüfung, die SUID/SGID-Ausführungen verbietet.
mpo_cred_label_update_execve
: Dies wird aufgerufen, wenn das Label zugewiesen wird. Dies ist der längste, da es aufgerufen wird, wenn die Binärdatei vollständig geladen ist, aber noch nicht ausgeführt wurde. Es führt Aktionen wie das Erstellen des Sandbox-Objekts, das Anhängen der Sandbox-Struktur an die kauth-Anmeldeinformationen und das Entfernen des Zugriffs auf Mach-Ports durch...
Beachten Sie, dass _cred_sb_evalutate
ein Wrapper über sb_evaluate_internal
ist und diese Funktion die übergebenen Anmeldeinformationen erhält und dann die Bewertung unter Verwendung der eval
-Funktion durchführt, die normalerweise das Plattformprofil bewertet, das standardmäßig auf alle Prozesse angewendet wird, und dann das spezifische Prozessprofil. Beachten Sie, dass das Plattformprofil eines der Hauptkomponenten von SIP in macOS ist.
Die Sandbox hat auch einen Benutzerdämon, der den XPC Mach-Dienst com.apple.sandboxd
bereitstellt und den speziellen Port 14 (HOST_SEATBELT_PORT
) bindet, den die Kernel-Erweiterung zur Kommunikation mit ihm verwendet. Es stellt einige Funktionen über MIG bereit.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)