macOS Office Sandbox Bypasses
Bypass del Sandbox di Word tramite Launch Agents
L'applicazione utilizza un Sandbox personalizzato utilizzando l'entitlement com.apple.security.temporary-exception.sbpl e questo Sandbox personalizzato consente di scrivere file ovunque purché il nome del file inizi con ~$: (require-any (require-all (vnode-type REGULAR-FILE) (regex #"(^|/)~$[^/]+$")))
Pertanto, l'escape è stato semplice come scrivere un file plist LaunchAgent in ~/Library/LaunchAgents/~$escape.plist.
Controlla il rapporto originale qui.
Bypass del Sandbox di Word tramite Login Items e zip
Ricorda che dal primo escape, Word può scrivere file arbitrari il cui nome inizia con ~$, anche se dopo la patch della vulnerabilità precedente non era possibile scrivere in /Library/Application Scripts o in /Library/LaunchAgents.
È stato scoperto che all'interno del sandbox è possibile creare un Login Item (applicazioni che verranno eseguite quando l'utente accede). Tuttavia, queste app non verranno eseguite a meno che non siano notarizzate e non è possibile aggiungere argomenti (quindi non è possibile eseguire una reverse shell usando bash).
Dal precedente bypass del Sandbox, Microsoft ha disabilitato l'opzione di scrittura dei file in ~/Library/LaunchAgents. Tuttavia, è stato scoperto che se si inserisce un file zip come Login Item, l'Archive Utility lo scompatterà nella sua posizione corrente. Quindi, poiché per impostazione predefinita la cartella LaunchAgents di ~/Library non viene creata, è stato possibile creare un file plist in LaunchAgents/~$escape.plist e posizionare il file zip in ~/Library in modo che, quando viene decompresso, raggiunga la destinazione di persistenza.
Controlla il rapporto originale qui.
Bypass del Sandbox di Word tramite Login Items e .zshenv
(Ricorda che dal primo escape, Word può scrivere file arbitrari il cui nome inizia con ~$).
Tuttavia, la tecnica precedente aveva una limitazione: se la cartella ~/Library/LaunchAgents esiste perché è stata creata da un altro software, il bypass fallirebbe. Quindi è stata scoperta una catena di Login Items diversa per questo caso.
Un attaccante potrebbe creare i file .bash_profile e .zshenv con il payload da eseguire e quindi comprimerli in un file zip e scrivere il file zip nella cartella dell'utente vittima: ~/~$escape.zip.
Successivamente, aggiungi il file zip ai Login Items e quindi all'app Terminal. Quando l'utente effettua nuovamente l'accesso, il file zip verrà decompresso nella cartella dell'utente, sovrascrivendo .bash_profile e `.zshenv e quindi il terminale eseguirà uno di questi file (a seconda se viene utilizzato bash o zsh).
Controlla il rapporto originale qui.
Bypass del Sandbox di Word con Open e variabili di ambiente
Dai processi sandboxed è ancora possibile invocare altri processi utilizzando l'utilità open. Inoltre, questi processi verranno eseguiti all'interno del proprio sandbox.
È stato scoperto che l'utilità open ha l'opzione --env per eseguire un'app con specifiche variabili di ambiente. Pertanto, è stato possibile creare il file .zshenv all'interno di una cartella all'interno del sandbox e utilizzare open con --env impostando la variabile HOME su quella cartella aprendo l'app Terminal, che eseguirà il file .zshenv (per qualche motivo era anche necessario impostare la variabile __OSINSTALL_ENVIROMENT).
Controlla il rapporto originale qui.
Bypass del Sandbox di Word con Open e stdin
L'utilità open supporta anche il parametro --stdin (e dopo il bypass precedente non era più possibile utilizzare --env).
Il punto è che anche se python è firmato da Apple, non eseguirà uno script con l'attributo quarantine. Tuttavia, era possibile passargli uno script da stdin in modo che non controllasse se era stato messo in quarantena o meno:
Crea un file
~$exploit.pycon comandi Python arbitrari.Esegui open
–stdin='~$exploit.py' -a Python, che esegue l'app Python con il nostro file inserito come input standard. Python esegue tranquillamente il nostro codice e poiché è un processo figlio di launchd, non è vincolato alle regole del sandbox di Word.
Last updated