macOS SIP
WhiteIntel è un motore di ricerca alimentato dal dark web che offre funzionalità gratuite per verificare se un'azienda o i suoi clienti sono stati compromessi da malware ruba-informazioni.
Il loro obiettivo principale di WhiteIntel è contrastare le violazioni degli account e gli attacchi ransomware derivanti da malware che rubano informazioni.
Puoi visitare il loro sito web e provare il loro motore gratuitamente su:
Informazioni di Base
System Integrity Protection (SIP) in macOS è un meccanismo progettato per impedire persino agli utenti più privilegiati di apportare modifiche non autorizzate alle cartelle di sistema chiave. Questa funzionalità svolge un ruolo cruciale nel mantenere l'integrità del sistema limitando azioni come aggiungere, modificare o eliminare file in aree protette. Le cartelle principali protette da SIP includono:
/System
/bin
/sbin
/usr
Le regole che governano il comportamento di SIP sono definite nel file di configurazione situato in /System/Library/Sandbox/rootless.conf. All'interno di questo file, i percorsi che sono prefissati con un asterisco (*) sono indicati come eccezioni alle restrizioni rigorose altrimenti imposte da SIP.
Considera l'esempio seguente:
Questo frammento implica che mentre SIP generalmente protegge la directory /usr, ci sono specifiche sottodirectory (/usr/libexec/cups, /usr/local e /usr/share/man) dove le modifiche sono permesse, come indicato dall'asterisco (*) che precede i loro percorsi.
Per verificare se una directory o un file è protetto da SIP, è possibile utilizzare il comando ls -lOd per controllare la presenza del flag restricted o sunlnk. Per 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 esteso com.apple.rootless, quel file sarà anche protetto da SIP.
SIP limita anche altre azioni di root come:
Caricamento di estensioni kernel non attendibili
Ottenere porte di attività 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 XNU in csr.sh:
Stato di SIP
Puoi verificare se SIP è abilitato sul tuo sistema con il seguente comando:
Se hai bisogno di disabilitare SIP, devi riavviare il tuo computer in modalità di ripristino (premendo Command+R durante l'avvio), quindi eseguire il seguente comando:
Se desideri mantenere SIP abilitato ma rimuovere le protezioni del debug, puoi farlo con:
Altre restrizioni
Vieta il caricamento di estensioni kernel non firmate (kext), garantendo che solo le estensioni verificate interagiscano con il kernel di sistema.
Impedisce il debug dei processi di sistema di macOS, proteggendo i componenti principali del sistema dall'accesso e dalla modifica non autorizzati.
Inibisce strumenti come dtrace dall'ispezionare i processi di sistema, proteggendo ulteriormente l'integrità dell'operatività del sistema.
Per saperne di più sulle informazioni SIP in questa presentazione.
Bypass di SIP
Il bypass di SIP consente a un attaccante di:
Accedere ai dati dell'utente: Leggere dati sensibili dell'utente come posta, messaggi e cronologia di Safari di tutti gli account utente.
Bypass di TCC: Manipolare direttamente il database TCC (Trasparenza, Consenso e Controllo) per concedere l'accesso non autorizzato alla webcam, al microfono e ad altre risorse.
Stabilire la persistenza: Posizionare malware in posizioni protette da SIP, rendendolo resistente alla rimozione, anche con privilegi di root. Questo include anche la possibilità di manomettere lo Strumento di Rimozione Malware (MRT).
Caricare estensioni kernel: Anche se ci sono ulteriori protezioni, il bypass di SIP semplifica il processo di caricamento di estensioni kernel non firmate.
Pacchetti di installazione
I pacchetti di installazione firmati con il certificato di Apple possono eludere le sue protezioni. Ciò significa che anche i pacchetti firmati da sviluppatori standard verranno bloccati se tentano di modificare directory protette da SIP.
File SIP inesistente
Un potenziale vuoto è che se un file è specificato in rootless.conf ma attualmente non esiste, può essere creato. Il malware potrebbe sfruttare questo per stabilire la persistenza nel sistema. Ad esempio, un programma dannoso potrebbe creare un file .plist in /System/Library/LaunchDaemons se è elencato in rootless.conf ma non presente.
com.apple.rootless.install.heritable
L'entitlement com.apple.rootless.install.heritable consente di eludere SIP
È stato scoperto che era possibile sostituire il pacchetto di installazione dopo che il sistema ha verificato la sua firma del codice e quindi, il sistema avrebbe installato il pacchetto dannoso al posto dell'originale. Poiché queste azioni sono state eseguite da system_installd, ciò avrebbe permesso di eludere SIP.
Se un pacchetto veniva installato da un'immagine montata o da un'unità esterna, l'installatore avrebbe eseguito il binario da quella filesystem (anziché da una posizione protetta da SIP), facendo sì che system_installd eseguisse un binario arbitrario.
CVE-2021-30892 - Shrootless
Gli esperti di sicurezza di questo post sul blog hanno scoperto una vulnerabilità nel meccanismo di Protezione dell'Integrità di Sistema (SIP) di macOS, denominata vulnerabilità 'Shrootless'. Questa vulnerabilità riguarda il demone system_installd, che ha un entitlement, com.apple.rootless.install.heritable, che consente a uno qualsiasi dei suoi processi figlio di eludere le restrizioni del file system di SIP.
Il demone system_installd installerà pacchetti firmati da Apple.
Gli esperti hanno scoperto che durante l'installazione di un pacchetto firmato da Apple (.pkg), system_installd esegue eventuali script post-installazione inclusi nel pacchetto. Questi script vengono eseguiti dalla shell predefinita, zsh, che esegue automaticamente i comandi dal file /etc/zshenv, se esiste, anche in modalità non interattiva. Questo comportamento potrebbe essere sfruttato dagli attaccanti: creando un file /etc/zshenv dannoso e attendendo che system_installd invochi zsh, potrebbero eseguire operazioni arbitrarie sul dispositivo.
Inoltre, è stato scoperto che /etc/zshenv potrebbe essere utilizzato come 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 amministratore si eleva a root usando sudo -s o sudo <comando>, il file ~/.zshenv verrebbe attivato, elevando effettivamente a root.
In CVE-2022-22583 è stato scoperto che lo stesso processo system_installd poteva ancora essere abusato perché metteva lo script post-installazione dentro una cartella con nome casuale protetta da SIP dentro a /tmp. Il punto è che /tmp non è protetto da SIP, quindi era possibile montare un'immagine virtuale su di esso, quindi l'installatore avrebbe messo lì lo script post-installazione, 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 ingannato nel corrompere un file cruciale, a causa della sua capacità di seguire i 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 la Protezione dell'Integrità di Sistema (SIP) del sistema operativo, che controlla il caricamento delle estensioni kernel. Una volta corrotto, la capacità di SIP di gestire le esclusioni del kernel è compromessa.
I comandi per sfruttare questa vulnerabilità sono:
L'exploit di questa vulnerabilità ha gravi implicazioni. Il file Info.plist, normalmente responsabile della gestione delle autorizzazioni per le estensioni del kernel, diventa inefficace. Ciò include l'incapacità di mettere in blacklist alcune estensioni, come AppleHWAccess.kext. Di conseguenza, con il meccanismo di controllo di SIP fuori uso, questa estensione può essere caricata, concedendo accesso non autorizzato in lettura e scrittura alla RAM del sistema.
Era possibile montare un nuovo sistema di file sopra le cartelle protette da SIP per eludere la protezione.
Il sistema è impostato per avviarsi da un'immagine disco dell'installatore 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 del boot. La strategia prevede la sostituzione di un caricatore dinamico (dyld) con una versione malevola (libBaseIA.dylib). Questa sostituzione porta all'esecuzione del codice dell'attaccante quando l'installazione viene avviata.
Il codice dell'attaccante ottiene il controllo durante il processo di aggiornamento, sfruttando la fiducia del sistema nell'installatore. L'attacco procede alterando l'immagine InstallESD.dmg tramite method swizzling, prendendo di mira in particolare il 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 sistema di file radice del codice di aggiornamento. L'iniezione di una libreria dinamica in questo permette al codice malevolo di operare all'interno di un processo in grado di alterare file di livello OS, aumentando significativamente il potenziale compromesso del sistema.
In questa presentazione da DEF CON 31, viene mostrato come systemmigrationd (che può aggirare SIP) esegue uno script bash e uno script perl, che possono essere abusati tramite le variabili d'ambiente BASH_ENV e PERL5OPT.
CVE-2023-42860
Come dettagliato in questo post sul blog, uno script postinstall dai pacchetti InstallAssistant.pkg consentiva l'esecuzione:
È stato possibile creare un symlink in ${SHARED_SUPPORT_PATH}/SharedSupport.dmg che avrebbe permesso a un utente di rimuovere le restrizioni da qualsiasi file, aggirando la protezione SIP.
com.apple.rootless.install
L'entitlement com.apple.rootless.install consente di aggirare SIP
L'entitlement com.apple.rootless.install è noto per aggirare la Protezione dell'Integrità di Sistema (SIP) su macOS. Questo è stato menzionato 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 entitlement. Ciò consente al processo correlato di aggirare i vincoli di SIP. Inoltre, questo servizio presenta un metodo che permette lo spostamento di file senza applicare misure di sicurezza.
Snapshot di Sistema Sigillati
I Snapshot di Sistema Sigillati 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à di sistema. Sono essenzialmente versioni in sola lettura del volume di sistema.
Ecco uno sguardo più dettagliato:
Sistema Immutabile: I Snapshot di Sistema Sigillati rendono il volume di sistema macOS "immutabile", il che significa che non può essere modificato. Ciò impedisce qualsiasi modifica non autorizzata o accidentale al sistema che potrebbe compromettere la sicurezza o la stabilità del sistema.
Aggiornamenti del Software di Sistema: Quando si installano 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 al snapshot precedente se qualcosa va storto durante l'aggiornamento.
Separazione dei Dati: In congiunzione con il concetto di separazione dei volumi Dati e Sistema introdotto in macOS Catalina, la funzionalità Snapshot di Sistema Sigillati garantisce che tutti i dati e le impostazioni siano memorizzati su un volume "Dati" separato. Questa separazione rende i dati indipendenti dal sistema, semplificando il processo di aggiornamento del sistema e migliorando la sicurezza del sistema.
Ricorda che questi snapshot sono gestiti automaticamente da macOS e non occupano spazio aggiuntivo sul disco, grazie alle capacità di condivisione dello spazio di APFS. È importante notare che questi snapshot sono diversi dai snapshot di Time Machine, che sono backup accessibili dall'utente dell'intero sistema.
Verifica degli Snapshot
Il comando diskutil apfs list elenca i dettagli dei volumi APFS e la loro disposizione:
Nell'output precedente è possibile vedere che le posizioni accessibili dall'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 aggirato 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:
WhiteIntel è un motore di ricerca alimentato dal dark web che offre funzionalità gratuite per verificare se un'azienda o i suoi clienti sono stati compromessi da malware ruba-informazioni.
Il loro obiettivo principale è combattere i sequestri di account e gli attacchi ransomware derivanti da malware che rubano informazioni.
Puoi visitare il loro sito web e provare il loro motore gratuitamente su:
Last updated
