macOS Auto Start
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)
Questa sezione si basa fortemente sulla serie di blog Beyond the good ol' LaunchAgents, l'obiettivo è aggiungere più posizioni di avvio automatico (se possibile), indicare quali tecniche funzionano ancora oggi con l'ultima versione di macOS (13.4) e specificare i permessi necessari.
Qui puoi trovare posizioni di avvio utili per il sandbox bypass che ti consente di eseguire semplicemente qualcosa scrivendolo in un file e aspettando un'azione molto comune, una determinata quantità di tempo o un'azione che di solito puoi eseguire dall'interno di una sandbox senza necessitare di permessi di root.
/Library/LaunchAgents
Trigger: Riavvio
Richiesto root
/Library/LaunchDaemons
Trigger: Riavvio
Richiesto root
/System/Library/LaunchAgents
Trigger: Riavvio
Richiesto root
/System/Library/LaunchDaemons
Trigger: Riavvio
Richiesto root
~/Library/LaunchAgents
Trigger: Rientro
~/Library/LaunchDemons
Trigger: Rientro
Come fatto interessante, launchd ha un elenco di proprietà incorporato nella sezione Mach-o __Text.__config che contiene altri servizi ben noti che launchd deve avviare. Inoltre, questi servizi possono contenere RequireSuccess, RequireRun e RebootOnSuccess, il che significa che devono essere eseguiti e completati con successo.
Ovviamente, non può essere modificato a causa della firma del codice.
launchd è il primo processo eseguito dal kernel OX S all'avvio e l'ultimo a terminare allo spegnimento. Dovrebbe sempre avere il PID 1. Questo processo leggerà ed eseguirà le configurazioni indicate nei plists ASEP in:
/Library/LaunchAgents: Agenti per utente installati dall'amministratore
/Library/LaunchDaemons: Demoni a livello di sistema installati dall'amministratore
/System/Library/LaunchAgents: Agenti per utente forniti da Apple.
/System/Library/LaunchDaemons: Demoni a livello di sistema forniti da Apple.
Quando un utente accede, i plists situati in /Users/$USER/Library/LaunchAgents e /Users/$USER/Library/LaunchDemons vengono avviati con i permessi degli utenti connessi.
La principale differenza tra agenti e demoni è che gli agenti vengono caricati quando l'utente accede e i demoni vengono caricati all'avvio del sistema (poiché ci sono servizi come ssh che devono essere eseguiti prima che qualsiasi utente acceda al sistema). Inoltre, gli agenti possono utilizzare l'interfaccia grafica mentre i demoni devono essere eseguiti in background.
Ci sono casi in cui un agente deve essere eseguito prima che l'utente effettui il login, questi sono chiamati PreLoginAgents. Ad esempio, questo è utile per fornire tecnologia assistiva al login. Possono essere trovati anche in /Library/LaunchAgents (vedi qui un esempio).
Nuovi file di configurazione Daemons o Agents saranno caricati dopo il prossimo riavvio o usando launchctl load <target.plist> È anche possibile caricare file .plist senza quell'estensione con launchctl -F <file> (tuttavia quei file plist non verranno caricati automaticamente dopo il riavvio).
È anche possibile scaricare con launchctl unload <target.plist> (il processo indicato da esso sarà terminato),
Per assicurarsi che non ci sia niente (come un override) che impedisca a un Agente o Daemon di funzionare eseguire: sudo launchctl load -w /System/Library/LaunchDaemos/com.apple.smdb.plist
Elenca tutti gli agenti e i demoni caricati dall'utente corrente:
Se un plist è di proprietà di un utente, anche se si trova in una cartella di sistema daemon, il compito verrà eseguito come utente e non come root. Questo può prevenire alcuni attacchi di escalation dei privilegi.
launchd è il primo processo in modalità utente che viene avviato dal kernel. L'avvio del processo deve essere riuscito e non può uscire o bloccarsi. È anche protetto contro alcuni segnali di terminazione.
Una delle prime cose che launchd farebbe è avviare tutti i daemon come:
Daemon di timer basati sul tempo da eseguire:
atd (com.apple.atrun.plist): Ha un StartInterval di 30min
crond (com.apple.systemstats.daily.plist): Ha StartCalendarInterval per avviarsi alle 00:15
Daemon di rete come:
org.cups.cups-lpd: Ascolta in TCP (SockType: stream) con SockServiceName: printer
SockServiceName deve essere o una porta o un servizio da /etc/services
com.apple.xscertd.plist: Ascolta in TCP sulla porta 1640
Daemon di percorso che vengono eseguiti quando un percorso specificato cambia:
com.apple.postfix.master: Controlla il percorso /etc/postfix/aliases
Daemon di notifiche IOKit:
com.apple.xartstorageremoted: "com.apple.iokit.matching" => { "com.apple.device-attach" => { "IOMatchLaunchStream" => 1 ...
Porta Mach:
com.apple.xscertd-helper.plist: Indica nell'entry MachServices il nome com.apple.xscertd.helper
UserEventAgent:
Questo è diverso dal precedente. Fa sì che launchd avvii app in risposta a eventi specifici. Tuttavia, in questo caso, il binario principale coinvolto non è launchd ma /usr/libexec/UserEventAgent. Carica plugin dalla cartella SIP riservata /System/Library/UserEventPlugins/ dove ogni plugin indica il suo inizializzatore nella chiave XPCEventModuleInitializer o, nel caso di plugin più vecchi, nel dizionario CFPluginFactories sotto la chiave FB86416D-6164-2070-726F-70735C216EC0 del suo Info.plist.
Writeup: https://theevilbit.github.io/beyond/beyond_0001/ Writeup (xterm): https://theevilbit.github.io/beyond/beyond_0018/
Utile per bypassare il sandbox: ✅
Bypass TCC: ✅
Ma è necessario trovare un'app con un bypass TCC che esegue una shell che carica questi file
~/.zshrc, ~/.zlogin, ~/.zshenv.zwc, ~/.zshenv, ~/.zprofile
Attivatore: Apri un terminale con zsh
/etc/zshenv, /etc/zprofile, /etc/zshrc, /etc/zlogin
Attivatore: Apri un terminale con zsh
Richiesta di root
~/.zlogout
Attivatore: Esci da un terminale con zsh
/etc/zlogout
Attivatore: Esci da un terminale con zsh
Richiesta di root
Potenzialmente di più in: man zsh
~/.bashrc
Attivatore: Apri un terminale con bash
/etc/profile (non ha funzionato)
~/.profile (non ha funzionato)
~/.xinitrc, ~/.xserverrc, /opt/X11/etc/X11/xinit/xinitrc.d/
Attivatore: Ci si aspetta che si attivi con xterm, ma non è installato e anche dopo l'installazione viene generato questo errore: xterm: DISPLAY is not set
Quando si avvia un ambiente shell come zsh o bash, vengono eseguiti determinati file di avvio. macOS attualmente utilizza /bin/zsh come shell predefinita. Questa shell viene automaticamente accessibile quando viene avviata l'applicazione Terminal o quando un dispositivo viene accesso tramite SSH. Sebbene bash e sh siano presenti anche in macOS, devono essere esplicitamente invocati per essere utilizzati.
La pagina man di zsh, che possiamo leggere con man zsh, ha una lunga descrizione dei file di avvio.
Configurare lo sfruttamento indicato e disconnettersi e riconnettersi o anche riavviare non ha funzionato per me per eseguire l'app. (L'app non veniva eseguita, forse deve essere in esecuzione quando vengono eseguite queste azioni)
Writeup: https://theevilbit.github.io/beyond/beyond_0021/
~/Library/Preferences/ByHost/com.apple.loginwindow.<UUID>.plist
Attivatore: Riavviare le applicazioni riaperte
Tutte le applicazioni da riaprire si trovano all'interno del plist ~/Library/Preferences/ByHost/com.apple.loginwindow.<UUID>.plist
Quindi, per far avviare le applicazioni riaperte dalla tua, devi semplicemente aggiungere la tua app alla lista.
L'UUID può essere trovato elencando quella directory o con ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'
Per controllare le applicazioni che verranno riaperte puoi fare:
Per aggiungere un'applicazione a questo elenco puoi usare:
Utile per bypassare il sandbox: ✅
Bypass TCC: ✅
L'uso del Terminal per avere permessi FDA dell'utente che lo utilizza
~/Library/Preferences/com.apple.Terminal.plist
Trigger: Apri Terminal
In ~/Library/Preferences sono memorizzate le preferenze dell'utente nelle Applicazioni. Alcune di queste preferenze possono contenere una configurazione per eseguire altre applicazioni/script.
Ad esempio, il Terminal può eseguire un comando all'avvio:
Questa configurazione è riflessa nel file ~/Library/Preferences/com.apple.Terminal.plist in questo modo:
Quindi, se il plist delle preferenze del terminale nel sistema può essere sovrascritto, la funzionalità open può essere utilizzata per aprire il terminale e quel comando verrà eseguito.
Puoi aggiungere questo dalla cli con:
Utile per bypassare il sandbox: ✅
Bypass TCC: ✅
Uso del Terminal per avere permessi FDA dell'utente che lo utilizza
Ovunque
Attivatore: Apri Terminale
Se crei uno .terminal script e lo apri, l'applicazione Terminale verrà automaticamente invocata per eseguire i comandi indicati lì. Se l'app Terminale ha alcuni privilegi speciali (come TCC), il tuo comando verrà eseguito con quei privilegi speciali.
Provalo con:
You could also use the extensions .command, .tool, with regular shell scripts content and they will be also opened by Terminal.
Se il terminale ha Accesso Completo al Disco, sarà in grado di completare quell'azione (nota che il comando eseguito sarà visibile in una finestra del terminale).
Writeup: https://theevilbit.github.io/beyond/beyond_0013/ Writeup: https://posts.specterops.io/audio-unit-plug-ins-896d3434a882
/Library/Audio/Plug-Ins/HAL
Richiesta di root
Trigger: Riavvia coreaudiod o il computer
/Library/Audio/Plug-ins/Components
Richiesta di root
Trigger: Riavvia coreaudiod o il computer
~/Library/Audio/Plug-ins/Components
Trigger: Riavvia coreaudiod o il computer
/System/Library/Components
Richiesta di root
Trigger: Riavvia coreaudiod o il computer
Secondo i precedenti writeup è possibile compilare alcuni audio plugins e farli caricare.
Writeup: https://theevilbit.github.io/beyond/beyond_0028/
/System/Library/QuickLook
/Library/QuickLook
~/Library/QuickLook
/Applications/AppNameHere/Contents/Library/QuickLook/
~/Applications/AppNameHere/Contents/Library/QuickLook/
I plugin QuickLook possono essere eseguiti quando attivi l'anteprima di un file (premi la barra spaziatrice con il file selezionato in Finder) e un plugin che supporta quel tipo di file è installato.
È possibile compilare il proprio plugin QuickLook, posizionarlo in una delle posizioni precedenti per caricarlo e poi andare a un file supportato e premere spazio per attivarlo.
Questo non ha funzionato per me, né con il LoginHook dell'utente né con il LogoutHook di root
Writeup: https://theevilbit.github.io/beyond/beyond_0022/
Devi essere in grado di eseguire qualcosa come defaults write com.apple.loginwindow LoginHook /Users/$USER/hook.sh
Locato in ~/Library/Preferences/com.apple.loginwindow.plist
Sono deprecati ma possono essere utilizzati per eseguire comandi quando un utente accede.
Questa impostazione è memorizzata in /Users/$USER/Library/Preferences/com.apple.loginwindow.plist
Per eliminarlo:
L'utente root è memorizzato in /private/var/root/Library/Preferences/com.apple.loginwindow.plist
Qui puoi trovare le posizioni di avvio utili per il bypass del sandbox che ti consente di eseguire semplicemente qualcosa scrivendolo in un file e aspettandoti condizioni non super comuni come specifici programmi installati, azioni di utenti "non comuni" o ambienti.
Writeup: https://theevilbit.github.io/beyond/beyond_0004/
Utile per bypassare il sandbox: ✅
Tuttavia, devi essere in grado di eseguire il binario crontab
O essere root
Bypass TCC: 🔴
/usr/lib/cron/tabs/, /private/var/at/tabs, /private/var/at/jobs, /etc/periodic/
È richiesto root per l'accesso diretto in scrittura. Non è richiesto root se puoi eseguire crontab <file>
Attivatore: Dipende dal lavoro cron
Elenca i lavori cron dell'utente corrente con:
Puoi anche vedere tutti i cron job degli utenti in /usr/lib/cron/tabs/ e /var/at/tabs/ (richiede root).
In MacOS si possono trovare diverse cartelle che eseguono script con certa frequenza in:
Lì puoi trovare i cron jobs regolari, i at jobs (non molto usati) e i periodic jobs (principalmente usati per pulire i file temporanei). I lavori periodici giornalieri possono essere eseguiti, ad esempio, con: periodic daily.
Per aggiungere un user cronjob programmaticamente è possibile utilizzare:
Writeup: https://theevilbit.github.io/beyond/beyond_0002/
~/Library/Application Support/iTerm2/Scripts/AutoLaunch
Trigger: Apri iTerm
~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt
Trigger: Apri iTerm
~/Library/Preferences/com.googlecode.iterm2.plist
Trigger: Apri iTerm
Gli script memorizzati in ~/Library/Application Support/iTerm2/Scripts/AutoLaunch verranno eseguiti. Ad esempio:
o:
Lo script ~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt verrà eseguito anche:
Le preferenze di iTerm2 situate in ~/Library/Preferences/com.googlecode.iterm2.plist possono indicare un comando da eseguire quando il terminale iTerm2 viene aperto.
Questa impostazione può essere configurata nelle impostazioni di iTerm2:
E il comando è riflesso nelle preferenze:
Puoi impostare il comando da eseguire con:
È altamente probabile che ci siano altri modi per abusare delle preferenze di iTerm2 per eseguire comandi arbitrari.
Writeup: https://theevilbit.github.io/beyond/beyond_0007/
Utile per bypassare il sandbox: ✅
Ma xbar deve essere installato
Bypass TCC: ✅
Richiede permessi di Accessibilità
~/Library/Application\ Support/xbar/plugins/
Attivazione: Una volta che xbar è eseguito
Se il popolare programma xbar è installato, è possibile scrivere uno script shell in ~/Library/Application\ Support/xbar/plugins/ che verrà eseguito quando xbar viene avviato:
Writeup: https://theevilbit.github.io/beyond/beyond_0008/
Utile per bypassare il sandbox: ✅
Ma Hammerspoon deve essere installato
Bypass TCC: ✅
Richiede permessi di Accessibilità
~/.hammerspoon/init.lua
Trigger: Una volta eseguito hammerspoon
Hammerspoon funge da piattaforma di automazione per macOS, sfruttando il linguaggio di scripting LUA per le sue operazioni. In particolare, supporta l'integrazione di codice AppleScript completo e l'esecuzione di script shell, migliorando significativamente le sue capacità di scripting.
L'app cerca un singolo file, ~/.hammerspoon/init.lua, e quando avviata, lo script verrà eseguito.
Utile per bypassare il sandbox: ✅
Ma BetterTouchTool deve essere installato
Bypass TCC: ✅
Richiede permessi di Automazione-Scorciatoie e Accessibilità
~/Library/Application Support/BetterTouchTool/*
Questo strumento consente di indicare applicazioni o script da eseguire quando vengono premuti alcuni scorciatoie. Un attaccante potrebbe essere in grado di configurare il proprio scorciatoia e azione da eseguire nel database per far eseguire codice arbitrario (uno scorciatoia potrebbe essere semplicemente premere un tasto).
Utile per bypassare il sandbox: ✅
Ma Alfred deve essere installato
Bypass TCC: ✅
Richiede permessi di Automazione, Accessibilità e persino accesso a Disco Completo
???
Consente di creare flussi di lavoro che possono eseguire codice quando vengono soddisfatte determinate condizioni. Potenzialmente è possibile per un attaccante creare un file di flusso di lavoro e far caricare ad Alfred (è necessario pagare la versione premium per utilizzare i flussi di lavoro).
Writeup: https://theevilbit.github.io/beyond/beyond_0006/
Utile per bypassare il sandbox: ✅
Ma ssh deve essere abilitato e utilizzato
Bypass TCC: ✅
L'uso di SSH richiede accesso FDA
~/.ssh/rc
Attivatore: Accesso tramite ssh
/etc/ssh/sshrc
Richiesta di root
Attivatore: Accesso tramite ssh
Per attivare ssh è necessario l'accesso a Disco Completo:
Per impostazione predefinita, a meno che PermitUserRC no in /etc/ssh/sshd_config, quando un utente effettua il login via SSH gli script /etc/ssh/sshrc e ~/.ssh/rc verranno eseguiti.
Writeup: https://theevilbit.github.io/beyond/beyond_0003/
~/Library/Application Support/com.apple.backgroundtaskmanagementagent
Attivatore: Login
Payload di sfruttamento memorizzato chiamando osascript
/var/db/com.apple.xpc.launchd/loginitems.501.plist
Attivatore: Login
Richiesta di root
In Preferenze di Sistema -> Utenti e Gruppi -> Elementi di Login puoi trovare elementi da eseguire quando l'utente effettua il login. È possibile elencarli, aggiungere e rimuovere dalla riga di comando:
Questi elementi sono memorizzati nel file ~/Library/Application Support/com.apple.backgroundtaskmanagementagent
Gli elementi di accesso possono anche essere indicati utilizzando l'API SMLoginItemSetEnabled che memorizzerà la configurazione in /var/db/com.apple.xpc.launchd/loginitems.501.plist
(Controlla la sezione precedente sugli elementi di accesso, questa è un'estensione)
Se memorizzi un file ZIP come elemento di accesso, l'Utility di archiviazione lo aprirà e se lo zip era, ad esempio, memorizzato in ~/Library e conteneva la cartella LaunchAgents/file.plist con una backdoor, quella cartella verrà creata (non lo è per impostazione predefinita) e il plist verrà aggiunto in modo che la prossima volta che l'utente accede di nuovo, la backdoor indicata nel plist verrà eseguita.
Un'altra opzione sarebbe creare i file .bash_profile e .zshenv all'interno della HOME dell'utente, quindi se la cartella LaunchAgents esiste già, questa tecnica funzionerebbe comunque.
Scrittura: https://theevilbit.github.io/beyond/beyond_0014/
Devi eseguire at e deve essere abilitato
I compiti at sono progettati per programmare compiti una tantum da eseguire in determinati momenti. A differenza dei cron job, i compiti at vengono automaticamente rimossi dopo l'esecuzione. È fondamentale notare che questi compiti sono persistenti attraverso i riavvii del sistema, contrassegnandoli come potenziali preoccupazioni di sicurezza in determinate condizioni.
Per impostazione predefinita sono disabilitati ma l'utente root può abilitarli con:
Questo creerà un file in 1 ora:
Controlla la coda dei lavori usando atq:
Sopra possiamo vedere due lavori programmati. Possiamo stampare i dettagli del lavoro usando at -c JOBNUMBER
Se i compiti AT non sono abilitati, i compiti creati non verranno eseguiti.
I file di lavoro possono essere trovati in /private/var/at/jobs/
Il nome del file contiene la coda, il numero del lavoro e l'orario programmato per l'esecuzione. Ad esempio, diamo un'occhiata a a0001a019bdcd2.
a - questa è la coda
0001a - numero del lavoro in esadecimale, 0x1a = 26
019bdcd2 - tempo in esadecimale. Rappresenta i minuti trascorsi dall'epoca. 0x019bdcd2 è 26991826 in decimale. Se lo moltiplichiamo per 60 otteniamo 1619509560, che è GMT: 27 aprile 2021, martedì 7:46:00.
Se stampiamo il file del lavoro, scopriamo che contiene le stesse informazioni ottenute utilizzando at -c.
Writeup: https://theevilbit.github.io/beyond/beyond_0024/ Writeup: https://posts.specterops.io/folder-actions-for-persistence-on-macos-8923f222343d
Utile per bypassare il sandbox: ✅
Ma è necessario poter chiamare osascript con argomenti per contattare System Events per poter configurare le Azioni della cartella
Bypass TCC: 🟠
Ha alcune autorizzazioni TCC di base come Desktop, Documenti e Download
/Library/Scripts/Folder Action Scripts
Richiesta di root
Attivazione: Accesso alla cartella specificata
~/Library/Scripts/Folder Action Scripts
Attivazione: Accesso alla cartella specificata
Le Azioni della cartella sono script attivati automaticamente da modifiche in una cartella, come l'aggiunta, la rimozione di elementi o altre azioni come l'apertura o il ridimensionamento della finestra della cartella. Queste azioni possono essere utilizzate per vari compiti e possono essere attivate in modi diversi, come utilizzando l'interfaccia Finder o comandi del terminale.
Per impostare le Azioni della cartella, hai opzioni come:
Creare un flusso di lavoro per le Azioni della cartella con Automator e installarlo come servizio.
Allegare uno script manualmente tramite la Configurazione delle Azioni della cartella nel menu contestuale di una cartella.
Utilizzare OSAScript per inviare messaggi Apple Event a System Events.app per impostare programmaticamente un'Azione della cartella.
Questo metodo è particolarmente utile per incorporare l'azione nel sistema, offrendo un livello di persistenza.
Il seguente script è un esempio di ciò che può essere eseguito da un'Azione della cartella:
Per rendere lo script sopra utilizzabile da Folder Actions, compilarlo utilizzando:
Dopo che lo script è stato compilato, imposta le Azioni della Cartella eseguendo lo script qui sotto. Questo script abiliterà le Azioni della Cartella globalmente e attaccherà specificamente lo script precedentemente compilato alla cartella Desktop.
Esegui lo script di configurazione con:
Questo è il modo per implementare questa persistenza tramite GUI:
Questo è lo script che verrà eseguito:
Compilalo con: osacompile -l JavaScript -o folder.scpt source.js
Spostalo in:
Poi, apri l'app Folder Actions Setup, seleziona la cartella che desideri monitorare e seleziona nel tuo caso folder.scpt (nel mio caso l'ho chiamata output2.scp):
Ora, se apri quella cartella con Finder, il tuo script verrà eseguito.
Questa configurazione è stata memorizzata nel plist situato in ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist in formato base64.
Ora, proviamo a preparare questa persistenza senza accesso GUI:
Copia ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist in /tmp per eseguire il backup:
cp ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist /tmp
Rimuovi le Azioni della Cartella che hai appena impostato:
Ora che abbiamo un ambiente vuoto
Copia il file di backup: cp /tmp/com.apple.FolderActionsDispatcher.plist ~/Library/Preferences/
Apri l'app Folder Actions Setup.app per consumare questa configurazione: open "/System/Library/CoreServices/Applications/Folder Actions Setup.app/"
E questo non ha funzionato per me, ma queste sono le istruzioni del documento:(
Documento: https://theevilbit.github.io/beyond/beyond_0027/
Utile per bypassare il sandbox: ✅
Ma devi avere installato un'applicazione malevola all'interno del sistema
Bypass TCC: 🔴
~/Library/Preferences/com.apple.dock.plist
Attivatore: Quando l'utente clicca sull'app all'interno del dock
Tutte le applicazioni che appaiono nel Dock sono specificate all'interno del plist: ~/Library/Preferences/com.apple.dock.plist
È possibile aggiungere un'applicazione semplicemente con:
Utilizzando un po' di ingegneria sociale potresti fingere ad esempio Google Chrome all'interno del dock ed eseguire effettivamente il tuo script:
Writeup: https://theevilbit.github.io/beyond/beyond_0017
Utile per bypassare la sandbox: 🟠
Deve avvenire un'azione molto specifica
Finirai in un'altra sandbox
Bypass TCC: 🔴
/Library/ColorPickers
Richiesta di root
Trigger: Usa il selettore di colori
~/Library/ColorPickers
Trigger: Usa il selettore di colori
Compila un selettore di colori bundle con il tuo codice (puoi usare questo ad esempio) e aggiungi un costruttore (come nella sezione Salvaschermo) e copia il bundle in ~/Library/ColorPickers.
Poi, quando il selettore di colori viene attivato, il tuo codice dovrebbe essere eseguito.
Nota che il binario che carica la tua libreria ha una sandbox molto restrittiva: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/LegacyExternalColorPickerService-x86_64.xpc/Contents/MacOS/LegacyExternalColorPickerService-x86_64
Writeup: https://theevilbit.github.io/beyond/beyond_0026/ Writeup: https://objective-see.org/blog/blog_0x11.html
Utile per bypassare il sandbox: No, perché è necessario eseguire la propria app
Bypass TCC: ???
Un'app specifica
Un esempio di applicazione con un'estensione Finder Sync può essere trovato qui.
Le applicazioni possono avere Finder Sync Extensions. Questa estensione andrà all'interno di un'applicazione che verrà eseguita. Inoltre, affinché l'estensione possa eseguire il proprio codice, deve essere firmata con un valido certificato di sviluppatore Apple, deve essere sandboxed (anche se potrebbero essere aggiunte eccezioni rilassate) e deve essere registrata con qualcosa come:
Writeup: https://theevilbit.github.io/beyond/beyond_0016/ Writeup: https://posts.specterops.io/saving-your-access-d562bf5bf90b
/System/Library/Screen Savers
Richiesta di root
Trigger: Seleziona il salvaschermo
/Library/Screen Savers
Richiesta di root
Trigger: Seleziona il salvaschermo
~/Library/Screen Savers
Trigger: Seleziona il salvaschermo
Crea un nuovo progetto in Xcode e seleziona il template per generare un nuovo Screen Saver. Poi, aggiungi il tuo codice, ad esempio il seguente codice per generare log.
Build it, and copy the .saver bundle to ~/Library/Screen Savers. Then, open the Screen Saver GUI and it you just click on it, it should generate a lot of logs:
Nota che all'interno dei diritti del binario che carica questo codice (/System/Library/Frameworks/ScreenSaver.framework/PlugIns/legacyScreenSaver.appex/Contents/MacOS/legacyScreenSaver) puoi trovare com.apple.security.app-sandbox quindi sarai all'interno del comune sandbox dell'applicazione.
Saver code:
writeup: https://theevilbit.github.io/beyond/beyond_0011/
Utile per bypassare il sandbox: 🟠
Ma finirai in un'applicazione sandbox
Bypass TCC: 🔴
Il sandbox sembra molto limitato
~/Library/Spotlight/
Trigger: Viene creato un nuovo file con un'estensione gestita dal plugin spotlight.
/Library/Spotlight/
Trigger: Viene creato un nuovo file con un'estensione gestita dal plugin spotlight.
Richiesta root
/System/Library/Spotlight/
Trigger: Viene creato un nuovo file con un'estensione gestita dal plugin spotlight.
Richiesta root
Some.app/Contents/Library/Spotlight/
Trigger: Viene creato un nuovo file con un'estensione gestita dal plugin spotlight.
Nuova app richiesta
Spotlight è la funzione di ricerca integrata di macOS, progettata per fornire agli utenti accesso rapido e completo ai dati sui loro computer. Per facilitare questa capacità di ricerca rapida, Spotlight mantiene un database proprietario e crea un indice analizzando la maggior parte dei file, consentendo ricerche rapide sia attraverso i nomi dei file che il loro contenuto.
Il meccanismo sottostante di Spotlight coinvolge un processo centrale chiamato 'mds', che sta per 'metadata server'. Questo processo orchestra l'intero servizio Spotlight. A complemento di questo, ci sono più demoni 'mdworker' che eseguono una varietà di compiti di manutenzione, come indicizzare diversi tipi di file (ps -ef | grep mdworker). Questi compiti sono resi possibili attraverso i plugin importatori di Spotlight, o ".mdimporter bundles", che consentono a Spotlight di comprendere e indicizzare contenuti attraverso una vasta gamma di formati di file.
I plugin o .mdimporter bundles si trovano nei luoghi menzionati in precedenza e se appare un nuovo bundle viene caricato in un minuto (non è necessario riavviare alcun servizio). Questi bundle devono indicare quali tipi di file e estensioni possono gestire, in questo modo, Spotlight li utilizzerà quando viene creato un nuovo file con l'estensione indicata.
È possibile trovare tutti gli mdimporters caricati eseguendo:
E per esempio /Library/Spotlight/iBooksAuthor.mdimporter è usato per analizzare questi tipi di file (estensioni .iba e .book tra gli altri):
Se controlli il Plist di altri mdimporter, potresti non trovare l'entry UTTypeConformsTo. Questo perché è un Identificatore di Tipo Uniforme incorporato (UTI) e non è necessario specificare le estensioni.
Inoltre, i plugin di sistema predefiniti hanno sempre la precedenza, quindi un attaccante può accedere solo a file che non sono altrimenti indicizzati dai mdimporters di Apple.
Per creare il tuo importatore, puoi iniziare con questo progetto: https://github.com/megrimm/pd-spotlight-importer e poi cambiare il nome, il CFBundleDocumentTypes e aggiungere UTImportedTypeDeclarations in modo che supporti l'estensione che desideri supportare e rifletterli in schema.xml.
Poi cambia il codice della funzione GetMetadataForFile per eseguire il tuo payload quando viene creato un file con l'estensione elaborata.
Infine compila e copia il tuo nuovo .mdimporter in una delle tre posizioni precedenti e puoi controllare se viene caricato monitorando i log o controllando mdimport -L.
Non sembra che questo funzioni più.
Scrittura: https://theevilbit.github.io/beyond/beyond_0009/
/System/Library/PreferencePanes
/Library/PreferencePanes
~/Library/PreferencePanes
Non sembra che questo funzioni più.
Qui puoi trovare le posizioni di avvio utili per il bypass del sandbox che ti consente di eseguire semplicemente qualcosa scrivendolo in un file essendo root e/o richiedendo altre condizioni strane.
Scrittura: https://theevilbit.github.io/beyond/beyond_0019/
/etc/periodic/daily, /etc/periodic/weekly, /etc/periodic/monthly, /usr/local/etc/periodic
Richiesta di root
Attivazione: Quando arriva il momento
/etc/daily.local, /etc/weekly.local o /etc/monthly.local
Richiesta di root
Attivazione: Quando arriva il momento
Gli script periodici (/etc/periodic) vengono eseguiti a causa dei lanciatori di demoni configurati in /System/Library/LaunchDaemons/com.apple.periodic*. Nota che gli script memorizzati in /etc/periodic/ vengono eseguiti come proprietario del file, quindi questo non funzionerà per un potenziale escalation di privilegi.
Ci sono altri script periodici che verranno eseguiti indicati in /etc/defaults/periodic.conf:
Se riesci a scrivere uno dei file /etc/daily.local, /etc/weekly.local o /etc/monthly.local, verrà eseguito prima o poi.
Nota che lo script periodico verrà eseguito come il proprietario dello script. Quindi, se un utente normale possiede lo script, verrà eseguito come quell'utente (questo potrebbe prevenire attacchi di escalation dei privilegi).
Scrittura: Linux Hacktricks PAM Scrittura: https://theevilbit.github.io/beyond/beyond_0005/
Root sempre richiesto
Poiché PAM è più focalizzato su persistenza e malware che su una facile esecuzione all'interno di macOS, questo blog non fornirà una spiegazione dettagliata, leggi le scritture per comprendere meglio questa tecnica.
Controlla i moduli PAM con:
Una tecnica di persistenza/escallation dei privilegi che sfrutta PAM è semplice come modificare il modulo /etc/pam.d/sudo aggiungendo all'inizio la riga:
Quindi sembrerà qualcosa del genere:
E quindi qualsiasi tentativo di utilizzare sudo funzionerà.
Nota che questa directory è protetta da TCC, quindi è altamente probabile che l'utente riceva un prompt che chiede l'accesso.
Un altro bel esempio è su, dove puoi vedere che è anche possibile fornire parametri ai moduli PAM (e potresti anche backdoor questo file):
Writeup: https://theevilbit.github.io/beyond/beyond_0028/ Writeup: https://posts.specterops.io/persistent-credential-theft-with-authorization-plugins-d17b34719d65
Utile per bypassare il sandbox: 🟠
Ma è necessario essere root e fare configurazioni extra
Bypass TCC: ???
/Library/Security/SecurityAgentPlugins/
Richiesta root
È anche necessario configurare il database di autorizzazione per utilizzare il plugin
Puoi creare un plugin di autorizzazione che verrà eseguito quando un utente accede per mantenere la persistenza. Per ulteriori informazioni su come crearne uno di questi plugin, controlla i writeup precedenti (e fai attenzione, uno scritto male può bloccarti e dovrai pulire il tuo mac dalla modalità di recupero).
Sposta il pacchetto nella posizione da caricare:
Infine, aggiungi la regola per caricare questo Plugin:
Il evaluate-mechanisms dirà al framework di autorizzazione che avrà bisogno di chiamare un meccanismo esterno per l'autorizzazione. Inoltre, privileged farà sì che venga eseguito da root.
Attivalo con:
E poi il gruppo staff dovrebbe avere accesso sudo (leggi /etc/sudoers per confermare).
Writeup: https://theevilbit.github.io/beyond/beyond_0030/
/private/etc/man.conf
Richiesta root
/private/etc/man.conf: Ogni volta che viene usato man
Il file di configurazione /private/etc/man.conf indica il binario/script da utilizzare quando si aprono i file di documentazione man. Quindi il percorso dell'eseguibile potrebbe essere modificato in modo che ogni volta che l'utente usa man per leggere della documentazione venga eseguita una backdoor.
Ad esempio impostato in /private/etc/man.conf:
E poi crea /tmp/view come:
Writeup: https://theevilbit.github.io/beyond/beyond_0023/
Utile per bypassare la sandbox: 🟠
Ma è necessario essere root e apache deve essere in esecuzione
Bypass TCC: 🔴
Httpd non ha diritti
/etc/apache2/httpd.conf
Richiesta root
Attivazione: Quando Apache2 viene avviato
Puoi indicare in /etc/apache2/httpd.conf di caricare un modulo aggiungendo una riga come:
In questo modo, i tuoi moduli compilati verranno caricati da Apache. L'unica cosa è che devi firmarlo con un certificato Apple valido, oppure devi aggiungere un nuovo certificato di fiducia nel sistema e firmarlo con esso.
Quindi, se necessario, per assicurarti che il server venga avviato, potresti eseguire:
Esempio di codice per il Dylb:
Writeup: https://theevilbit.github.io/beyond/beyond_0031/
Utile per bypassare il sandbox: 🟠
Ma hai bisogno di essere root, auditd deve essere in esecuzione e causare un avviso
Bypass TCC: 🔴
/etc/security/audit_warn
Richiesta root
Trigger: Quando auditd rileva un avviso
Ogni volta che auditd rileva un avviso, lo script /etc/security/audit_warn viene eseguito. Quindi potresti aggiungere il tuo payload su di esso.
Puoi forzare un avviso con sudo audit -n.
Questo è deprecato, quindi non dovrebbe essere trovato nulla in quelle directory.
L'StartupItem è una directory che dovrebbe essere posizionata all'interno di /Library/StartupItems/ o /System/Library/StartupItems/. Una volta che questa directory è stabilita, deve contenere due file specifici:
Uno script rc: Uno script shell eseguito all'avvio.
Un file plist, specificamente chiamato StartupParameters.plist, che contiene varie impostazioni di configurazione.
Assicurati che sia lo script rc che il file StartupParameters.plist siano correttamente posizionati all'interno della directory StartupItem affinché il processo di avvio possa riconoscerli e utilizzarli.
Non riesco a trovare questo componente nel mio macOS, quindi per ulteriori informazioni controlla il writeup
Writeup: https://theevilbit.github.io/beyond/beyond_0023/
Introdotto da Apple, emond è un meccanismo di registrazione che sembra essere poco sviluppato o possibilmente abbandonato, eppure rimane accessibile. Sebbene non sia particolarmente utile per un amministratore Mac, questo servizio oscuro potrebbe servire come un metodo di persistenza sottile per gli attori delle minacce, probabilmente inosservato dalla maggior parte degli amministratori macOS.
Per coloro che sono a conoscenza della sua esistenza, identificare qualsiasi uso malevolo di emond è semplice. Il LaunchDaemon di sistema per questo servizio cerca script da eseguire in una singola directory. Per ispezionare questo, si può utilizzare il seguente comando:
Writeup: https://theevilbit.github.io/beyond/beyond_0018/
/opt/X11/etc/X11/xinit/privileged_startx.d
Richiesta di root
Trigger: Con XQuartz
XQuartz non è più installato in macOS, quindi se vuoi ulteriori informazioni controlla il writeup.
È così complicato installare kext anche come root che non lo considererò per sfuggire alle sandbox o anche per la persistenza (a meno che tu non abbia un exploit)
Per installare un KEXT come elemento di avvio, deve essere installato in una delle seguenti posizioni:
/System/Library/Extensions
File KEXT integrati nel sistema operativo OS X.
/Library/Extensions
File KEXT installati da software di terze parti
Puoi elencare i file kext attualmente caricati con:
Per ulteriori informazioni su estensioni del kernel controlla questa sezione.
Scrittura: https://theevilbit.github.io/beyond/beyond_0029/
/usr/local/bin/amstoold
Richiesta di root
A quanto pare il plist di /System/Library/LaunchAgents/com.apple.amstoold.plist stava usando questo binario mentre esponeva un servizio XPC... il problema è che il binario non esisteva, quindi potevi posizionare qualcosa lì e quando il servizio XPC veniva chiamato, il tuo binario sarebbe stato chiamato.
Non riesco più a trovare questo nel mio macOS.
Scrittura: https://theevilbit.github.io/beyond/beyond_0015/
/Library/Preferences/Xsan/.xsanrc
Richiesta di root
Attivazione: Quando il servizio viene eseguito (raramente)
A quanto pare non è molto comune eseguire questo script e non sono riuscito nemmeno a trovarlo nel mio macOS, quindi se vuoi ulteriori informazioni controlla la scrittura.
Questo non funziona nelle versioni moderne di MacOS
È anche possibile posizionare qui comandi che verranno eseguiti all'avvio. Esempio di script rc.common regolare:
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
