macOS Auto Start
Esta sección se basa en gran medida en la serie de blogs Beyond the good ol' LaunchAgents, el objetivo es agregar más ubicaciones de inicio automático (si es posible), indicar qué técnicas siguen funcionando en la actualidad con la última versión de macOS (13.4) y especificar los permisos necesarios.
Bypass de la Caja de Arena
Aquí puedes encontrar ubicaciones de inicio útiles para bypass de la caja de arena que te permite simplemente ejecutar algo escribiéndolo en un archivo y esperando una acción muy común, una cantidad determinada de tiempo o una acción que normalmente puedes realizar desde dentro de una caja de arena sin necesidad de permisos de root.
Launchd
Ubicaciones
/Library/LaunchAgents
Disparador: Reinicio
Se requiere permisos de root
/Library/LaunchDaemons
Disparador: Reinicio
Se requiere permisos de root
/System/Library/LaunchAgents
Disparador: Reinicio
Se requiere permisos de root
/System/Library/LaunchDaemons
Disparador: Reinicio
Se requiere permisos de root
~/Library/LaunchAgents
Disparador: Volver a iniciar sesión
~/Library/LaunchDemons
Disparador: Volver a iniciar sesión
Como dato interesante, launchd
tiene una lista de propiedades incrustada en la sección Mach-o __Text.__config
que contiene otros servicios conocidos que launchd
debe iniciar. Además, estos servicios pueden contener RequireSuccess
, RequireRun
y RebootOnSuccess
, lo que significa que deben ejecutarse y completarse con éxito.
Por supuesto, no se puede modificar debido a la firma de código.
Descripción y Explotación
launchd
es el primer proceso ejecutado por el kernel de OX S al inicio y el último en finalizar al apagar. Siempre debería tener el PID 1. Este proceso lee y ejecuta las configuraciones indicadas en los plists de ASEP en:
/Library/LaunchAgents
: Agentes por usuario instalados por el administrador/Library/LaunchDaemons
: Demonios de todo el sistema instalados por el administrador/System/Library/LaunchAgents
: Agentes por usuario proporcionados por Apple./System/Library/LaunchDaemons
: Demonios de todo el sistema proporcionados por Apple.
Cuando un usuario inicia sesión, los plists ubicados en /Users/$USER/Library/LaunchAgents
y /Users/$USER/Library/LaunchDemons
se inician con los permisos de los usuarios conectados.
La diferencia principal entre agentes y demonios es que los agentes se cargan cuando el usuario inicia sesión y los demonios se cargan al iniciar el sistema (ya que hay servicios como ssh que necesitan ejecutarse antes de que cualquier usuario acceda al sistema). Además, los agentes pueden usar la interfaz gráfica mientras que los demonios deben ejecutarse en segundo plano.
Hay casos en los que un agente necesita ser ejecutado antes de que el usuario inicie sesión, estos se llaman PreLoginAgents. Por ejemplo, esto es útil para proporcionar tecnología de asistencia en el inicio de sesión. También se pueden encontrar en /Library/LaunchAgents
(ver aquí un ejemplo).
Los nuevos archivos de configuración de Daemons o Agents se cargarán después del próximo reinicio o usando launchctl load <target.plist>
También es posible cargar archivos .plist sin esa extensión con launchctl -F <file>
(sin embargo, esos archivos plist no se cargarán automáticamente después del reinicio).
También es posible descargar con launchctl unload <target.plist>
(el proceso al que apunta será terminado).
Para asegurarse de que no haya nada (como una anulación) impidiendo que un Agente o Daemon se ejecute, ejecute: sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.smdb.plist
Listar todos los agentes y daemons cargados por el usuario actual:
Si un plist es propiedad de un usuario, incluso si está en carpetas de sistema de demonios, la tarea se ejecutará como el usuario y no como root. Esto puede prevenir algunos ataques de escalada de privilegios.
Más información sobre launchd
launchd
es el primer proceso en modo de usuario que se inicia desde el kernel. El inicio del proceso debe ser exitoso y no puede salir ni fallar. Está incluso protegido contra algunas señales de finalización.
Una de las primeras cosas que hará launchd
es iniciar todos los demonios como:
Demonios temporizadores basados en tiempo para ser ejecutados:
atd (
com.apple.atrun.plist
): Tiene unStartInterval
de 30 minutoscrond (
com.apple.systemstats.daily.plist
): TieneStartCalendarInterval
para iniciar a las 00:15
Demonios de red como:
org.cups.cups-lpd
: Escucha en TCP (SockType: stream
) conSockServiceName: printer
SockServiceName debe ser un puerto o un servicio de
/etc/services
com.apple.xscertd.plist
: Escucha en TCP en el puerto 1640
Demonios de ruta que se ejecutan cuando cambia una ruta especificada:
com.apple.postfix.master
: Verifica la ruta/etc/postfix/aliases
Demonios de notificaciones de IOKit:
com.apple.xartstorageremoted
:"com.apple.iokit.matching" => { "com.apple.device-attach" => { "IOMatchLaunchStream" => 1 ...
Puerto Mach:
com.apple.xscertd-helper.plist
: Indica en la entradaMachServices
el nombrecom.apple.xscertd.helper
UserEventAgent:
Esto es diferente al anterior. Hace que launchd genere aplicaciones en respuesta a eventos específicos. Sin embargo, en este caso, el binario principal involucrado no es
launchd
sino/usr/libexec/UserEventAgent
. Carga complementos desde la carpeta restringida por SIP/System/Library/UserEventPlugins/
donde cada complemento indica su inicializador en la claveXPCEventModuleInitializer
o, en el caso de complementos más antiguos, en el diccionarioCFPluginFactories
bajo la claveFB86416D-6164-2070-726F-70735C216EC0
de suInfo.plist
.
Archivos de inicio de shell
Descripción: https://theevilbit.github.io/beyond/beyond_0001/ Descripción (xterm): https://theevilbit.github.io/beyond/beyond_0018/
Útil para evadir el sandbox: ✅
Bypass de TCC: ✅
Pero necesitas encontrar una aplicación con un bypass de TCC que ejecute un shell que cargue estos archivos
Ubicaciones
~/.zshrc
,~/.zlogin
,~/.zshenv.zwc
,~/.zshenv
,~/.zprofile
Disparador: Abrir una terminal con zsh
/etc/zshenv
,/etc/zprofile
,/etc/zshrc
,/etc/zlogin
Disparador: Abrir una terminal con zsh
Se requiere permisos de root
~/.zlogout
Disparador: Salir de una terminal con zsh
/etc/zlogout
Disparador: Salir de una terminal con zsh
Se requieren permisos de root
Potencialmente más en:
man zsh
~/.bashrc
Disparador: Abrir una terminal con bash
/etc/profile
(no funcionó)~/.profile
(no funcionó)~/.xinitrc
,~/.xserverrc
,/opt/X11/etc/X11/xinit/xinitrc.d/
Disparador: Se espera que se active con xterm, pero no está instalado y aún después de instalarlo se produce este error: xterm:
DISPLAY is not set
Descripción y Explotación
Al iniciar un entorno de shell como zsh
o bash
, se ejecutan ciertos archivos de inicio. macOS actualmente utiliza /bin/zsh
como shell predeterminado. Este shell se accede automáticamente cuando se inicia la aplicación Terminal o cuando se accede a un dispositivo a través de SSH. Si bien bash
y sh
también están presentes en macOS, deben ser invocados explícitamente para ser utilizados.
La página de manual de zsh, que podemos leer con man zsh
, tiene una larga descripción de los archivos de inicio.
Aplicaciones Reabiertas
Configurar la explotación indicada y cerrar sesión e iniciar sesión o incluso reiniciar no funcionó para mí para ejecutar la aplicación. (La aplicación no se estaba ejecutando, tal vez necesita estar en ejecución cuando se realizan estas acciones)
Descripción: https://theevilbit.github.io/beyond/beyond_0021/
Ubicación
~/Library/Preferences/ByHost/com.apple.loginwindow.<UUID>.plist
Disparador: Reiniciar la reapertura de aplicaciones
Descripción y Explotación
Todas las aplicaciones a reabrir están dentro del plist ~/Library/Preferences/ByHost/com.apple.loginwindow.<UUID>.plist
Por lo tanto, para hacer que las aplicaciones reabiertas lancen la suya propia, solo necesita agregar su aplicación a la lista.
El UUID se puede encontrar listando ese directorio o con ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'
Para verificar las aplicaciones que se reabrirán, puede hacer:
Para agregar una aplicación a esta lista puedes usar:
Preferencias de Terminal
Ubicación
~/Library/Preferences/com.apple.Terminal.plist
Desencadenante: Abrir Terminal
Descripción y Explotación
En ~/Library/Preferences
se almacenan las preferencias del usuario en las aplicaciones. Algunas de estas preferencias pueden contener una configuración para ejecutar otras aplicaciones/scripts.
Por ejemplo, Terminal puede ejecutar un comando al iniciar:
Esta configuración se refleja en el archivo ~/Library/Preferences/com.apple.Terminal.plist
de la siguiente manera:
Entonces, si se pudiera sobrescribir el plist de las preferencias del terminal en el sistema, la funcionalidad open
se puede utilizar para abrir el terminal y ejecutar ese comando.
Esto se puede agregar desde la línea de comandos con:
Scripts de Terminal / Otras extensiones de archivo
Ubicación
En cualquier lugar
Desencadenante: Abrir Terminal
Descripción y Explotación
Si creas un script .terminal
y lo abres, la aplicación Terminal se invocará automáticamente para ejecutar los comandos indicados en él. Si la app Terminal tiene algunos privilegios especiales (como TCC), tu comando se ejecutará con esos privilegios especiales.
Pruébalo con:
También se pueden usar las extensiones .command
, .tool
, con contenido de scripts de shell regular y también se abrirán en Terminal.
Si Terminal tiene Acceso completo al disco, podrá completar esa acción (nota que el comando ejecutado será visible en una ventana de terminal).
Plugins de Audio
Descripción: https://theevilbit.github.io/beyond/beyond_0013/ Descripción: https://posts.specterops.io/audio-unit-plug-ins-896d3434a882
Ubicación
/Library/Audio/Plug-Ins/HAL
Se requieren permisos de root
Desencadenar: Reiniciar coreaudiod o la computadora
/Library/Audio/Plug-ins/Components
Se requieren permisos de root
Desencadenar: Reiniciar coreaudiod o la computadora
~/Library/Audio/Plug-ins/Components
Desencadenar: Reiniciar coreaudiod o la computadora
/System/Library/Components
Se requieren permisos de root
Desencadenar: Reiniciar coreaudiod o la computadora
Descripción
Según las descripciones anteriores, es posible compilar algunos plugins de audio y cargarlos.
Plugins de QuickLook
Descripción: https://theevilbit.github.io/beyond/beyond_0028/
Ubicación
/System/Library/QuickLook
/Library/QuickLook
~/Library/QuickLook
/Applications/NombredelaAplicación/Aplicación/Contenidos/Biblioteca/QuickLook/
~/Applications/NombredelaAplicación/Aplicación/Contenidos/Biblioteca/QuickLook/
Descripción y Explotación
Los plugins de QuickLook se pueden ejecutar cuando se activa la vista previa de un archivo (presionando la barra espaciadora con el archivo seleccionado en Finder) y se instala un plugin que admita ese tipo de archivo.
Es posible compilar tu propio plugin de QuickLook, colocarlo en una de las ubicaciones anteriores para cargarlo y luego ir a un archivo compatible y presionar espacio para activarlo.
Ganchos de Inicio/Cierre de Sesión
Esto no funcionó para mí, ni con el LoginHook de usuario ni con el LogoutHook de root
Descripción: https://theevilbit.github.io/beyond/beyond_0022/
Ubicación
Necesitas poder ejecutar algo como
defaults write com.apple.loginwindow LoginHook /Users/$USER/hook.sh
Lo
calizado en~/Library/Preferences/com.apple.loginwindow.plist
Están obsoletos pero se pueden usar para ejecutar comandos cuando un usuario inicia sesión.
Este ajuste se almacena en /Users/$USER/Library/Preferences/com.apple.loginwindow.plist
Para eliminarlo:
El usuario root se almacena en /private/var/root/Library/Preferences/com.apple.loginwindow.plist
Bypass condicional de Sandbox
Aquí puedes encontrar ubicaciones de inicio útiles para bypass de sandbox que te permiten simplemente ejecutar algo escribiéndolo en un archivo y esperando condiciones no muy comunes como programas específicos instalados, acciones de usuario "poco comunes" o entornos.
Cron
Descripción: https://theevilbit.github.io/beyond/beyond_0004/
Útil para bypass de sandbox: ✅
Sin embargo, necesitas poder ejecutar el binario
crontab
O ser root
Bypass de TCC: 🔴
Ubicación
/usr/lib/cron/tabs/
,/private/var/at/tabs
,/private/var/at/jobs
,/etc/periodic/
Se requiere ser root para acceso de escritura directa. No se requiere ser root si puedes ejecutar
crontab <archivo>
Desencadenante: Depende del trabajo cron
Descripción y Explotación
Lista los trabajos cron del usuario actual con:
También puedes ver todos los trabajos cron de los usuarios en /usr/lib/cron/tabs/
y /var/at/tabs/
(necesita permisos de root).
En MacOS se pueden encontrar varias carpetas que ejecutan scripts con cierta frecuencia en:
Allí puedes encontrar los trabajos cron regulares, los trabajos at (poco utilizados) y los trabajos periódicos (principalmente utilizados para limpiar archivos temporales). Los trabajos periódicos diarios se pueden ejecutar, por ejemplo, con: periodic daily
.
Para agregar un trabajo cron de usuario programáticamente es posible utilizar:
iTerm2
Escritura: https://theevilbit.github.io/beyond/beyond_0002/
Ubicaciones
~/Library/Application Support/iTerm2/Scripts/AutoLaunch
Desencadenar: Abrir iTerm
~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt
Desencadenar: Abrir iTerm
~/Library/Preferences/com.googlecode.iterm2.plist
Desencadenar: Abrir iTerm
Descripción y Explotación
Los scripts almacenados en ~/Library/Application Support/iTerm2/Scripts/AutoLaunch
se ejecutarán. Por ejemplo:
El archivo ~/Library/LaunchAgents
contiene agentes de lanzamiento de usuario.
El script ~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt
también se ejecutará:
El archivo de preferencias de iTerm2 ubicado en ~/Library/Preferences/com.googlecode.iterm2.plist
puede indicar un comando a ejecutar cuando se abre el terminal de iTerm2.
Esta configuración se puede ajustar en la configuración de iTerm2:
Y el comando se refleja en las preferencias:
Puedes configurar el comando a ejecutar con:
Es altamente probable que haya otras formas de abusar de las preferencias de iTerm2 para ejecutar comandos arbitrarios.
xbar
Explicación: https://theevilbit.github.io/beyond/beyond_0007/
Útil para evadir el sandbox: ✅
Pero xbar debe estar instalado
Bypass de TCC: ✅
Requiere permisos de Accesibilidad
Ubicación
~/Library/Application\ Support/xbar/plugins/
Disparador: Una vez que xbar es ejecutado
Descripción
Si el popular programa xbar está instalado, es posible escribir un script de shell en ~/Library/Application\ Support/xbar/plugins/
que se ejecutará al iniciar xbar:
Hammerspoon
Descripción: https://theevilbit.github.io/beyond/beyond_0008/
Útil para evadir el sandbox: ✅
Pero Hammerspoon debe estar instalado
Bypass de TCC: ✅
Requiere permisos de Accesibilidad
Ubicación
~/.hammerspoon/init.lua
Disparador: Una vez que se ejecuta Hammerspoon
Descripción
Hammerspoon sirve como una plataforma de automatización para macOS, aprovechando el lenguaje de script LUA para sus operaciones. Notablemente, admite la integración de código completo de AppleScript y la ejecución de scripts de shell, mejorando significativamente sus capacidades de scripting.
La aplicación busca un único archivo, ~/.hammerspoon/init.lua
, y cuando se inicia, se ejecutará el script.
BetterTouchTool
Útil para evadir el sandbox: ✅
Pero BetterTouchTool debe estar instalado
Bypass de TCC: ✅
Solicita permisos de Automatización de accesos directos y Accesibilidad
Ubicación
~/Library/Application Support/BetterTouchTool/*
Esta herramienta permite indicar aplicaciones o scripts para ejecutar cuando se presionan algunos accesos directos. Un atacante podría configurar su propio acceso directo y acción para ejecutar en la base de datos para hacer que ejecute código arbitrario (un acceso directo podría ser simplemente presionar una tecla).
Alfred
Útil para evadir el sandbox: ✅
Pero Alfred debe estar instalado
Bypass de TCC: ✅
Solicita permisos de Automatización, Accesibilidad e incluso acceso completo al disco
Ubicación
???
Permite crear flujos de trabajo que pueden ejecutar código cuando se cumplen ciertas condiciones. Potencialmente es posible que un atacante cree un archivo de flujo de trabajo y haga que Alfred lo cargue (es necesario pagar la versión premium para usar flujos de trabajo).
SSHRC
Writeup: https://theevilbit.github.io/beyond/beyond_0006/
Útil para evadir el sandbox: ✅
Pero ssh necesita estar habilitado y usado
Bypass de TCC: ✅
SSH solía tener acceso completo al disco
Ubicación
~/.ssh/rc
Disparador: Inicio de sesión a través de ssh
/etc/ssh/sshrc
Se requiere permisos de root
Disparador: Inicio de sesión a través de ssh
Para activar ssh se requiere Acceso Completo al Disco:
Descripción y Explotación
Por defecto, a menos que PermitUserRC no
en /etc/ssh/sshd_config
, cuando un usuario inicia sesión a través de SSH los scripts /etc/ssh/sshrc
y ~/.ssh/rc
se ejecutarán.
Elementos de Inicio de Sesión
Descripción: https://theevilbit.github.io/beyond/beyond_0003/
Ubicaciones
~/Library/Application Support/com.apple.backgroundtaskmanagementagent
Disparador: Inicio de sesión
Carga útil de explotación almacenada llamando a
osascript
/var/db/com.apple.xpc.launchd/loginitems.501.plist
Disparador: Inicio de sesión
Se requieren permisos de root
Descripción
En Preferencias del Sistema -> Usuarios y Grupos -> Elementos de Inicio de Sesión puedes encontrar elementos que se ejecutarán cuando el usuario inicie sesión. Es posible listarlos, agregar y eliminar desde la línea de comandos:
Estos elementos se almacenan en el archivo ~/Library/Application Support/com.apple.backgroundtaskmanagementagent
Los elementos de inicio de sesión también se pueden indicar utilizando la API SMLoginItemSetEnabled que almacenará la configuración en /var/db/com.apple.xpc.launchd/loginitems.501.plist
ZIP como Elemento de Inicio de Sesión
(Consulte la sección anterior sobre Elementos de Inicio de Sesión, esta es una extensión)
Si almacenas un archivo ZIP como un Elemento de Inicio de Sesión, el Archive Utility
lo abrirá y si el zip estaba almacenado, por ejemplo, en ~/Library
y contenía la carpeta LaunchAgents/file.plist
con un backdoor, esa carpeta se creará (no lo está de forma predeterminada) y el plist se agregará para que la próxima vez que el usuario vuelva a iniciar sesión, se ejecute el backdoor indicado en el plist.
Otra opción sería crear los archivos .bash_profile
y .zshenv
dentro del directorio HOME del usuario, por lo que si la carpeta LaunchAgents ya existe, esta técnica seguiría funcionando.
At
Artículo: https://theevilbit.github.io/beyond/beyond_0014/
Ubicación
Necesitas ejecutar
at
y debe estar habilitado
Descripción
Las tareas de at
están diseñadas para programar tareas únicas que se ejecutarán en momentos específicos. A diferencia de los trabajos cron, las tareas de at
se eliminan automáticamente después de la ejecución. Es crucial tener en cuenta que estas tareas son persistentes en reinicios del sistema, lo que las convierte en posibles preocupaciones de seguridad bajo ciertas condiciones.
Por defecto están deshabilitadas, pero el usuario root puede habilitarlas con:
Esto creará un archivo en 1 hora:
Verifica la cola de trabajos usando atq
:
Arriba podemos ver dos trabajos programados. Podemos imprimir los detalles del trabajo usando at -c NÚMERO_DE_TRABAJO
Si las tareas de AT no están habilitadas, las tareas creadas no se ejecutarán.
Los archivos de trabajo se pueden encontrar en /private/var/at/jobs/
El nombre de archivo contiene la cola, el número de trabajo y la hora programada para ejecutarse. Por ejemplo, veamos a0001a019bdcd2
.
a
- esta es la cola0001a
- número de trabajo en hexadecimal,0x1a = 26
019bdcd2
- hora en hexadecimal. Representa los minutos transcurridos desde la época.0x019bdcd2
es26991826
en decimal. Si lo multiplicamos por 60 obtenemos1619509560
, que esGMT: 2021. April 27., Tuesday 7:46:00
.
Si imprimimos el archivo de trabajo, encontramos que contiene la misma información que obtuvimos usando at -c
.
Acciones de Carpeta
Descripción: https://theevilbit.github.io/beyond/beyond_0024/ Descripción: https://posts.specterops.io/folder-actions-for-persistence-on-macos-8923f222343d
Útil para evadir el sandbox: ✅
Pero necesitas poder llamar a
osascript
con argumentos para contactar conSystem Events
y poder configurar Acciones de CarpetaBypass de TCC: 🟠
Tiene algunos permisos básicos de TCC como Escritorio, Documentos y Descargas
Ubicación
/Library/Scripts/Folder Action Scripts
Requiere permisos de root
Disparador: Acceso a la carpeta especificada
~/Library/Scripts/Folder Action Scripts
Disparador: Acceso a la carpeta especificada
Descripción y Explotación
Las Acciones de Carpeta son scripts que se activan automáticamente por cambios en una carpeta, como agregar, quitar elementos u otras acciones como abrir o cambiar el tamaño de la ventana de la carpeta. Estas acciones pueden ser utilizadas para diversas tareas y pueden ser activadas de diferentes formas, como mediante la interfaz de Finder o comandos de terminal.
Para configurar Acciones de Carpeta, tienes opciones como:
Crear un flujo de trabajo de Acción de Carpeta con Automator e instalarlo como un servicio.
Adjuntar un script manualmente a través de la Configuración de Acciones de Carpeta en el menú contextual de una carpeta.
Utilizar OSAScript para enviar mensajes de Evento de Apple a la aplicación
System Events.app
para configurar programáticamente una Acción de Carpeta.
Este método es particularmente útil para incrustar la acción en el sistema, ofreciendo un nivel de persistencia.
El siguiente script es un ejemplo de lo que puede ser ejecutado por una Acción de Carpeta:
Para hacer que el script anterior sea utilizable por las Acciones de Carpeta, compílalo usando:
Después de compilar el script, configura las Acciones de Carpeta ejecutando el script a continuación. Este script habilitará las Acciones de Carpeta de forma global y adjuntará específicamente el script previamente compilado a la carpeta Escritorio.
Ejecuta el script de configuración con:
Esta es la forma de implementar esta persistencia a través de la GUI:
Este es el script que se ejecutará:
Compílalo con: osacompile -l JavaScript -o folder.scpt source.js
Muévelo a:
Luego, abre la aplicación Folder Actions Setup
, selecciona la carpeta que deseas vigilar y selecciona en tu caso folder.scpt
(en mi caso lo llamé output2.scp):
Ahora, si abres esa carpeta con Finder, tu script se ejecutará.
Esta configuración se almacenó en el plist ubicado en ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist
en formato base64.
Ahora, intentemos preparar esta persistencia sin acceso a la GUI:
Copia
~/Library/Preferences/com.apple.FolderActionsDispatcher.plist
a/tmp
para hacer una copia de seguridad:
cp ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist /tmp
Elimina las Acciones de Carpeta que acabas de configurar:
Ahora que tenemos un entorno vacío
Copia el archivo de respaldo:
cp /tmp/com.apple.FolderActionsDispatcher.plist ~/Library/Preferences/
Abre la aplicación Folder Actions Setup para consumir esta configuración:
open "/System/Library/CoreServices/Applications/Folder Actions Setup.app/"
Y esto no funcionó para mí, pero esas son las instrucciones del informe :(
Accesos directos del Dock
Informe: https://theevilbit.github.io/beyond/beyond_0027/
Útil para evadir el sandbox: ✅
Pero necesitas haber instalado una aplicación maliciosa dentro del sistema
Bypass de TCC: 🔴
Ubicación
~/Library/Preferences/com.apple.dock.plist
Disparador: Cuando el usuario hace clic en la aplicación dentro del dock
Descripción y Explotación
Todas las aplicaciones que aparecen en el Dock están especificadas dentro del plist: ~/Library/Preferences/com.apple.dock.plist
Es posible añadir una aplicación solo con:
Usando algo de ingeniería social podrías hacerte pasar, por ejemplo, por Google Chrome dentro del dock y realmente ejecutar tu propio script:
Selectores de color
Descripción: https://theevilbit.github.io/beyond/beyond_0017
Útil para evadir el sandbox: 🟠
Se necesita una acción muy específica
Terminarás en otro sandbox
Bypass de TCC: 🔴
Ubicación
/Library/ColorPickers
Se requieren permisos de root
Desencadenante: Usar el selector de color
~/Library/ColorPickers
Desencadenante: Usar el selector de color
Descripción y Exploit
Compila un paquete de selector de color con tu código (podrías usar este por ejemplo) y agrega un constructor (como en la sección de Protector de pantalla) y copia el paquete a ~/Library/ColorPickers
.
Entonces, cuando se active el selector de color, tu código también debería ejecutarse.
Ten en cuenta que el binario que carga tu biblioteca tiene un sandbox muy restrictivo: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/LegacyExternalColorPickerService-x86_64.xpc/Contents/MacOS/LegacyExternalColorPickerService-x86_64
Complementos de Sincronización del Finder
Descripción: https://theevilbit.github.io/beyond/beyond_0026/ Descripción: https://objective-see.org/blog/blog_0x11.html
Útil para evadir el sandbox: No, porque necesitas ejecutar tu propia aplicación
Bypass de TCC: ???
Ubicación
Una aplicación específica
Descripción y Exploit
Un ejemplo de aplicación con una Extensión de Sincronización del Finder se puede encontrar aquí.
Las aplicaciones pueden tener Extensiones de Sincronización del Finder
. Esta extensión se incluirá en una aplicación que se ejecutará. Además, para que la extensión pueda ejecutar su código, debe estar firmada con un certificado de desarrollador de Apple válido, debe estar en sandbox (aunque se pueden agregar excepciones relajadas) y debe estar registrada con algo como:
Protector de pantalla
Escritura: https://theevilbit.github.io/beyond/beyond_0016/ Escritura: https://posts.specterops.io/saving-your-access-d562bf5bf90b
Ubicación
/System/Library/Screen Savers
Se requiere permisos de root
Desencadenar: Seleccionar el protector de pantalla
/Library/Screen Savers
Se requiere permisos de root
Desencadenar: Seleccionar el protector de pantalla
~/Library/Screen Savers
Desencadenar: Seleccionar el protector de pantalla
Descripción y Exploit
Crea un nuevo proyecto en Xcode y selecciona la plantilla para generar un nuevo Protector de pantalla. Luego, agrega tu código, por ejemplo el siguiente código para generar registros.
Compílalo, y copia el paquete .saver
a ~/Library/Screen Savers
. Luego, abre la GUI del Protector de pantalla y si haces clic en él, debería generar muchos registros:
Ten en cuenta que debido a que dentro de los permisos del binario que carga este código (/System/Library/Frameworks/ScreenSaver.framework/PlugIns/legacyScreenSaver.appex/Contents/MacOS/legacyScreenSaver
) puedes encontrar com.apple.security.app-sandbox
estarás dentro del sandbox de la aplicación común.
Código del protector de pantalla:
Complementos de Spotlight
writeup: https://theevilbit.github.io/beyond/beyond_0011/
Útil para evadir el sandbox: 🟠
Pero terminarás en un sandbox de aplicación
Bypass de TCC: 🔴
El sandbox parece muy limitado
Ubicación
~/Library/Spotlight/
Disparador: Se crea un nuevo archivo con una extensión gestionada por el complemento de Spotlight.
/Library/Spotlight/
Disparador: Se crea un nuevo archivo con una extensión gestionada por el complemento de Spotlight.
Se requiere permisos de root
/System/Library/Spotlight/
Disparador: Se crea un nuevo archivo con una extensión gestionada por el complemento de Spotlight.
Se requiere permisos de root
Some.app/Contents/Library/Spotlight/
Disparador: Se crea un nuevo archivo con una extensión gestionada por el complemento de Spotlight.
Se requiere una nueva aplicación
Descripción y Explotación
Spotlight es la función de búsqueda integrada de macOS, diseñada para proporcionar a los usuarios acceso rápido y completo a los datos en sus computadoras. Para facilitar esta capacidad de búsqueda rápida, Spotlight mantiene una base de datos propietaria y crea un índice al analizar la mayoría de los archivos, lo que permite búsquedas rápidas tanto por nombres de archivo como por su contenido.
El mecanismo subyacente de Spotlight implica un proceso central llamado 'mds', que significa 'servidor de metadatos'. Este proceso orquesta todo el servicio de Spotlight. Complementariamente, existen múltiples demonios 'mdworker' que realizan una variedad de tareas de mantenimiento, como indexar diferentes tipos de archivos (ps -ef | grep mdworker
). Estas tareas son posibles a través de complementos importadores de Spotlight, o paquetes ".mdimporter", que permiten a Spotlight comprender e indexar contenido en una amplia gama de formatos de archivo.
Los complementos o paquetes .mdimporter
se encuentran en los lugares mencionados anteriormente y si aparece un nuevo paquete, se carga en cuestión de minutos (no es necesario reiniciar ningún servicio). Estos paquetes deben indicar qué tipo de archivo y extensiones pueden gestionar, de esta manera, Spotlight los utilizará cuando se cree un nuevo archivo con la extensión indicada.
Es posible encontrar todos los mdimporters
cargados ejecutando:
Y por ejemplo /Library/Spotlight/iBooksAuthor.mdimporter se utiliza para analizar este tipo de archivos (extensiones .iba
y .book
entre otros):
Si revisas el Plist de otros mdimporter
, es posible que no encuentres la entrada UTTypeConformsTo
. Esto se debe a que es un Identificador de Tipo Uniforme (UTI) integrado y no necesita especificar extensiones.
Además, los complementos predeterminados del sistema siempre tienen prioridad, por lo que un atacante solo puede acceder a archivos que no estén indexados de otra manera por los propios mdimporters
de Apple.
Para crear tu propio importador, podrías comenzar con este proyecto: https://github.com/megrimm/pd-spotlight-importer y luego cambiar el nombre, los CFBundleDocumentTypes
y agregar UTImportedTypeDeclarations
para que admita la extensión que deseas soportar y reflejarlos en schema.xml
.
Luego cambia el código de la función GetMetadataForFile
para ejecutar tu carga útil cuando se cree un archivo con la extensión procesada.
Finalmente, compila y copia tu nuevo .mdimporter
en una de las ubicaciones anteriores y puedes verificar cuándo se carga monitoreando los registros o revisando mdimport -L.
Panel de Preferencias
Parece que esto ya no funciona.
Descripción: https://theevilbit.github.io/beyond/beyond_0009/
Ubicación
/System/Library/PreferencePanes
/Library/PreferencePanes
~/Library/PreferencePanes
Descripción
Parece que esto ya no funciona.
Bypass de Sandbox de Root
Aquí puedes encontrar ubicaciones de inicio útiles para bypass de sandbox que te permiten simplemente ejecutar algo al escribirlo en un archivo siendo root y/o requiriendo otras condiciones extrañas.
Periódico
Descripción: https://theevilbit.github.io/beyond/beyond_0019/
Ubicación
/etc/periodic/daily
,/etc/periodic/weekly
,/etc/periodic/monthly
,/usr/local/etc/periodic
Se requiere ser root
Disparador: Cuando llegue el momento
/etc/daily.local
,/etc/weekly.local
o/etc/monthly.local
Se requiere ser root
Disparador: Cuando llegue el momento
Descripción y Explotación
Los scripts periódicos (/etc/periodic
) se ejecutan debido a los launch daemons configurados en /System/Library/LaunchDaemons/com.apple.periodic*
. Ten en cuenta que los scripts almacenados en /etc/periodic/
se ejecutan como el propietario del archivo, por lo que esto no funcionará para una posible escalada de privilegios.
Hay otros scripts periódicos que se ejecutarán según lo indicado en /etc/defaults/periodic.conf
:
Si logras escribir alguno de los archivos /etc/daily.local
, /etc/weekly.local
o /etc/monthly.local
, se ejecutará tarde o temprano.
Ten en cuenta que el script periódico se ejecutará como el propietario del script. Por lo tanto, si un usuario regular es el propietario del script, se ejecutará como ese usuario (esto podría prevenir ataques de escalada de privilegios).
PAM
Explicación detallada: Linux Hacktricks PAM Explicación detallada: https://theevilbit.github.io/beyond/beyond_0005/
Ubicación
Siempre se requiere ser root
Descripción y Explotación
Dado que PAM se enfoca más en la persistencia y en el malware que en la ejecución sencilla dentro de macOS, este blog no proporcionará una explicación detallada, lee las explicaciones detalladas para entender mejor esta técnica.
Verifica los módulos de PAM con:
Una técnica de persistencia/escalada de privilegios que abusa de PAM es tan fácil como modificar el módulo /etc/pam.d/sudo agregando al principio la línea:
Así se verá algo así como esto:
Y, por lo tanto, cualquier intento de usar sudo
funcionará.
Ten en cuenta que este directorio está protegido por TCC, por lo que es muy probable que el usuario reciba una solicitud pidiendo acceso.
Plugins de Autorización
Descripción: https://theevilbit.github.io/beyond/beyond_0028/ Descripción: https://posts.specterops.io/persistent-credential-theft-with-authorization-plugins-d17b34719d65
Útil para evadir el sandbox: 🟠
Pero necesitas ser root y hacer configuraciones adicionales
Bypass de TCC: ???
Ubicación
/Library/Security/SecurityAgentPlugins/
Se requiere ser root
También es necesario configurar la base de datos de autorización para usar el plugin
Descripción y Explotación
Puedes crear un plugin de autorización que se ejecutará cuando un usuario inicie sesión para mantener la persistencia. Para obtener más información sobre cómo crear uno de estos plugins, consulta las descripciones anteriores (y ten cuidado, uno mal escrito puede bloquearte y necesitarás limpiar tu Mac desde el modo de recuperación).
Mueva el paquete a la ubicación para ser cargado:
Finalmente agregar la regla para cargar este Plugin:
El evaluate-mechanisms
le indicará al marco de autorización que necesitará llamar a un mecanismo externo para la autorización. Además, privileged
hará que se ejecute como root.
Actívalo con:
Y luego el grupo staff debe tener acceso sudo (lee /etc/sudoers
para confirmar).
Man.conf
Explicación: https://theevilbit.github.io/beyond/beyond_0030/
Ubicación
/private/etc/man.conf
Requiere permisos de root
/private/etc/man.conf
: Cada vez que se use man
Descripción y Exploit
El archivo de configuración /private/etc/man.conf
indica el binario/script a utilizar al abrir archivos de documentación de man. Por lo tanto, la ruta al ejecutable podría ser modificada para que cada vez que el usuario use man para leer algunos documentos, se ejecute una puerta trasera.
Por ejemplo, establecido en /private/etc/man.conf
:
Y luego crea /tmp/view
de la siguiente manera:
Apache2
Descripción: https://theevilbit.github.io/beyond/beyond_0023/
Útil para evadir el sandbox: 🟠
Pero necesitas ser root y que apache esté en ejecución
Bypass de TCC: 🔴
Httpd no tiene permisos especiales
Ubicación
/etc/apache2/httpd.conf
Se requiere ser root
Disparador: Cuando se inicia Apache2
Descripción y Exploit
Puedes indicar en /etc/apache2/httpd.conf
que cargue un módulo agregando una línea como esta:
De esta manera, tus módulos compilados serán cargados por Apache. La única condición es que necesitas firmarlos con un certificado válido de Apple, o necesitas agregar un nuevo certificado de confianza en el sistema y firmarlos con él.
Luego, si es necesario, para asegurarte de que el servidor se iniciará, puedes ejecutar:
Ejemplo de código para el Dylb:
Marco de auditoría BSM
Descripción: https://theevilbit.github.io/beyond/beyond_0031/
Útil para evadir el sandbox: 🟠
Pero necesitas ser root, que auditd esté en ejecución y causar una advertencia
Bypass de TCC: 🔴
Ubicación
/etc/security/audit_warn
Se requiere ser root
Desencadenante: Cuando auditd detecta una advertencia
Descripción y Exploit
Cada vez que auditd detecta una advertencia, se ejecuta el script /etc/security/audit_warn
. Por lo tanto, podrías agregar tu carga útil en él.
Elementos de Inicio
Esto está obsoleto, por lo que no se debería encontrar nada en esos directorios.
El directorio StartupItem debe estar ubicado dentro de /Library/StartupItems/
o /System/Library/StartupItems/
. Una vez que este directorio esté establecido, debe contener dos archivos específicos:
Un script rc: Un script de shell ejecutado al inicio.
Un archivo plist, nombrado específicamente
StartupParameters.plist
, que contiene varias configuraciones.
Asegúrate de que tanto el script rc como el archivo StartupParameters.plist
estén ubicados correctamente dentro del directorio StartupItem para que el proceso de inicio los reconozca y los utilice.
Ubicaciones de inicio automático de macOS
Carpetas de inicio automático
Las siguientes carpetas contienen elementos que se inician automáticamente al iniciar sesión en macOS:
/Library/LaunchAgents/
/Library/LaunchDaemons/
/Library/StartupItems/
/System/Library/LaunchAgents/
/System/Library/LaunchDaemons/
/System/Library/StartupItems/
~/Library/LaunchAgents/
~/Library/LaunchDaemons/
Otros lugares de inicio automático
Además de las carpetas mencionadas, también hay otras ubicaciones donde se pueden encontrar elementos de inicio automático en macOS:
Archivos
.plist
en/Library/LaunchDaemons/
y/System/Library/LaunchDaemons/
Archivos
.plist
en/Library/LaunchAgents/
y/System/Library/LaunchAgents/
Archivos
.plist
en/Library/Preferences/
Archivos
.plist
en~/Library/LaunchAgents/
Archivos
.plist
en~/Library/LaunchDaemons/
Archivos
.plist
en~/Library/Preferences/
Al revisar y gestionar estos lugares de inicio automático, puedes mejorar la seguridad y el rendimiento de tu sistema macOS.
emond
No puedo encontrar este componente en mi macOS, para obtener más información consulta el informe técnico
Informe técnico: https://theevilbit.github.io/beyond/beyond_0023/
Introducido por Apple, emond es un mecanismo de registro que parece estar subdesarrollado o posiblemente abandonado, pero sigue siendo accesible. Aunque no es particularmente beneficioso para un administrador de Mac, este servicio oscuro podría servir como un método sutil de persistencia para actores de amenazas, probablemente pasando desapercibido para la mayoría de los administradores de macOS.
Para aquellos que conocen su existencia, identificar cualquier uso malicioso de emond es sencillo. El LaunchDaemon del sistema para este servicio busca scripts para ejecutar en un solo directorio. Para inspeccionar esto, se puede utilizar el siguiente comando:
XQuartz
Escritura: https://theevilbit.github.io/beyond/beyond_0018/
Ubicación
/opt/X11/etc/X11/xinit/privileged_startx.d
Se requiere acceso de root
Desencadenante: Con XQuartz
Descripción y Exploit
XQuartz ya no se instala en macOS, así que si deseas más información, consulta la escritura.
kext
Es tan complicado instalar kext incluso como root que no consideraré esto para escapar de las cajas de arena o incluso para persistencia (a menos que tengas un exploit)
Ubicación
Para instalar un KEXT como un elemento de inicio, debe estar instalado en una de las siguientes ubicaciones:
/System/Library/Extensions
Archivos KEXT integrados en el sistema operativo OS X.
/Library/Extensions
Archivos KEXT instalados por software de terceros
Puedes listar los archivos kext cargados actualmente con:
Para obtener más información sobre extensiones de kernel, consulte esta sección.
amstoold
Descripción: https://theevilbit.github.io/beyond/beyond_0029/
Ubicación
/usr/local/bin/amstoold
Se requiere acceso de root
Descripción y explotación
Aparentemente, el plist
de /System/Library/LaunchAgents/com.apple.amstoold.plist
estaba utilizando este binario mientras exponía un servicio XPC... el problema es que el binario no existía, por lo que podías colocar algo allí y cuando se llamara al servicio XPC, se llamaría a tu binario.
Ya no puedo encontrar esto en mi macOS.
xsanctl
Descripción: https://theevilbit.github.io/beyond/beyond_0015/
Ubicación
/Library/Preferences/Xsan/.xsanrc
Se requiere acceso de root
Desencadenante: Cuando se ejecuta el servicio (raramente)
Descripción y explotación
Aparentemente, no es muy común ejecutar este script y ni siquiera pude encontrarlo en mi macOS, así que si deseas más información, consulta el writeup.
/etc/rc.common
Esto no funciona en las versiones modernas de MacOS
También es posible colocar aquí comandos que se ejecutarán al inicio. Ejemplo de un script rc.common regular:
Técnicas y herramientas de persistencia
Last updated