macOS Office Sandbox Bypasses
Bypass del Sandbox de Word a través de Launch Agents
La aplicación utiliza un Sandbox personalizado usando el derecho com.apple.security.temporary-exception.sbpl
y este sandbox personalizado permite escribir archivos en cualquier lugar siempre que el nombre del archivo comience con ~$
: (require-any (require-all (vnode-type REGULAR-FILE) (regex #"(^|/)~$[^/]+$")))
Por lo tanto, escapar fue tan fácil como escribir un plist
LaunchAgent en ~/Library/LaunchAgents/~$escape.plist
.
Revisa el informe original aquí.
Bypass del Sandbox de Word a través de Login Items y zip
Recuerda que desde el primer escape, Word puede escribir archivos arbitrarios cuyos nombres comiencen con ~$
, aunque después del parche de la vulnerabilidad anterior no era posible escribir en /Library/Application Scripts
o en /Library/LaunchAgents
.
Se descubrió que desde dentro del sandbox es posible crear un Login Item (aplicaciones que se ejecutarán cuando el usuario inicie sesión). Sin embargo, estas aplicaciones no se ejecutarán a menos que estén notarizadas y no es posible agregar argumentos (por lo que no puedes simplemente ejecutar un shell inverso usando bash
).
Desde el bypass anterior del Sandbox, Microsoft deshabilitó la opción de escribir archivos en ~/Library/LaunchAgents
. Sin embargo, se descubrió que si pones un archivo zip como Login Item, el Archive Utility
simplemente descomprimirá en su ubicación actual. Así que, debido a que por defecto la carpeta LaunchAgents
de ~/Library
no se crea, fue posible comprimir un plist en LaunchAgents/~$escape.plist
y colocar el archivo zip en ~/Library
para que al descomprimirlo alcance el destino de persistencia.
Revisa el informe original aquí.
Bypass del Sandbox de Word a través de Login Items y .zshenv
(Recuerda que desde el primer escape, Word puede escribir archivos arbitrarios cuyos nombres comiencen con ~$
).
Sin embargo, la técnica anterior tenía una limitación, si la carpeta ~/Library/LaunchAgents
existe porque algún otro software la creó, fallaría. Así que se descubrió una cadena diferente de Login Items para esto.
Un atacante podría crear los archivos .bash_profile
y .zshenv
con la carga útil para ejecutar y luego comprimirlos y escribir el zip en la carpeta del usuario de la víctima: ~/~$escape.zip
.
Luego, agregar el archivo zip a los Login Items y luego la aplicación Terminal
. Cuando el usuario vuelva a iniciar sesión, el archivo zip se descomprimiría en los archivos del usuario, sobrescribiendo .bash_profile
y .zshenv
y, por lo tanto, el terminal ejecutará uno de estos archivos (dependiendo de si se usa bash o zsh).
Revisa el informe original aquí.
Bypass del Sandbox de Word con Open y variables de entorno
Desde procesos en sandbox todavía es posible invocar otros procesos usando la utilidad open
. Además, estos procesos se ejecutarán dentro de su propio sandbox.
Se descubrió que la utilidad open tiene la opción --env
para ejecutar una aplicación con variables de entorno específicas. Por lo tanto, fue posible crear el archivo .zshenv
dentro de una carpeta dentro del sandbox y usar open
con --env
configurando la variable HOME
a esa carpeta abriendo esa aplicación Terminal
, que ejecutará el archivo .zshenv
(por alguna razón también fue necesario establecer la variable __OSINSTALL_ENVIROMENT
).
Revisa el informe original aquí.
Bypass del Sandbox de Word con Open y stdin
La utilidad open
también soportaba el parámetro --stdin
(y después del bypass anterior ya no era posible usar --env
).
La cuestión es que incluso si python
estaba firmado por Apple, no ejecutará un script con el atributo quarantine
. Sin embargo, fue posible pasarle un script desde stdin, por lo que no verificará si estaba en cuarentena o no:
Dejar un archivo
~$exploit.py
con comandos de Python arbitrarios.Ejecutar open
–stdin='~$exploit.py' -a Python
, que ejecuta la aplicación Python con nuestro archivo dejado sirviendo como su entrada estándar. Python ejecuta felizmente nuestro código, y dado que es un proceso hijo de launchd, no está sujeto a las reglas del sandbox de Word.
Last updated