macOS TCC Bypasses
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)
Dies ist kein Bypass, es ist nur, wie TCC funktioniert: Es schützt nicht vor dem Schreiben. Wenn das Terminal keinen Zugriff hat, um den Desktop eines Benutzers zu lesen, kann es trotzdem darauf schreiben:
Die erweiterte Attribut com.apple.macl wird der neuen Datei hinzugefügt, um der erstellenden App den Zugriff zum Lesen zu gewähren.
Es ist möglich, ein Fenster über die TCC-Aufforderung zu legen, um den Benutzer dazu zu bringen, es zu akzeptieren, ohne es zu bemerken. Sie finden einen PoC in TCC-ClickJacking.
Angreifer können Apps mit beliebigen Namen (z.B. Finder, Google Chrome...) in der Info.plist erstellen und den Zugriff auf einen TCC-geschützten Ort anfordern. Der Benutzer wird denken, dass die legitime Anwendung diejenige ist, die diesen Zugriff anfordert.
Darüber hinaus ist es möglich, die legitime App vom Dock zu entfernen und die gefälschte darauf zu setzen, sodass, wenn der Benutzer auf die gefälschte klickt (die dasselbe Symbol verwenden kann), sie die legitime aufrufen, um TCC-Berechtigungen zu verlangen und Malware auszuführen, wodurch der Benutzer glaubt, die legitime App habe den Zugriff angefordert.
Weitere Informationen und PoC in:
macOS Privilege EscalationStandardmäßig hatte der Zugriff über SSH "Vollzugriff auf die Festplatte". Um dies zu deaktivieren, müssen Sie es aufgelistet, aber deaktiviert haben (das Entfernen aus der Liste entfernt diese Berechtigungen nicht):
Hier finden Sie Beispiele dafür, wie einige Malware in der Lage war, diesen Schutz zu umgehen:
Beachten Sie, dass Sie jetzt, um SSH aktivieren zu können, Vollzugriff auf die Festplatte benötigen.
Das Attribut com.apple.macl wird Dateien zugewiesen, um einer bestimmten Anwendung Berechtigungen zum Lesen zu gewähren. Dieses Attribut wird gesetzt, wenn eine Datei über eine App gezogen und abgelegt wird oder wenn ein Benutzer eine Datei doppelklickt, um sie mit der Standardanwendung zu öffnen.
Daher könnte ein Benutzer eine bösartige App registrieren, um alle Erweiterungen zu verwalten und Launch Services aufzurufen, um jede Datei zu öffnen (so erhält die bösartige Datei Zugriff, um sie zu lesen).
Mit der Berechtigung com.apple.private.icloud-account-access ist es möglich, mit dem com.apple.iCloudHelper XPC-Dienst zu kommunizieren, der iCloud-Token bereitstellt.
iMovie und Garageband hatten diese Berechtigung und andere, die dies ermöglichten.
Für weitere Informationen über den Exploit, um iCloud-Token aus dieser Berechtigung zu erhalten, überprüfen Sie den Vortrag: #OBTS v5.0: "Was auf Ihrem Mac passiert, bleibt in Apples iCloud?!" - Wojciech Regula
Eine App mit der Berechtigung kTCCServiceAppleEvents kann andere Apps steuern. Das bedeutet, dass sie in der Lage sein könnte, die Berechtigungen, die den anderen Apps gewährt wurden, auszunutzen.
Für weitere Informationen über Apple Scripts siehe:
macOS Apple ScriptsZum Beispiel, wenn eine App Automatisierungsberechtigung über iTerm hat, hat in diesem Beispiel Terminal Zugriff auf iTerm:
Terminal, das keinen FDA hat, kann iTerm aufrufen, das es hat, und es verwenden, um Aktionen auszuführen:
Oder wenn eine App über Finder Zugriff hat, könnte es ein Skript wie dieses sein:
Der Benutzerland tccd-Daemon verwendet die HOME Umgebungsvariable, um auf die TCC-Benutzerdatenbank zuzugreifen: $HOME/Library/Application Support/com.apple.TCC/TCC.db
Laut diesem Stack Exchange-Beitrag und da der TCC-Daemon über launchd im aktuellen Benutzerbereich ausgeführt wird, ist es möglich, alle Umgebungsvariablen zu steuern, die ihm übergeben werden.
Somit könnte ein Angreifer die $HOME-Umgebungsvariable in launchctl so einstellen, dass sie auf ein kontrolliertes Verzeichnis verweist, den TCC-Daemon neustarten und dann die TCC-Datenbank direkt ändern, um sich alle verfügbaren TCC-Berechtigungen zu geben, ohne jemals den Endbenutzer aufzufordern.
PoC:
Notizen hatten Zugriff auf TCC-geschützte Standorte, aber wenn eine Notiz erstellt wird, wird diese in einem nicht geschützten Standort erstellt. Sie könnten also Notizen bitten, eine geschützte Datei in eine Notiz zu kopieren (also in einen nicht geschützten Standort) und dann auf die Datei zugreifen:
Die Binärdatei /usr/libexec/lsd mit der Bibliothek libsecurity_translocate hatte die Berechtigung com.apple.private.nullfs_allow, die es ermöglichte, ein nullfs-Mount zu erstellen, und hatte die Berechtigung com.apple.private.tcc.allow mit kTCCServiceSystemPolicyAllFiles, um auf jede Datei zuzugreifen.
Es war möglich, das Quarantäneattribut zu "Library" hinzuzufügen, den com.apple.security.translocation XPC-Dienst aufzurufen und dann würde es "Library" auf $TMPDIR/AppTranslocation/d/d/Library abbilden, wo alle Dokumente in "Library" zugänglich sein konnten.
Music hat eine interessante Funktion: Wenn es läuft, wird es die Dateien, die in ~/Music/Music/Media.localized/Automatically Add to Music.localized abgelegt werden, in die "Medienbibliothek" des Benutzers importieren. Darüber hinaus ruft es etwas wie rename(a, b); auf, wobei a und b sind:
a = "~/Music/Music/Media.localized/Automatically Add to Music.localized/myfile.mp3"
b = "~/Music/Music/Media.localized/Automatically Add to Music.localized/Not Added.localized/2023-09-25 11.06.28/myfile.mp3"
Dieses rename(a, b); Verhalten ist anfällig für eine Race Condition, da es möglich ist, eine gefälschte TCC.db-Datei in den Ordner Automatically Add to Music.localized zu legen und dann, wenn der neue Ordner (b) erstellt wird, die Datei zu kopieren, sie zu löschen und auf ~/Library/Application Support/com.apple.TCC zu verweisen.
Wenn SQLITE_SQLLOG_DIR="path/folder" bedeutet das im Grunde, dass jede geöffnete DB in diesen Pfad kopiert wird. In diesem CVE wurde diese Kontrolle missbraucht, um in eine SQLite-Datenbank zu schreiben, die von einem Prozess mit FDA die TCC-Datenbank geöffnet wird, und dann SQLITE_SQLLOG_DIR mit einem Symlink im Dateinamen zu missbrauchen, sodass, wenn diese Datenbank geöffnet wird, die Benutzer-TCC.db überschrieben wird mit der geöffneten.
Mehr Infos im Bericht und im Vortrag.
Wenn die Umgebungsvariable SQLITE_AUTO_TRACE gesetzt ist, beginnt die Bibliothek libsqlite3.dylib mit dem Protokollieren aller SQL-Abfragen. Viele Anwendungen verwendeten diese Bibliothek, sodass es möglich war, alle ihre SQLite-Abfragen zu protokollieren.
Mehrere Apple-Anwendungen verwendeten diese Bibliothek, um auf TCC-geschützte Informationen zuzugreifen.
Diese Umgebungsvariable wird vom Metal-Framework verwendet, das eine Abhängigkeit für verschiedene Programme ist, insbesondere Music, das FDA hat.
Setzen Sie Folgendes: MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name". Wenn path ein gültiges Verzeichnis ist, wird der Fehler ausgelöst und wir können fs_usage verwenden, um zu sehen, was im Programm vor sich geht:
Eine Datei wird open()ed, die path/.dat.nosyncXXXX.XXXXXX heißt (X ist zufällig)
Eine oder mehrere write()s schreiben den Inhalt in die Datei (wir kontrollieren dies nicht)
path/.dat.nosyncXXXX.XXXXXX wird renamed() zu path/name
Es handelt sich um einen temporären Dateischreibvorgang, gefolgt von einem rename(old, new), das nicht sicher ist.
Es ist nicht sicher, weil es die alten und neuen Pfade separat auflösen muss, was einige Zeit in Anspruch nehmen kann und anfällig für eine Race Condition sein kann. Für weitere Informationen können Sie die xnu-Funktion renameat_internal() überprüfen.
Im Grunde genommen, wenn ein privilegierter Prozess von einem Ordner umbenennt, den Sie kontrollieren, könnten Sie einen RCE gewinnen und ihn dazu bringen, auf eine andere Datei zuzugreifen oder, wie in diesem CVE, die Datei zu öffnen, die die privilegierte App erstellt hat, und einen FD zu speichern.
Wenn das Umbenennen auf einen Ordner zugreift, den Sie kontrollieren, während Sie die Quelldatei geändert haben oder einen FD dafür haben, ändern Sie die Zieldatei (oder den Ordner), um auf ein Symlink zu zeigen, sodass Sie jederzeit schreiben können.
Das war der Angriff im CVE: Um beispielsweise die TCC.db des Benutzers zu überschreiben, können wir:
/Users/hacker/ourlink erstellen, um auf /Users/hacker/Library/Application Support/com.apple.TCC/ zu zeigen
das Verzeichnis /Users/hacker/tmp/ erstellen
MTL_DUMP_PIPELINES_TO_JSON_FILE=/Users/hacker/tmp/TCC.db setzen
den Fehler auslösen, indem Sie Music mit dieser Umgebungsvariable ausführen
das open() von /Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX abfangen (X ist zufällig)
hier öffnen wir auch diese Datei zum Schreiben und halten den Dateideskriptor fest
atomar /Users/hacker/tmp mit /Users/hacker/ourlink in einer Schleife wechseln
wir tun dies, um unsere Chancen auf Erfolg zu maximieren, da das Zeitfenster für das Rennen ziemlich klein ist, aber das Verlieren des Rennens hat vernachlässigbare Nachteile
ein wenig warten
testen, ob wir Glück hatten
wenn nicht, erneut von oben ausführen
Weitere Informationen unter https://gergelykalman.com/lateralus-CVE-2023-32407-a-macos-tcc-bypass.html
Wenn Sie jetzt versuchen, die Umgebungsvariable MTL_DUMP_PIPELINES_TO_JSON_FILE zu verwenden, werden Apps nicht gestartet.
Als Root könnten Sie diesen Dienst aktivieren und der ARD-Agent hätte vollen Festplattzugriff, der dann von einem Benutzer missbraucht werden könnte, um eine neue TCC-Benutzerdatenbank zu kopieren.
TCC verwendet eine Datenbank im HOME-Ordner des Benutzers, um den Zugriff auf benutzerspezifische Ressourcen unter $HOME/Library/Application Support/com.apple.TCC/TCC.db zu steuern. Wenn es dem Benutzer gelingt, TCC mit einer $HOME-Umgebungsvariable, die auf einen anderen Ordner zeigt, neu zu starten, könnte der Benutzer eine neue TCC-Datenbank in /Library/Application Support/com.apple.TCC/TCC.db erstellen und TCC dazu bringen, jede TCC-Berechtigung für jede App zu gewähren.
Beachten Sie, dass Apple die Einstellung, die im Benutzerprofil im NFSHomeDirectory-Attribut für den Wert von $HOME gespeichert ist, verwendet. Wenn Sie also eine Anwendung mit Berechtigungen zur Änderung dieses Wertes (kTCCServiceSystemPolicySysAdminFiles) kompromittieren, können Sie diese Option mit einem TCC-Bypass waffenfähig machen.
Der erste POC verwendet dsexport und dsimport, um den HOME-Ordner des Benutzers zu ändern.
Holen Sie sich einen csreq-Blob für die Zielanwendung.
Platzieren Sie eine gefälschte TCC.db-Datei mit den erforderlichen Zugriffsrechten und dem csreq-Blob.
Exportieren Sie den Directory Services-Eintrag des Benutzers mit dsexport.
Ändern Sie den Directory Services-Eintrag, um das Home-Verzeichnis des Benutzers zu ändern.
Importieren Sie den geänderten Directory Services-Eintrag mit dsimport.
Stoppen Sie den tccd des Benutzers und starten Sie den Prozess neu.
Der zweite POC verwendete /usr/libexec/configd, das com.apple.private.tcc.allow mit dem Wert kTCCServiceSystemPolicySysAdminFiles hatte.
Es war möglich, configd mit der -t-Option auszuführen, ein Angreifer konnte ein benutzerdefiniertes Bundle zum Laden angeben. Daher ersetzt der Exploit die dsexport- und dsimport-Methode zur Änderung des Home-Verzeichnisses des Benutzers durch eine configd-Code-Injektion.
Für weitere Informationen siehe den originalen Bericht.
Es gibt verschiedene Techniken, um Code in einen Prozess zu injizieren und dessen TCC-Berechtigungen auszunutzen:
macOS Process AbuseDarüber hinaus ist die häufigste Prozessinjektion, um TCC zu umgehen, über Plugins (Bibliothek laden). Plugins sind zusätzlicher Code, der normalerweise in Form von Bibliotheken oder plist vorliegt, die von der Hauptanwendung geladen werden und unter ihrem Kontext ausgeführt werden. Daher hat der benutzerdefinierte Code auch Zugriff, wenn die Hauptanwendung Zugriff auf TCC-eingeschränkte Dateien hatte (über gewährte Berechtigungen oder Berechtigungen).
Die Anwendung /System/Library/CoreServices/Applications/Directory Utility.app hatte die Berechtigung kTCCServiceSystemPolicySysAdminFiles, lud Plugins mit der .daplug-Erweiterung und hatte nicht die gehärtete Laufzeit.
Um diesen CVE waffenfähig zu machen, wird das NFSHomeDirectory geändert (unter Ausnutzung der vorherigen Berechtigung), um die TCC-Datenbank des Benutzers zu übernehmen und TCC zu umgehen.
Für weitere Informationen siehe den originalen Bericht.
Die Binärdatei /usr/sbin/coreaudiod hatte die Berechtigungen com.apple.security.cs.disable-library-validation und com.apple.private.tcc.manager. Die erste erlaubt Code-Injektion und die zweite gibt ihr Zugriff auf die Verwaltung von TCC.
Diese Binärdatei erlaubte das Laden von drittanbieter Plugins aus dem Ordner /Library/Audio/Plug-Ins/HAL. Daher war es möglich, ein Plugin zu laden und die TCC-Berechtigungen mit diesem PoC auszunutzen:
Für weitere Informationen siehe den originalen Bericht.
Systemanwendungen, die den Kamerastream über Core Media I/O öffnen (Apps mit kTCCServiceCamera), laden in diesem Prozess diese Plugins, die sich in /Library/CoreMediaIO/Plug-Ins/DAL befinden (nicht SIP-beschränkt).
Es reicht aus, dort eine Bibliothek mit dem gemeinsamen Konstruktor zu speichern, um Code zu injizieren.
Mehrere Apple-Anwendungen waren anfällig dafür.
Die Firefox-Anwendung hatte die Berechtigungen com.apple.security.cs.disable-library-validation und com.apple.security.cs.allow-dyld-environment-variables:
Für weitere Informationen darüber, wie man dies leicht ausnutzen kann, prüfen Sie den ursprünglichen Bericht.
Die Binärdatei /system/Library/Filesystems/acfs.fs/Contents/bin/xsanctl hatte die Berechtigungen com.apple.private.tcc.allow und com.apple.security.get-task-allow, die es ermöglichten, Code in den Prozess einzuschleusen und die TCC-Berechtigungen zu nutzen.
Telegram hatte die Berechtigungen com.apple.security.cs.allow-dyld-environment-variables und com.apple.security.cs.disable-library-validation, sodass es möglich war, dies auszunutzen, um Zugriff auf seine Berechtigungen zu erhalten, wie z.B. das Aufzeichnen mit der Kamera. Sie können die Payload im Bericht finden.
Beachten Sie, wie die Umgebungsvariable verwendet wird, um eine Bibliothek zu laden. Eine benutzerdefinierte plist wurde erstellt, um diese Bibliothek einzuschleusen, und launchctl wurde verwendet, um sie zu starten:
Es ist möglich, open sogar im Sandbox-Modus aufzurufen.
Es ist recht üblich, dem Terminal Vollzugriff auf die Festplatte (FDA) zu gewähren, zumindest auf Computern, die von Technikern verwendet werden. Und es ist möglich, .terminal-Skripte damit aufzurufen.
.terminal-Skripte sind plist-Dateien wie diese mit dem Befehl, der im CommandString-Schlüssel ausgeführt werden soll:
Eine Anwendung könnte ein Terminal-Skript an einem Ort wie /tmp schreiben und es mit einem Befehl wie folgendem starten:
Jeder Benutzer (auch unprivilegierte) kann einen Time Machine-Snapshot erstellen und einbinden und auf ALLE Dateien dieses Snapshots zugreifen.
Der einzige privilegierte Zugriff, der benötigt wird, ist, dass die verwendete Anwendung (wie Terminal) Vollzugriff auf die Festplatte (FDA) haben muss (kTCCServiceSystemPolicyAllfiles), was von einem Administrator gewährt werden muss.
Eine detailliertere Erklärung kann im ursprünglichen Bericht** gefunden werden.**
Selbst wenn die TCC DB-Datei geschützt ist, war es möglich, eine neue TCC.db-Datei über das Verzeichnis zu mounten:
Check the full exploit in the original writeup.
Das Tool /usr/sbin/asr ermöglichte es, die gesamte Festplatte zu kopieren und an einem anderen Ort zu mounten, wodurch die TCC-Schutzmaßnahmen umgangen wurden.
Es gibt eine dritte TCC-Datenbank in /var/db/locationd/clients.plist, um anzuzeigen, welche Clients Zugriff auf Standortdienste haben.
Der Ordner /var/db/locationd/ war nicht vor DMG-Mounting geschützt, sodass es möglich war, unsere eigene plist zu mounten.
In mehreren Fällen speichern Dateien sensible Informationen wie E-Mails, Telefonnummern, Nachrichten... an ungeschützten Orten (was als Schwachstelle bei Apple zählt).
Das funktioniert nicht mehr, aber es funktionierte in der Vergangenheit:
Eine andere Möglichkeit, die CoreGraphics-Ereignisse verwendet:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
