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)
Questo non è un bypass, è solo come funziona TCC: Non protegge dalla scrittura. Se il Terminale non ha accesso per leggere il Desktop di un utente, può comunque scriverci dentro:
The extended attribute com.apple.macl viene aggiunto al nuovo file per dare all'app del creatore accesso per leggerlo.
È possibile mettere una finestra sopra il prompt TCC per far sì che l'utente accetti senza accorgersene. Puoi trovare un PoC in TCC-ClickJacking.
L'attaccante può creare app con qualsiasi nome (ad es. Finder, Google Chrome...) nel Info.plist e farla richiedere accesso a una posizione protetta da TCC. L'utente penserà che l'app legittima sia quella che richiede questo accesso.
Inoltre, è possibile rimuovere l'app legittima dal Dock e mettere quella falsa, così quando l'utente clicca su quella falsa (che può usare la stessa icona) potrebbe chiamare quella legittima, chiedere i permessi TCC ed eseguire un malware, facendo credere all'utente che l'app legittima abbia richiesto l'accesso.
Ulteriori informazioni e PoC in:
Per impostazione predefinita, un accesso tramite SSH aveva "Accesso completo al disco". Per disabilitarlo è necessario averlo elencato ma disabilitato (rimuoverlo dall'elenco non rimuoverà quei privilegi):
Qui puoi trovare esempi di come alcuni malware siano stati in grado di bypassare questa protezione:
Nota che ora, per poter abilitare SSH, hai bisogno di Accesso completo al disco
L'attributo com.apple.macl viene dato ai file per dare a una certa applicazione i permessi per leggerlo. Questo attributo viene impostato quando si trascina un file su un'app, o quando un utente fa doppio clic su un file per aprirlo con l'applicazione predefinita.
Pertanto, un utente potrebbe registrare un'app malevola per gestire tutte le estensioni e chiamare i Servizi di avvio per aprire qualsiasi file (quindi il file malevolo avrà accesso per leggerlo).
Con il diritto com.apple.private.icloud-account-access è possibile comunicare con il servizio XPC com.apple.iCloudHelper che fornirà token iCloud.
iMovie e Garageband avevano questo diritto e altri che lo consentivano.
Per ulteriori informazioni sull'exploit per ottenere token iCloud da quel diritto, controlla il talk: #OBTS v5.0: "Cosa succede sul tuo Mac, rimane su iCloud di Apple?!" - Wojciech Regula
Un'app con il permesso kTCCServiceAppleEvents sarà in grado di controllare altre app. Questo significa che potrebbe essere in grado di abusare dei permessi concessi alle altre app.
Per ulteriori informazioni sugli Apple Scripts, controlla:
Ad esempio, se un'app ha permesso di automazione su iTerm, per esempio in questo esempio Terminal ha accesso su iTerm:
Terminal, che non ha FDA, può chiamare iTerm, che ce l'ha, e usarlo per eseguire azioni:
O se un'app ha accesso su Finder, potrebbe utilizzare uno script come questo:
Il daemon tccd dell'utente utilizza la variabile di ambiente HOME per accedere al database degli utenti TCC da: $HOME/Library/Application Support/com.apple.TCC/TCC.db
Secondo questo post di Stack Exchange e poiché il daemon TCC viene eseguito tramite launchd all'interno del dominio dell'utente corrente, è possibile controllare tutte le variabili di ambiente passate ad esso.
Pertanto, un attaccante potrebbe impostare la variabile di ambiente $HOME in launchctl per puntare a una directory controllata, riavviare il daemon TCC e poi modificare direttamente il database TCC per concedersi tutti i diritti TCC disponibili senza mai richiedere all'utente finale.
PoC:
Notes aveva accesso a posizioni protette da TCC, ma quando viene creata una nota, questa è creata in una posizione non protetta. Quindi, potresti chiedere a Notes di copiare un file protetto in una nota (quindi in una posizione non protetta) e poi accedere al file:
Il binario /usr/libexec/lsd con la libreria libsecurity_translocate aveva il diritto com.apple.private.nullfs_allow che gli permetteva di creare un nullfs mount e aveva il diritto com.apple.private.tcc.allow con kTCCServiceSystemPolicyAllFiles per accedere a ogni file.
Era possibile aggiungere l'attributo di quarantena a "Library", chiamare il servizio XPC com.apple.security.translocation e poi mappare Library a $TMPDIR/AppTranslocation/d/d/Library dove tutti i documenti all'interno di Library potevano essere accessibili.
Music ha una caratteristica interessante: Quando è in esecuzione, importa i file trascinati in ~/Music/Music/Media.localized/Automatically Add to Music.localized nella "media library" dell'utente. Inoltre, chiama qualcosa come: rename(a, b); dove a e b sono:
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"
Questo comportamento rename(a, b); è vulnerabile a una Race Condition, poiché è possibile inserire all'interno della cartella Automatically Add to Music.localized un file TCC.db falso e poi, quando viene creata la nuova cartella (b) per copiare il file, eliminarlo e puntarlo a ~/Library/Application Support/com.apple.TCC/.
Se SQLITE_SQLLOG_DIR="path/folder" significa fondamentalmente che qualsiasi db aperto viene copiato in quel percorso. In questo CVE, questo controllo è stato abusato per scrivere all'interno di un database SQLite che verrà aperto da un processo con FDA il database TCC, e poi abusare di SQLITE_SQLLOG_DIR con un symlink nel nome del file in modo che quando quel database è aperto, l'utente TCC.db viene sovrascritto con quello aperto.
Ulteriori informazioni nella scrittura e nella conferenza.
Se la variabile di ambiente SQLITE_AUTO_TRACE è impostata, la libreria libsqlite3.dylib inizierà a registrare tutte le query SQL. Molte applicazioni utilizzavano questa libreria, quindi era possibile registrare tutte le loro query SQLite.
Diverse applicazioni Apple utilizzavano questa libreria per accedere a informazioni protette da TCC.
Questa variabile di ambiente è utilizzata dal framework Metal che è una dipendenza per vari programmi, in particolare Music, che ha FDA.
Impostando quanto segue: MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name". Se path è una directory valida, il bug verrà attivato e possiamo usare fs_usage per vedere cosa sta succedendo nel programma:
un file verrà open()ato, chiamato path/.dat.nosyncXXXX.XXXXXX (X è casuale)
uno o più write() scriveranno i contenuti nel file (non controlliamo questo)
path/.dat.nosyncXXXX.XXXXXX verrà renamed() a path/name
È una scrittura di file temporanea, seguita da un rename(old, new) che non è sicuro.
Non è sicuro perché deve risolvere i vecchi e nuovi percorsi separatamente, il che può richiedere del tempo e può essere vulnerabile a una Condizione di Gara. Per ulteriori informazioni, puoi controllare la funzione renameat_internal() di xnu.
Quindi, fondamentalmente, se un processo privilegiato sta rinominando da una cartella che controlli, potresti ottenere un RCE e farlo accedere a un file diverso o, come in questo CVE, aprire il file creato dall'app privilegiata e memorizzare un FD.
Se il rinominare accede a una cartella che controlli, mentre hai modificato il file sorgente o hai un FD ad esso, cambi la destinazione del file (o cartella) per puntare a un symlink, così puoi scrivere quando vuoi.
Questo era l'attacco nel CVE: Ad esempio, per sovrascrivere il TCC.db dell'utente, possiamo:
creare /Users/hacker/ourlink per puntare a /Users/hacker/Library/Application Support/com.apple.TCC/
creare la directory /Users/hacker/tmp/
impostare MTL_DUMP_PIPELINES_TO_JSON_FILE=/Users/hacker/tmp/TCC.db
attivare il bug eseguendo Music con questa variabile di ambiente
catturare l'open() di /Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX (X è casuale)
qui apriamo anche questo file per scrivere e teniamo il file descriptor
scambiare atomicamente /Users/hacker/tmp con /Users/hacker/ourlink in un ciclo
facciamo questo per massimizzare le nostre possibilità di successo poiché la finestra di gara è piuttosto ristretta, ma perdere la gara ha un impatto trascurabile
aspetta un po'
verifica se abbiamo avuto fortuna
se no, ripeti dall'inizio
Ulteriori informazioni su https://gergelykalman.com/lateralus-CVE-2023-32407-a-macos-tcc-bypass.html
Ora, se provi a usare la variabile di ambiente MTL_DUMP_PIPELINES_TO_JSON_FILE, le app non si avvieranno
Come root potresti abilitare questo servizio e l'agente ARD avrà accesso completo al disco, che potrebbe poi essere abusato da un utente per farlo copiare un nuovo database utente TCC.
TCC utilizza un database nella cartella HOME dell'utente per controllare l'accesso alle risorse specifiche per l'utente in $HOME/Library/Application Support/com.apple.TCC/TCC.db. Pertanto, se l'utente riesce a riavviare TCC con una variabile di ambiente $HOME che punta a una cartella diversa, l'utente potrebbe creare un nuovo database TCC in /Library/Application Support/com.apple.TCC/TCC.db e ingannare TCC per concedere qualsiasi permesso TCC a qualsiasi app.
Nota che Apple utilizza l'impostazione memorizzata all'interno del profilo dell'utente nell'attributo NFSHomeDirectory per il valore di $HOME, quindi se comprometti un'applicazione con permessi per modificare questo valore (kTCCServiceSystemPolicySysAdminFiles), puoi armare questa opzione con un bypass TCC.
Il primo POC utilizza dsexport e dsimport per modificare la HOME dell'utente.
Ottieni un blob csreq per l'app target.
Pianta un file TCC.db falso con accesso richiesto e il blob csreq.
Esporta l'entry dei Servizi di Directory dell'utente con dsexport.
Modifica l'entry dei Servizi di Directory per cambiare la home directory dell'utente.
Importa l'entry dei Servizi di Directory modificata con dsimport.
Ferma il tccd dell'utente e riavvia il processo.
Il secondo POC ha utilizzato /usr/libexec/configd che aveva com.apple.private.tcc.allow con il valore kTCCServiceSystemPolicySysAdminFiles.
Era possibile eseguire configd con l'opzione -t, un attaccante potrebbe specificare un Bundle personalizzato da caricare. Pertanto, l'exploit sostituisce il metodo dsexport e dsimport di cambiamento della home directory dell'utente con un iniezione di codice configd.
Per ulteriori informazioni, controlla il report originale.
Ci sono diverse tecniche per iniettare codice all'interno di un processo e abusare dei suoi privilegi TCC:
Inoltre, la tecnica di iniezione di processo più comune per bypassare TCC trovata è tramite plugin (load library). I plugin sono codice extra solitamente sotto forma di librerie o plist, che verranno caricati dall'applicazione principale e verranno eseguiti nel suo contesto. Pertanto, se l'applicazione principale aveva accesso a file TCC riservati (tramite permessi o diritti concessi), il codice personalizzato avrà anch'esso accesso.
L'applicazione /System/Library/CoreServices/Applications/Directory Utility.app aveva il diritto kTCCServiceSystemPolicySysAdminFiles, caricava plugin con estensione .daplug e non aveva il runtime rinforzato.
Per armare questo CVE, il NFSHomeDirectory è cambiato (abusando del diritto precedente) per poter prendere il database TCC degli utenti per bypassare TCC.
Per ulteriori informazioni, controlla il report originale.
Il binario /usr/sbin/coreaudiod aveva i diritti com.apple.security.cs.disable-library-validation e com.apple.private.tcc.manager. Il primo consentiva l'iniezione di codice e il secondo forniva accesso per gestire TCC.
Questo binario consentiva di caricare plugin di terze parti dalla cartella /Library/Audio/Plug-Ins/HAL. Pertanto, era possibile caricare un plugin e abusare dei permessi TCC con questo PoC:
Per ulteriori informazioni, controlla il rapporto originale.
Le applicazioni di sistema che aprono il flusso della fotocamera tramite Core Media I/O (app con kTCCServiceCamera) caricano nel processo questi plugin situati in /Library/CoreMediaIO/Plug-Ins/DAL (non soggetti a restrizioni SIP).
Basta memorizzare lì una libreria con il costruttore comune per iniettare codice.
Diverse applicazioni Apple erano vulnerabili a questo.
L'applicazione Firefox aveva i diritti com.apple.security.cs.disable-library-validation e com.apple.security.cs.allow-dyld-environment-variables:
Per ulteriori informazioni su come sfruttare facilmente questo controlla il rapporto originale.
Il binario /system/Library/Filesystems/acfs.fs/Contents/bin/xsanctl aveva i diritti com.apple.private.tcc.allow e com.apple.security.get-task-allow, che consentivano di iniettare codice all'interno del processo e utilizzare i privilegi TCC.
Telegram aveva i diritti com.apple.security.cs.allow-dyld-environment-variables e com.apple.security.cs.disable-library-validation, quindi era possibile abusarne per ottenere accesso alle sue autorizzazioni come registrare con la fotocamera. Puoi trovare il payload nel writeup.
Nota come utilizzare la variabile env per caricare una libreria, un plist personalizzato è stato creato per iniettare questa libreria e launchctl è stato utilizzato per lanciarla:
È possibile invocare open anche mentre si è in sandbox
È abbastanza comune concedere Full Disk Access (FDA) al terminale, almeno nei computer utilizzati da persone del settore tecnologico. Ed è possibile invocare script .terminal utilizzandolo.
Gli script .terminal sono file plist come questo con il comando da eseguire nella chiave CommandString:
Un'applicazione potrebbe scrivere uno script del terminale in una posizione come /tmp e lanciarlo con un comando come:
Qualsiasi utente (anche quelli non privilegiati) può creare e montare un'istantanea di Time Machine e accedere a TUTTI i file di quell'istantanea.
L'unico privilegio necessario è che l'applicazione utilizzata (come Terminal) abbia accesso Full Disk Access (FDA) (kTCCServiceSystemPolicyAllfiles), che deve essere concesso da un amministratore.
Una spiegazione più dettagliata può essere trovata nel rapporto originale.
Anche se il file del database TCC è protetto, era possibile montare sopra la directory un nuovo file TCC.db:
Controlla il full exploit nel writeup originale.
Lo strumento /usr/sbin/asr consentiva di copiare l'intero disco e montarlo in un'altra posizione bypassando le protezioni TCC.
C'è un terzo database TCC in /var/db/locationd/clients.plist per indicare i client autorizzati ad accedere ai servizi di localizzazione.
La cartella /var/db/locationd/ non era protetta dal montaggio DMG quindi era possibile montare il nostro plist.
In diverse occasioni i file memorizzeranno informazioni sensibili come email, numeri di telefono, messaggi... in posizioni non protette (che contano come una vulnerabilità in Apple).
Questo non funziona più, ma funzionava in passato:
Un altro modo utilizzando eventi CoreGraphics:
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
