¿Se puede confiar en los pop-ups de permisos de macOS?

• CVE-2025-31250 es una vulnerabilidad que hacía difícil confiar en los pop-ups de consentimiento de permisos TCC de macOS, ya que permitía que la app visible en pantalla fuera distinta de la app que realmente recibía el permiso
• El problema estaba en el manejo de TCCAccessRequestIndirect dentro de tccd: target_path se usaba para el nombre de la app mostrado en el pop-up, mientras que target_identifier se usaba para el identificador de la app que realmente recibiría el permiso
• A diferencia de bypasses anteriores, no hacía falta una app falsa, un acceso directo en el Dock ni inducir clics del usuario; si el usuario presionaba Allow en un pop-up falsificado, el ataque podía concretarse
• Apple lo corrigió en macOS Sequoia 15.5, pero confirmó que Ventura 13.7.6 y Sonoma 14.7.6, publicados el mismo día, no incluyen el parche y que no hay planes de corregir versiones anteriores
• Un atacante podía intentar falsificar pop-ups de permisos aprovechando el momento en que se abrían apps como FaceTime, Voice Memos o System Settings, con el riesgo de que el usuario confundiera a qué app estaba otorgando realmente el permiso

---

Funcionamiento clave de CVE-2025-31250

• CVE-2025-31250 es una vulnerabilidad que permitía que la app mostrada en el pop-up de permisos TCC de macOS fuera distinta de la app que realmente recibía el permiso
• Antes del parche, era posible una configuración como esta
  • Application A pedía a macOS que mostrara un pop-up de consentimiento de permisos
  • El pop-up parecía venir de Application B
  • El resultado del consentimiento del usuario se aplicaba a Application C
• Las tres apps podían ser distintas, aunque en un uso normal lo más probable es que fueran la misma app
• El problema central era que no había validación suficiente para asegurar que la app mostrada en el pop-up y la app que realmente recibía el permiso fueran la misma

Alcance del parche y correcciones

• A diferencia de la explicación inicial, el parche solo se aplicó a macOS Sequoia 15.5
• macOS Ventura 13.7.6 y macOS Sonoma 14.7.6, publicados el mismo día, no fueron corregidos
• Al compilar y ejecutar la PoC en una máquina virtual con Sonoma 14.7.6, la vulnerabilidad seguía funcionando
• Apple Product Security cambió el estado del reporte a “We’ve addressed the issue in all planned releases.” y después confirmó que no hay planes de parchear esta vulnerabilidad en Ventura ni en Sonoma
• En consecuencia, Ventura y Sonoma siguen siendo vulnerables a este problema

El punto donde se cruzan TCC y Apple Events

• TCC es el sistema central de permisos en los sistemas operativos de Apple y funciona internamente mediante el daemon tccd y el framework privado TCC
• Los desarrolladores no llaman directamente a la API privada, pero las APIs públicas invocan internamente funciones de TCC cuando hace falta
• tccd recibe mensajes usando la API XPC de Apple
• Antes del parche, una app con capacidad de enviar mensajes XPC a tccd podía mandar mensajes manipulados para separar la app mostrada en el pop-up de la app que realmente recibiría el permiso

Apple Events y el modelo de datos de TCC

• Apple Events es un mecanismo de comunicación entre procesos en macOS y hoy se usa principalmente para automatización
• La automatización con Apple Events puede escribirse mediante la Open Scripting Architecture de Apple
  • El lenguaje más representativo es AppleScript
  • También puede usarse JavaScript
• Desde macOS Mojave 10.14, las apps necesitan consentimiento del usuario vía TCC para enviar Apple Events
• Los resultados de consentimiento de TCC se almacenan en la base de datos SQLite Application Support/com.apple.TCC/TCC.db dentro de la carpeta personal del usuario
• Una fila típica de TCC contiene la app solicitante, el servicio solicitado y el resultado del consentimiento del usuario
• Como Apple Events necesita restringir permisos según la app receptora, usa la columna indirect object
  • Esa columna contiene el identificador de la app que recibirá los Apple Events
  • Además de Apple Events, el servicio FileProviderDomain también usa esta columna

Estructura del mensaje XPC vulnerable

• El problema estaba en un bug lógico de la función TCCAccessRequestIndirect
• Esta función procesa solicitudes de acceso que deben usar la columna indirect object de TCC.db
• La clave de la PoC era separar dos campos cuando target_prompt era 2
  • target_path: se usaba para obtener el nombre de la app que se muestra en el pop-up gráfico de permisos
  • target_identifier: se usaba como el bundle ID de la app que realmente quedaba registrado en la base de datos y recibía el permiso
• Aunque TCCAccessRequestIndirect era una función para indirect object, también podía usarse con varios servicios TCC que no utilizan esa columna, pasando una cadena vacía como indirect object
• Este bug no existía en las demás funciones de solicitud de acceso

Condiciones y límites de explotación

• La explotación solo tenía éxito si el usuario presionaba Allow en el pop-up de permisos
• Los servicios TCC que podían usarse eran limitados, pero incluían servicios importantes como Microphone y Camera
• También era posible falsificar pop-ups de permisos de acceso a ciertos directorios, aunque su utilidad era menor debido a capas extra de seguridad alrededor de los archivos
• También era posible hacer que una app maliciosa aplicara los permisos no a sí misma, sino a otra app
  • Esto podía servir si el atacante tenía control sobre otra app pero esa app requería permisos TCC

