macOS TCC Bypasses
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)
Esto no es un bypass, es solo cómo funciona TCC: No protege contra la escritura. Si Terminal no tiene acceso para leer el Escritorio de un usuario, aún puede escribir en él:
The extended attribute com.apple.macl se añade al nuevo archivo para dar acceso a la aplicación creadora para leerlo.
Es posible poner una ventana sobre el aviso de TCC para hacer que el usuario lo acepte sin darse cuenta. Puedes encontrar un PoC en TCC-ClickJacking.
El atacante puede crear aplicaciones con cualquier nombre (por ejemplo, Finder, Google Chrome...) en el Info.plist y hacer que solicite acceso a alguna ubicación protegida por TCC. El usuario pensará que la aplicación legítima es la que está solicitando este acceso.
Además, es posible eliminar la aplicación legítima del Dock y poner la falsa en su lugar, de modo que cuando el usuario haga clic en la falsa (que puede usar el mismo ícono) podría llamar a la legítima, pedir permisos de TCC y ejecutar un malware, haciendo que el usuario crea que la aplicación legítima solicitó el acceso.
Más información y PoC en:
macOS Privilege EscalationPor defecto, un acceso a través de SSH solía tener "Acceso Completo al Disco". Para deshabilitar esto, necesitas tenerlo listado pero deshabilitado (eliminarlo de la lista no eliminará esos privilegios):
Aquí puedes encontrar ejemplos de cómo algunos malwares han podido eludir esta protección:
Ten en cuenta que ahora, para poder habilitar SSH necesitas Acceso Completo al Disco
El atributo com.apple.macl se otorga a los archivos para dar a una cierta aplicación permisos para leerlo. Este atributo se establece al arrastrar y soltar un archivo sobre una aplicación, o cuando un usuario hace doble clic en un archivo para abrirlo con la aplicación predeterminada.
Por lo tanto, un usuario podría registrar una aplicación maliciosa para manejar todas las extensiones y llamar a Launch Services para abrir cualquier archivo (por lo que el archivo malicioso obtendrá acceso para leerlo).
El derecho com.apple.private.icloud-account-access permite comunicarse con el servicio XPC com.apple.iCloudHelper que proporcionará tokens de iCloud.
iMovie y Garageband tenían este derecho y otros que lo permitían.
Para más información sobre la explotación para obtener tokens de iCloud de ese derecho, consulta la charla: #OBTS v5.0: "¿Qué sucede en tu Mac, se queda en el iCloud de Apple?!" - Wojciech Regula
Una aplicación con el permiso kTCCServiceAppleEvents podrá controlar otras aplicaciones. Esto significa que podría abusar de los permisos otorgados a las otras aplicaciones.
Para más información sobre Apple Scripts, consulta:
macOS Apple ScriptsPor ejemplo, si una aplicación tiene permiso de Automatización sobre iTerm, por ejemplo, en este caso Terminal tiene acceso sobre iTerm:
Terminal, que no tiene FDA, puede llamar a iTerm, que sí lo tiene, y usarlo para realizar acciones:
O si una aplicación tiene acceso a Finder, podría ser un script como este:
El daemon tccd de usuario estaba utilizando la variable de entorno HOME para acceder a la base de datos de usuarios de TCC desde: $HOME/Library/Application Support/com.apple.TCC/TCC.db
Según esta publicación de Stack Exchange y debido a que el daemon TCC se ejecuta a través de launchd dentro del dominio del usuario actual, es posible controlar todas las variables de entorno pasadas a él.
Así, un atacante podría establecer la variable de entorno $HOME en launchctl para apuntar a un directorio controlado, reiniciar el daemon TCC, y luego modificar directamente la base de datos de TCC para otorgarse todos los derechos de TCC disponibles sin nunca solicitar al usuario final.
PoC:
Notas tenía acceso a ubicaciones protegidas por TCC, pero cuando se crea una nota, esta se crea en una ubicación no protegida. Así que podrías pedirle a notas que copie un archivo protegido en una nota (así que en una ubicación no protegida) y luego acceder al archivo:
El binario /usr/libexec/lsd con la biblioteca libsecurity_translocate tenía el derecho com.apple.private.nullfs_allow, lo que le permitía crear un nullfs mount y tenía el derecho com.apple.private.tcc.allow con kTCCServiceSystemPolicyAllFiles para acceder a todos los archivos.
Era posible agregar el atributo de cuarentena a "Library", llamar al servicio XPC com.apple.security.translocation y luego se mapearía Library a $TMPDIR/AppTranslocation/d/d/Library donde todos los documentos dentro de Library podrían ser accedidos.
Música tiene una característica interesante: Cuando está en funcionamiento, importará los archivos que se suelten en ~/Music/Music/Media.localized/Automatically Add to Music.localized en la "biblioteca de medios" del usuario. Además, llama a algo como: rename(a, b); donde a y b son:
a = "~/Music/Music/Media.localized/Automatically Add to Music.localized/myfile.mp3"
b = "~/Music/Music/Media.localized/Automatically Add to Music.localized/Not Added.localized/2023-09-25 11.06.28/myfile.mp3"
Este comportamiento de rename(a, b); es vulnerable a una Condición de Carrera, ya que es posible colocar dentro de la carpeta Automatically Add to Music.localized un archivo TCC.db falso y luego, cuando se crea la nueva carpeta (b) para copiar el archivo, eliminarlo y apuntarlo a ~/Library/Application Support/com.apple.TCC/.
Si SQLITE_SQLLOG_DIR="path/folder" significa básicamente que cualquier base de datos abierta se copia a esa ruta. En este CVE, este control fue abusado para escribir dentro de una base de datos SQLite que va a ser abierta por un proceso con FDA la base de datos TCC, y luego abusar de SQLITE_SQLLOG_DIR con un symlink en el nombre del archivo para que cuando esa base de datos esté abierta, el usuario TCC.db se sobrescriba con la que se abrió.
Más info en el informe y en la charla.
Si la variable de entorno SQLITE_AUTO_TRACE está configurada, la biblioteca libsqlite3.dylib comenzará a registrar todas las consultas SQL. Muchas aplicaciones usaron esta biblioteca, por lo que era posible registrar todas sus consultas SQLite.
Varias aplicaciones de Apple usaron esta biblioteca para acceder a información protegida por TCC.
Esta variable de entorno es utilizada por el marco Metal que es una dependencia de varios programas, notablemente Music, que tiene FDA.
Configurando lo siguiente: MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name". Si path es un directorio válido, el error se activará y podemos usar fs_usage para ver qué está sucediendo en el programa:
se abrirá un archivo open(), llamado path/.dat.nosyncXXXX.XXXXXX (X es aleatorio)
uno o más write() escribirán el contenido en el archivo (no controlamos esto)
path/.dat.nosyncXXXX.XXXXXX será renombrado a path/name
Es una escritura de archivo temporal, seguida de un rename(old, new) que no es seguro.
No es seguro porque tiene que resolver las rutas antiguas y nuevas por separado, lo que puede llevar algo de tiempo y puede ser vulnerable a una condición de carrera. Para más información, puedes consultar la función renameat_internal() de xnu.
Entonces, básicamente, si un proceso privilegiado está renombrando desde una carpeta que controlas, podrías obtener un RCE y hacer que acceda a un archivo diferente o, como en este CVE, abrir el archivo que la aplicación privilegiada creó y almacenar un FD.
Si el renombrado accede a una carpeta que controlas, mientras has modificado el archivo fuente o tienes un FD a él, cambias el archivo (o carpeta) de destino para apuntar a un symlink, así puedes escribir cuando quieras.
Este fue el ataque en el CVE: Por ejemplo, para sobrescribir el TCC.db del usuario, podemos:
crear /Users/hacker/ourlink para apuntar a /Users/hacker/Library/Application Support/com.apple.TCC/
crear el directorio /Users/hacker/tmp/
establecer MTL_DUMP_PIPELINES_TO_JSON_FILE=/Users/hacker/tmp/TCC.db
activar el error ejecutando Music con esta variable de entorno
capturar el open() de /Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX (X es aleatorio)
aquí también open() este archivo para escritura, y mantener el descriptor de archivo
cambiar atómicamente /Users/hacker/tmp con /Users/hacker/ourlink en un bucle
hacemos esto para maximizar nuestras posibilidades de éxito ya que la ventana de carrera es bastante estrecha, pero perder la carrera tiene un inconveniente negligible
esperar un poco
probar si tuvimos suerte
si no, ejecutar de nuevo desde el principio
Más info en https://gergelykalman.com/lateralus-CVE-2023-32407-a-macos-tcc-bypass.html
Ahora, si intentas usar la variable de entorno MTL_DUMP_PIPELINES_TO_JSON_FILE, las aplicaciones no se lanzarán.
Como root podrías habilitar este servicio y el agente ARD tendrá acceso completo al disco que luego podría ser abusado por un usuario para hacer que copie una nueva base de datos de usuario TCC.
TCC utiliza una base de datos en la carpeta HOME del usuario para controlar el acceso a recursos específicos del usuario en $HOME/Library/Application Support/com.apple.TCC/TCC.db. Por lo tanto, si el usuario logra reiniciar TCC con una variable de entorno $HOME apuntando a una carpeta diferente, el usuario podría crear una nueva base de datos TCC en /Library/Application Support/com.apple.TCC/TCC.db y engañar a TCC para otorgar cualquier permiso TCC a cualquier aplicación.
Ten en cuenta que Apple utiliza la configuración almacenada dentro del perfil del usuario en el atributo NFSHomeDirectory para el valor de $HOME, así que si comprometes una aplicación con permisos para modificar este valor (kTCCServiceSystemPolicySysAdminFiles), puedes armar esta opción con un bypass de TCC.
El primer POC utiliza dsexport y dsimport para modificar la carpeta HOME del usuario.
Obtener un blob csreq para la aplicación objetivo.
Plantar un archivo TCC.db falso con acceso requerido y el blob csreq.
Exportar la entrada de Servicios de Directorio del usuario con dsexport.
Modificar la entrada de Servicios de Directorio para cambiar el directorio home del usuario.
Importar la entrada de Servicios de Directorio modificada con dsimport.
Detener el tccd del usuario y reiniciar el proceso.
El segundo POC utilizó /usr/libexec/configd que tenía com.apple.private.tcc.allow con el valor kTCCServiceSystemPolicySysAdminFiles.
Era posible ejecutar configd con la opción -t, un atacante podría especificar un Bundle personalizado para cargar. Por lo tanto, el exploit reemplaza el método dsexport y dsimport de cambiar el directorio home del usuario con una inyección de código de configd.
Para más información, consulta el informe original.
Existen diferentes técnicas para inyectar código dentro de un proceso y abusar de sus privilegios TCC:
macOS Process AbuseAdemás, la inyección de proceso más común para eludir TCC encontrada es a través de plugins (cargar biblioteca). Los plugins son código extra, generalmente en forma de bibliotecas o plist, que serán cargados por la aplicación principal y se ejecutarán bajo su contexto. Por lo tanto, si la aplicación principal tenía acceso a archivos restringidos por TCC (a través de permisos o derechos otorgados), el código personalizado también lo tendrá.
La aplicación /System/Library/CoreServices/Applications/Directory Utility.app tenía el derecho kTCCServiceSystemPolicySysAdminFiles, cargaba plugins con extensión .daplug y no tenía el runtime endurecido.
Para armar este CVE, se cambia el NFSHomeDirectory (abusando del derecho anterior) para poder apoderarse de la base de datos TCC del usuario para eludir TCC.
Para más información, consulta el informe original.
El binario /usr/sbin/coreaudiod tenía los derechos com.apple.security.cs.disable-library-validation y com.apple.private.tcc.manager. El primero permitiendo inyección de código y el segundo otorgándole acceso para gestionar TCC.
Este binario permitía cargar plugins de terceros desde la carpeta /Library/Audio/Plug-Ins/HAL. Por lo tanto, era posible cargar un plugin y abusar de los permisos TCC con este PoC:
Para más información, consulta el informe original.
Las aplicaciones del sistema que abren el flujo de cámara a través de Core Media I/O (aplicaciones con kTCCServiceCamera) cargan en el proceso estos complementos ubicados en /Library/CoreMediaIO/Plug-Ins/DAL (no restringido por SIP).
Simplemente almacenar allí una biblioteca con el constructor común funcionará para inyectar código.
Varias aplicaciones de Apple eran vulnerables a esto.
La aplicación Firefox tenía los derechos com.apple.security.cs.disable-library-validation y com.apple.security.cs.allow-dyld-environment-variables:
Para más información sobre cómo explotar esto fácilmente consulta el informe original.
El binario /system/Library/Filesystems/acfs.fs/Contents/bin/xsanctl tenía los derechos com.apple.private.tcc.allow y com.apple.security.get-task-allow, lo que permitía inyectar código dentro del proceso y usar los privilegios de TCC.
Telegram tenía los derechos com.apple.security.cs.allow-dyld-environment-variables y com.apple.security.cs.disable-library-validation, por lo que era posible abusar de ello para obtener acceso a sus permisos como grabar con la cámara. Puedes encontrar la carga útil en el informe.
Nota cómo usar la variable env para cargar una biblioteca, se creó un plist personalizado para inyectar esta biblioteca y se usó launchctl para lanzarla:
Es posible invocar open incluso mientras está en sandbox
Es bastante común dar acceso completo al disco (FDA) a la terminal, al menos en computadoras utilizadas por personas técnicas. Y es posible invocar scripts .terminal con ello.
Los scripts .terminal son archivos plist como este con el comando a ejecutar en la clave CommandString:
Una aplicación podría escribir un script de terminal en una ubicación como /tmp y lanzarlo con un comando como:
Cualquier usuario (incluso los no privilegiados) puede crear y montar un snapshot de Time Machine y acceder a TODOS los archivos de ese snapshot.
El único privilegio necesario es que la aplicación utilizada (como Terminal) tenga acceso Full Disk Access (FDA) (kTCCServiceSystemPolicyAllfiles), que debe ser concedido por un administrador.
Una explicación más detallada se puede encontrar en el informe original.
Incluso si el archivo de la base de datos TCC está protegido, era posible montar sobre el directorio un nuevo archivo TCC.db:
Check the full exploit in the original writeup.
La herramienta /usr/sbin/asr permitía copiar todo el disco y montarlo en otro lugar eludiendo las protecciones de TCC.
Hay una tercera base de datos de TCC en /var/db/locationd/clients.plist para indicar los clientes permitidos para acceder a los servicios de ubicación.
La carpeta /var/db/locationd/ no estaba protegida contra el montaje de DMG por lo que era posible montar nuestro propio plist.
En varias ocasiones, los archivos almacenarán información sensible como correos electrónicos, números de teléfono, mensajes... en ubicaciones no protegidas (lo que cuenta como una vulnerabilidad en Apple).
Esto ya no funciona, pero sí funcionó en el pasado:
Otra forma usando CoreGraphics events:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
