macOS SIP
Informazioni di base
La Protezione dell'Integrità del Sistema (SIP) in macOS è un meccanismo progettato per impedire anche agli utenti più privilegiati di apportare modifiche non autorizzate a cartelle di sistema chiave. Questa funzione gioca un ruolo cruciale nel mantenere l'integrità del sistema limitando azioni come l'aggiunta, la modifica o la cancellazione di file in aree protette. Le cartelle principali protette da SIP includono:
/System
/bin
/sbin
/usr
Le regole che governano il comportamento del SIP sono definite nel file di configurazione situato in /System/Library/Sandbox/rootless.conf
. All'interno di questo file, i percorsi che sono preceduti da un asterisco (*) sono indicati come eccezioni alle altrimenti rigorose restrizioni del SIP.
Considera l'esempio qui sotto:
Questo frammento implica che mentre SIP generalmente protegge la /usr
directory, ci sono specifici sottodirectory (/usr/libexec/cups
, /usr/local
, e /usr/share/man
) dove le modifiche sono consentite, come indicato dall'asterisco (*) che precede i loro percorsi.
Per verificare se una directory o un file è protetto da SIP, puoi usare il comando ls -lOd
per controllare la presenza del flag restricted
o sunlnk
. Ad esempio:
In questo caso, il flag sunlnk
indica che la directory /usr/libexec/cups
stessa non può essere eliminata, anche se i file al suo interno possono essere creati, modificati o eliminati.
D'altra parte:
Qui, il flag restricted
indica che la directory /usr/libexec
è protetta da SIP. In una directory protetta da SIP, i file non possono essere creati, modificati o eliminati.
Inoltre, se un file contiene l'attributo com.apple.rootless
come attributo esteso, quel file sarà anche protetto da SIP.
SIP limita anche altre azioni di root come:
Caricamento di estensioni del kernel non affidabili
Ottenere task-ports per processi firmati da Apple
Modificare le variabili NVRAM
Consentire il debug del kernel
Le opzioni sono mantenute nella variabile nvram come un bitflag (csr-active-config
su Intel e lp-sip0
è letto dall'albero dei dispositivi avviato per ARM). Puoi trovare i flag nel codice sorgente di XNU in csr.sh
:
Stato SIP
Puoi controllare se SIP è abilitato sul tuo sistema con il seguente comando:
Se è necessario disabilitare SIP, è necessario riavviare il computer in modalità di recupero (premendo Command+R durante l'avvio), quindi eseguire il seguente comando:
Se desideri mantenere SIP abilitato ma rimuovere le protezioni di debug, puoi farlo con:
Altre Restrizioni
Disabilita il caricamento di estensioni del kernel non firmate (kexts), garantendo che solo le estensioni verificate interagiscano con il kernel di sistema.
Previene il debugging dei processi di sistema macOS, proteggendo i componenti core del sistema da accessi e modifiche non autorizzate.
Inibisce strumenti come dtrace dall'ispezionare i processi di sistema, proteggendo ulteriormente l'integrità del funzionamento del sistema.
Scopri di più sulle informazioni SIP in questo talk.
Bypass SIP
Il bypass di SIP consente a un attaccante di:
Accedere ai Dati Utente: Leggere dati sensibili dell'utente come email, messaggi e cronologia di Safari da tutti gli account utente.
Bypass TCC: Manipolare direttamente il database TCC (Trasparenza, Consenso e Controllo) per concedere accesso non autorizzato alla webcam, al microfono e ad altre risorse.
Stabilire Persistenza: Posizionare malware in posizioni protette da SIP, rendendolo resistente alla rimozione, anche da privilegi di root. Questo include anche la possibilità di manomettere lo strumento di rimozione malware (MRT).
Caricare Estensioni del Kernel: Sebbene ci siano ulteriori misure di sicurezza, bypassare SIP semplifica il processo di caricamento di estensioni del kernel non firmate.
Pacchetti Installer
I pacchetti installer firmati con il certificato di Apple possono bypassare le sue protezioni. Ciò significa che anche i pacchetti firmati da sviluppatori standard verranno bloccati se tentano di modificare le directory protette da SIP.
File SIP Inesistente
Una potenziale falla è che se un file è specificato in rootless.conf
ma attualmente non esiste, può essere creato. Il malware potrebbe sfruttare questo per stabilire persistenza sul sistema. Ad esempio, un programma malevolo potrebbe creare un file .plist in /System/Library/LaunchDaemons
se è elencato in rootless.conf
ma non presente.
com.apple.rootless.install.heritable
L'attributo com.apple.rootless.install.heritable
consente di bypassare SIP
È stato scoperto che era possibile scambiare il pacchetto installer dopo che il sistema aveva verificato la sua firma e poi, il sistema avrebbe installato il pacchetto malevolo invece di quello originale. Poiché queste azioni venivano eseguite da system_installd
, ciò avrebbe consentito di bypassare SIP.
Se un pacchetto veniva installato da un'immagine montata o da un'unità esterna, l'installer avrebbe eseguito il binario da quella file system (invece che da una posizione protetta da SIP), facendo eseguire a system_installd
un binario arbitrario.
CVE-2021-30892 - Shrootless
I ricercatori di questo post del blog hanno scoperto una vulnerabilità nel meccanismo di Protezione dell'Integrità di Sistema (SIP) di macOS, soprannominata vulnerabilità 'Shrootless'. Questa vulnerabilità si concentra sul demone system_installd
, che ha un attributo, com.apple.rootless.install.heritable
, che consente a qualsiasi dei suoi processi figli di bypassare le restrizioni del file system di SIP.
Il demone system_installd
installerà pacchetti che sono stati firmati da Apple.
I ricercatori hanno scoperto che durante l'installazione di un pacchetto firmato da Apple (.pkg file), system_installd
esegue qualsiasi script post-install incluso nel pacchetto. Questi script vengono eseguiti dalla shell predefinita, zsh
, che esegue automaticamente comandi dal file /etc/zshenv
, se esiste, anche in modalità non interattiva. Questo comportamento potrebbe essere sfruttato dagli attaccanti: creando un file /etc/zshenv
malevolo e aspettando che system_installd
invochi zsh
, potrebbero eseguire operazioni arbitrarie sul dispositivo.
Inoltre, è stato scoperto che /etc/zshenv
potrebbe essere utilizzato come una tecnica di attacco generale, non solo per un bypass di SIP. Ogni profilo utente ha un file ~/.zshenv
, che si comporta allo stesso modo di /etc/zshenv
ma non richiede permessi di root. Questo file potrebbe essere utilizzato come meccanismo di persistenza, attivandosi ogni volta che zsh
si avvia, o come meccanismo di elevazione dei privilegi. Se un utente admin si eleva a root usando sudo -s
o sudo <command>
, il file ~/.zshenv
verrebbe attivato, elevandosi effettivamente a root.
In CVE-2022-22583 è stato scoperto che lo stesso processo system_installd
poteva ancora essere abusato perché stava mettendo lo script post-install in una cartella con nome casuale protetta da SIP all'interno di /tmp
. Il fatto è che /tmp
stesso non è protetto da SIP, quindi era possibile montare un immagine virtuale su di esso, poi l'installer avrebbe messo lì lo script post-install, smontato l'immagine virtuale, ricreato tutte le cartelle e aggiunto lo script di post installazione con il payload da eseguire.
È stata identificata una vulnerabilità in cui fsck_cs
è stato indotto a corrompere un file cruciale, a causa della sua capacità di seguire link simbolici. In particolare, gli attaccanti hanno creato un link da /dev/diskX
al file /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist
. Eseguire fsck_cs
su /dev/diskX
ha portato alla corruzione di Info.plist
. L'integrità di questo file è vitale per il SIP (Protezione dell'Integrità di Sistema) del sistema operativo, che controlla il caricamento delle estensioni del kernel. Una volta corrotto, la capacità di SIP di gestire le esclusioni del kernel è compromessa.
I comandi per sfruttare questa vulnerabilità sono:
L'exploitation de cette vulnérabilité a de graves implications. Le fichier Info.plist
, normalement responsable de la gestion des autorisations pour les extensions du noyau, devient inefficace. Cela inclut l'incapacité de mettre sur liste noire certaines extensions, telles que AppleHWAccess.kext
. Par conséquent, avec le mécanisme de contrôle de SIP hors service, cette extension peut être chargée, accordant un accès en lecture et en écriture non autorisé à la RAM du système.
È stato possibile montare un nuovo file system su cartelle protette da SIP per bypassare la protezione.
Il sistema è impostato per avviarsi da un'immagine disco di installazione incorporata all'interno di Install macOS Sierra.app
per aggiornare il sistema operativo, utilizzando l'utilità bless
. Il comando utilizzato è il seguente:
La sicurezza di questo processo può essere compromessa se un attaccante altera l'immagine di aggiornamento (InstallESD.dmg
) prima dell'avvio. La strategia prevede la sostituzione di un loader dinamico (dyld) con una versione malevola (libBaseIA.dylib
). Questa sostituzione porta all'esecuzione del codice dell'attaccante quando viene avviato l'installer.
Il codice dell'attaccante guadagna il controllo durante il processo di aggiornamento, sfruttando la fiducia del sistema nell'installer. L'attacco procede alterando l'immagine InstallESD.dmg
tramite method swizzling, mirando in particolare al metodo extractBootBits
. Questo consente l'iniezione di codice malevolo prima che l'immagine del disco venga utilizzata.
Inoltre, all'interno di InstallESD.dmg
, c'è un BaseSystem.dmg
, che funge da file system radice del codice di aggiornamento. Iniettare una libreria dinamica in questo consente al codice malevolo di operare all'interno di un processo in grado di alterare file a livello di OS, aumentando significativamente il potenziale di compromissione del sistema.
In questo intervento di DEF CON 31, viene mostrato come systemmigrationd
(che può bypassare SIP) esegue uno script bash e uno script perl, che possono essere abusati tramite variabili d'ambiente BASH_ENV
e PERL5OPT
.
CVE-2023-42860
Come dettagliato in questo post del blog, uno script postinstall
da pacchetti InstallAssistant.pkg
consentiva di eseguire:
e era possibile creare un symlink in ${SHARED_SUPPORT_PATH}/SharedSupport.dmg
che avrebbe permesso a un utente di rimuovere le restrizioni da qualsiasi file, eludendo la protezione SIP.
com.apple.rootless.install
L'attributo com.apple.rootless.install
consente di eludere SIP
L'attributo com.apple.rootless.install
è noto per eludere la Protezione dell'Integrità di Sistema (SIP) su macOS. Questo è stato menzionato in particolare in relazione a CVE-2022-26712.
In questo caso specifico, il servizio XPC di sistema situato in /System/Library/PrivateFrameworks/ShoveService.framework/Versions/A/XPCServices/SystemShoveService.xpc
possiede questo attributo. Questo consente al processo correlato di eludere i vincoli SIP. Inoltre, questo servizio presenta un metodo che consente il movimento di file senza imporre alcuna misura di sicurezza.
Sealed System Snapshots
I Sealed System Snapshots sono una funzionalità introdotta da Apple in macOS Big Sur (macOS 11) come parte del meccanismo di Protezione dell'Integrità di Sistema (SIP) per fornire un ulteriore livello di sicurezza e stabilità del sistema. Sono essenzialmente versioni di sola lettura del volume di sistema.
Ecco uno sguardo più dettagliato:
Sistema Immutabile: I Sealed System Snapshots rendono il volume di sistema macOS "immutabile", il che significa che non può essere modificato. Questo previene qualsiasi cambiamento non autorizzato o accidentale al sistema che potrebbe compromettere la sicurezza o la stabilità del sistema.
Aggiornamenti del Software di Sistema: Quando installi aggiornamenti o upgrade di macOS, macOS crea un nuovo snapshot di sistema. Il volume di avvio di macOS utilizza quindi APFS (Apple File System) per passare a questo nuovo snapshot. L'intero processo di applicazione degli aggiornamenti diventa più sicuro e affidabile poiché il sistema può sempre tornare allo snapshot precedente se qualcosa va storto durante l'aggiornamento.
Separazione dei Dati: In concomitanza con il concetto di separazione dei volumi Dati e Sistema introdotto in macOS Catalina, la funzionalità Sealed System Snapshot garantisce che tutti i tuoi dati e le impostazioni siano memorizzati su un volume separato "Dati". Questa separazione rende i tuoi dati indipendenti dal sistema, semplificando il processo di aggiornamenti di sistema e migliorando la sicurezza del sistema.
Ricorda che questi snapshot sono gestiti automaticamente da macOS e non occupano spazio aggiuntivo sul tuo disco, grazie alle capacità di condivisione dello spazio di APFS. È anche importante notare che questi snapshot sono diversi dagli snapshot di Time Machine, che sono backup accessibili dall'utente dell'intero sistema.
Controlla gli Snapshot
Il comando diskutil apfs list
elenca i dettagli dei volumi APFS e il loro layout:
Nell'output precedente è possibile vedere che le posizioni accessibili all'utente sono montate sotto /System/Volumes/Data
.
Inoltre, lo snapshot del volume di sistema macOS è montato in /
ed è sigillato (firmato crittograficamente dal sistema operativo). Quindi, se SIP viene eluso e modificato, il sistema operativo non si avvierà più.
È anche possibile verificare che il sigillo sia abilitato eseguendo:
Inoltre, il disco snapshot è montato anche come sola lettura:
Last updated