Engaño aprovechando el momento del pop-up

• Si un pop-up de permisos aparece al azar, es más probable que el usuario sospeche y presione Don’t Allow
• Las apps de macOS pueden revisar la lista de aplicaciones en ejecución y cuál está en primer plano
  • Ver apps en ejecución: NSWorkspace runningApplications
  • Ver la app en primer plano: NSWorkspace frontmostApplication
• Una app maliciosa puede esperar hasta que cierta app se ejecute o pase al primer plano y entonces mostrar un pop-up de permisos falsificado usando el nombre de esa app
• Por ejemplo, al abrir FaceTime podría falsificarse un pop-up de permiso de Camera, y al abrir Voice Memos uno de Microphone
• El usuario podría interpretar el pop-up que aparece justo después de abrir o cambiar de app como una solicitud legítima de permisos de esa app

Relación con rutas anteriores de bypass de TCC

• Antes, tccd determinaba la carpeta personal del usuario a partir de la variable de entorno HOME, lo que permitía un bypass de TCC usando una carpeta personal falsa y una TCC.db falsa
• Ese problema fue corregido en una actualización de mediados de julio de 2020, y desde entonces tccd consulta la carpeta personal desde el directorio de información de usuario del sistema operativo
• Después de eso siguieron apareciendo casos de bypass que abusaban del cambio de carpeta personal del usuario
  • Wojciech Reguła publicó CVE-2020-27937, que explotaba el sistema de plugins del editor GUI del directorio de información de usuario en macOS
  • El equipo Microsoft Threat Intelligence publicó el bypass powerdir usando comandos de import/export
• Cambiar la carpeta personal del usuario normalmente requiere dos cosas
  • privilegios de root
  • consentimiento del usuario para ciertos servicios TCC
• CVE-2025-31250 no evita el requisito de privilegios root, pero sí podía inducir el consentimiento TCC necesario mediante un pop-up falsificado
• Si una app maliciosa engañaba al usuario para obtener el consentimiento y además conseguía elevar privilegios a root, podía abrirse la ruta de cambiar el directorio de usuario e implantar una TCC.db falsa
• REG.db rastrea las TCC.db válidas, pero TCC incluye una función con la que una app puede añadir entradas a REG.db, permitiendo agregar la ruta de una TCC.db implantada

Límites de la gestión de permisos visible para el usuario

• TCC es el sistema que opera detrás del panel Privacy & Security de System Settings
• Los resultados de consentimiento relacionados con Apple Events se muestran en la sección Automation
• En el panel Privacy & Security, el usuario puede revisar los consentimientos otorgados y, en muchos casos, revocar permisos específicos
• Sin embargo, si un atacante engañaba al usuario para permitir permisos de Apple Events, ese consentimiento no aparecía en System Settings
• El usuario podía revocar el consentimiento con la herramienta CLI tccutil, pero su documentación es limitada y la mayoría de los usuarios difícilmente la conoce
  • La documentación de Apple incluye una vieja Technical Q&A y una IT training page

Endpoint Security y posibilidad de detección

• El framework Endpoint Security de Apple empezó recientemente a soportar monitoreo de modificaciones a la base de datos TCC
• El artículo de Objective-See sobre este cambio está aquí: Endpoint Security TCC database monitoring
• Si esta función opera como se espera, las apps que usan el framework podrían mostrar al usuario una alerta posterior indicando a qué app se le otorgó realmente el permiso
• Aun así, esta posibilidad de detección solo tuvo relevancia directa durante el corto periodo entre la adición del evento de Endpoint Security por parte de Apple y el parche de la vulnerabilidad

Cómo hizo Apple la corrección

• El análisis del binario tccd en macOS Sequoia 15.5 mostró que el parche final fue más complejo de lo que se pensó al principio
• Después del parche, ya no es posible falsificar pop-ups de TCC del mismo modo
• También parece haberse restringido el uso de TCCAccessRequestIndirect con otros servicios TCC mediante un indirect object vacío
• Se observó que este tipo de mensaje vulnerable ahora es descartado silenciosamente por tccd sin ejecutar ninguna acción
• En una validación básica, el parche pareció bueno, aunque se necesita más análisis para entender por completo todo su comportamiento

Flujo del reporte hasta el parche

• Esta fue la segunda vulnerabilidad reportada a Apple por el investigador, y la que más tiempo tardó en ser corregida entre todos sus reportes parchados
• El proceso incluyó el reporte inicial, solicitudes de aclaración adicionales por parte de Apple Product Security, el compartir una posible ruta de bypass completo de TCC, actualizaciones de pruebas de la PoC, verificación del estado de reproducción y varias consultas de seguimiento
• El parche simple propuesto consistía en verificar que ambos campos apuntaran a la misma app
• Apple respondió varias veces que seguía investigando, y después pidió el nombre para los créditos antes de publicar el parche
• A la vulnerabilidad se le dio el nombre “TCC, Who?”