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)
Le restrizioni di avvio in macOS sono state introdotte per migliorare la sicurezza regolando come, chi e da dove un processo può essere avviato. Iniziato in macOS Ventura, forniscono un framework che categorizza ogni binario di sistema in distinte categorie di restrizione, definite all'interno della trust cache, un elenco contenente i binari di sistema e i loro rispettivi hash. Queste restrizioni si estendono a ogni binario eseguibile all'interno del sistema, comportando un insieme di regole che delineano i requisiti per l'avvio di un particolare binario. Le regole comprendono le auto-restrizioni che un binario deve soddisfare, le restrizioni parentali che devono essere soddisfatte dal suo processo genitore e le restrizioni responsabili a cui devono attenersi altre entità rilevanti.
Il meccanismo si estende alle app di terze parti attraverso le Environment Constraints, a partire da macOS Sonoma, consentendo agli sviluppatori di proteggere le loro app specificando un insieme di chiavi e valori per le restrizioni ambientali.
Definisci le restrizioni dell'ambiente di avvio e della libreria in dizionari di restrizione che salvi in file di elenco di proprietà launchd, o in file di elenco di proprietà separati che utilizzi nella firma del codice.
Ci sono 4 tipi di restrizioni:
Auto-restrizioni: restrizioni applicate al binario in esecuzione.
Processo genitore: restrizioni applicate al genitore del processo (ad esempio launchd che esegue un servizio XP)
Restrizioni responsabili: restrizioni applicate al processo che chiama il servizio in una comunicazione XPC
Restrizioni di caricamento della libreria: utilizza le restrizioni di caricamento della libreria per descrivere selettivamente il codice che può essere caricato
Quindi, quando un processo cerca di avviare un altro processo — chiamando execve(_:_:_:) o posix_spawn(_:_:_:_:_:_:) — il sistema operativo verifica che il file eseguibile soddisfi la sua propria auto-restrizione. Controlla anche che l'eseguibile del processo genitore soddisfi la restrizione parentale dell'eseguibile e che l'eseguibile del processo responsabile soddisfi la restrizione del processo responsabile dell'eseguibile. Se una di queste restrizioni di avvio non è soddisfatta, il sistema operativo non esegue il programma.
Se durante il caricamento di una libreria qualsiasi parte della restrizione della libreria non è vera, il tuo processo non carica la libreria.
Un LC è composto da fatti e operazioni logiche (e, o..) che combinano fatti.
I fatti che un LC può utilizzare sono documentati. Ad esempio:
is-init-proc: Un valore booleano che indica se l'eseguibile deve essere il processo di inizializzazione del sistema operativo (launchd).
is-sip-protected: Un valore booleano che indica se l'eseguibile deve essere un file protetto da System Integrity Protection (SIP).
on-authorized-authapfs-volume: Un valore booleano che indica se il sistema operativo ha caricato l'eseguibile da un volume APFS autorizzato e autenticato.
on-authorized-authapfs-volume: Un valore booleano che indica se il sistema operativo ha caricato l'eseguibile da un volume APFS autorizzato e autenticato.
Volume Cryptexes
on-system-volume: Un valore booleano che indica se il sistema operativo ha caricato l'eseguibile dal volume di sistema attualmente avviato.
Dentro /System...
...
Quando un binario Apple è firmato, viene assegnato a una categoria LC all'interno della trust cache.
Le categorie LC di iOS 16 sono state invertite e documentate qui.
Le attuali categorie LC (macOS 14 - Somona) sono state invertite e le loro descrizioni possono essere trovate qui.
Ad esempio, la Categoria 1 è:
(on-authorized-authapfs-volume || on-system-volume): Deve trovarsi nel volume di sistema o Cryptexes.
launch-type == 1: Deve essere un servizio di sistema (plist in LaunchDaemons).
validation-category == 1: Un eseguibile del sistema operativo.
is-init-proc: Launchd
Hai ulteriori informazioni a riguardo qui, ma fondamentalmente, sono definiti in AMFI (AppleMobileFileIntegrity), quindi devi scaricare il Kernel Development Kit per ottenere il KEXT. I simboli che iniziano con kConstraintCategory sono quelli interessanti. Estraendoli otterrai uno stream codificato DER (ASN.1) che dovrai decodificare con ASN.1 Decoder o la libreria python-asn1 e il suo script dump.py, andrivet/python-asn1 che ti darà una stringa più comprensibile.
Questi sono i Launch Constraints impostati configurati in applicazioni di terze parti. Lo sviluppatore può selezionare i fatti e gli operatori logici da utilizzare nella sua applicazione per limitare l'accesso a se stesso.
È possibile enumerare gli Environment Constraints di un'applicazione con:
In macOS ci sono alcuni cache di fiducia:
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/BaseSystemTrustCache.img4
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4
/System/Library/Security/OSLaunchPolicyData
E in iOS sembra che si trovi in /usr/standalone/firmware/FUD/StaticTrustCache.img4.
Su macOS in esecuzione su dispositivi Apple Silicon, se un binario firmato da Apple non è nel cache di fiducia, AMFI rifiuterà di caricarlo.
I precedenti file di cache di fiducia sono nel formato IMG4 e IM4P, essendo IM4P la sezione payload di un formato IMG4.
Puoi usare pyimg4 per estrarre il payload dei database:
(Un'altra opzione potrebbe essere quella di utilizzare lo strumento img4tool, che funzionerà anche su M1 anche se il rilascio è vecchio e per x86_64 se lo installi nelle posizioni appropriate).
Ora puoi utilizzare lo strumento trustcache per ottenere le informazioni in un formato leggibile:
La cache di fiducia segue la seguente struttura, quindi la categoria LC è la quarta colonna
Then, you could use a script such as this one to extract data.
From that data you can check the Apps with a launch constraints value of 0, which are the ones that aren't constrained (check here for what each value is).
Le Launch Constraints avrebbero mitigato diversi attacchi vecchi assicurandosi che il processo non venga eseguito in condizioni inaspettate: Ad esempio, da posizioni inaspettate o invocato da un processo padre inaspettato (se solo launchd dovrebbe lanciarlo).
Inoltre, le Launch Constraints mitigano anche gli attacchi di downgrade.
Tuttavia, non mitigano gli abusi comuni di XPC, iniezioni di codice Electron o iniezioni di dylib senza validazione della libreria (a meno che gli ID team che possono caricare librerie non siano noti).
Nella release di Sonoma, un punto notevole è la configurazione della responsabilità del servizio demone XPC. Il servizio XPC è responsabile di se stesso, a differenza del client connesso che è responsabile. Questo è documentato nel rapporto di feedback FB13206884. Questa configurazione potrebbe sembrare difettosa, poiché consente alcune interazioni con il servizio XPC:
Avvio del Servizio XPC: Se considerato un bug, questa configurazione non consente di avviare il servizio XPC tramite codice dell'attaccante.
Connessione a un Servizio Attivo: Se il servizio XPC è già in esecuzione (possibilmente attivato dalla sua applicazione originale), non ci sono barriere per connettersi ad esso.
Sebbene l'implementazione di vincoli sul servizio XPC possa essere vantaggiosa ristretta la finestra per potenziali attacchi, non affronta la preoccupazione principale. Garantire la sicurezza del servizio XPC richiede fondamentalmente di validare efficacemente il client connesso. Questo rimane l'unico metodo per rafforzare la sicurezza del servizio. Inoltre, vale la pena notare che la configurazione di responsabilità menzionata è attualmente operativa, il che potrebbe non allinearsi con il design previsto.
Anche se è richiesto che l'applicazione debba essere aperta da LaunchService (nei vincoli dei genitori). Questo può essere ottenuto utilizzando open (che può impostare variabili di ambiente) o utilizzando l'API dei Servizi di Lancio (dove possono essere indicate le variabili di ambiente).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
