- El sistema de permisos TCC de macOS podía mostrar pop-ups de solicitud de permisos engañosos al usuario debido a una falla
- Esta vulnerabilidad fue registrada como CVE-2025-31250 y el problema es que el consentimiento del usuario se aplica a otra app
- Existe la posibilidad de un ataque de spoofing en el que una app maliciosa muestra la ventana de solicitud de permisos con el nombre de una app confiable para inducir el consentimiento del usuario
- Fue corregido en macOS Sequoia 15.5 de Apple, pero en otras versiones sigue sin parche
- Además de la dificultad para revisar y revocar el historial de permisos concedidos, existe la posibilidad de que aparezcan vulnerabilidades similares en el futuro
Corrección importante
- Esta vulnerabilidad fue corregida en macOS Sequoia 15.5, pero en macOS Ventura 13.7.6 y macOS Sonoma 14.7.6 todavía no ha sido corregida
- Se confirmó que el informante no fue mencionado en las notas de lanzamiento de seguridad de Apple
- Se verificó directamente en una máquina virtual con macOS Sonoma 14.7.6 que la vulnerabilidad sigue siendo explotable
- Se estima que Ventura 13.7.6 se encuentra en la misma situación
- Se está esperando una respuesta oficial de Apple
Introducción
- La vulnerabilidad CVE-2025-31250 permite que una aplicación muestre pop-ups falsos de solicitud de permisos en macOS
- Si "Application A" muestra el pop-up, este aparece como si fuera de "Application B", y como resultado el consentimiento del usuario termina aplicándose a "Application C"
- Normalmente las tres aplicaciones serían la misma, pero esta falla permitía especificar apps distintas
- Esto genera un problema grave para la confiabilidad de las ventanas de solicitud de permisos
- Métodos similares de "spoofing" ya se habían presentado antes en HackTricks y otros lugares, pero esta vulnerabilidad usa un método más simple
TCC
- TCC es el sistema central de gestión de permisos integrado en los sistemas operativos de Apple
- Los permisos se administran enviando mensajes al demonio "tccd", y la API pública llama funciones del framework privado TCC
- El demonio se comunica mediante mensajes usando la API XPC de Apple
- Antes de que se corrigiera esta vulnerabilidad, al enviar un mensaje arbitrario se podía hacer que la app mostrada en el pop-up de permisos fuera distinta de la app que realmente recibía el permiso
- Para entender por qué existe esta falla, hace falta revisar Apple Events
Apple Events
¿Qué es Apple Events?
- Apple Events es el mecanismo de comunicación entre procesos de las apps de macOS
- Es un protocolo que existe desde la época de los libros clásicos publicados en 1993
- Incluso después de la llegada de macOS X siguió en uso tras ser rediseñado para ajustarse a la nueva arquitectura
- Hoy en día se usa principalmente para automatización (Automation), mediante scripting con AppleScript y JavaScript
- Es parecido a Script Host de Windows, y también ha sido abusado como vector de malware
Apple Events y TCC
- Desde macOS Mojave 10.14, enviar Apple Events requiere consentimiento del usuario
- En la base de datos de permisos de TCC (TCC.db) se registran la app solicitante, el servicio y la respuesta de consentimiento
- Como Apple Events requiere administrar permisos por cada app receptora, se usa la columna indirect object de TCC.db
- La función TCCAccessRequestIndirect del demonio TCC procesa los mensajes que usan esa columna
- Esa función tenía un bug lógico que permitía que la app mostrada al usuario y la app que realmente recibía el permiso fueran distintas
Prueba de concepto (Proof-of-Concept)
- El ejemplo de código Swift manipula el mensaje de solicitud de permisos de la siguiente forma
- Expone al usuario en el pop-up de consentimiento el nombre de la app ubicada en la ruta de "spoofedBundle"
- Define el bundle ID de "actualBundle" como el verdadero destinatario del permiso
- Como resultado, al usuario le parece que una app confiable solicita el permiso, pero el permiso real termina en la app maliciosa
- Incluso dejando vacío el valor de "indirect_object" se podían atacar varios servicios de TCC
- Esto provoca un colapso de la confiabilidad del consentimiento de permisos del usuario
- Un atacante puede engañar al usuario para hacer que una app arbitraria obtenga permisos
Explotación de la vulnerabilidad
Limitaciones y particularidades
- Solo ciertos servicios de TCC son vulnerables al ataque, pero servicios importantes como Microphone y Camera sí están expuestos
- En permisos de archivos o carpetas el efecto no es tan grande debido a protecciones adicionales
- Puede combinarse con ingeniería social para lograr que el usuario otorgue consentimiento en lugar de otra app que realmente necesita el permiso
La importancia del momento oportuno
- El momento en que se muestra el pop-up es importante
- Una app maliciosa puede detectar qué apps están en ejecución y cuál está en primer plano, y mostrar el pop-up en el momento adecuado para confundir al usuario
- Por ejemplo, si se muestra un pop-up de permiso de Camera cuando se abre FaceTime, el usuario podría asumir que es una solicitud legítima
- También es posible un escenario de spoofing de solicitud de permiso de Microphone al ejecutar Voice Memos
- Si se abusa de esto en un momento coherente con el contexto, la tasa de éxito puede aumentar
Revisión de vulnerabilidades pasadas
- Han existido vulnerabilidades que aprovechan que la ruta de TCC.db se determina según la carpeta personal del usuario
- Hasta 2020, bastaba con cambiar la variable de entorno
HOME para usar una TCC.db falsa ($HOMERun)
- Incluso después del parche, aunque se requieren privilegios de root y consentimiento del usuario, combinarlo con spoofing de ingeniería social puede permitir eludir permisos
- Una app maliciosa podría inducir el consentimiento del usuario y luego cambiar la carpeta personal y agregar una base de datos registrada para eludir el sistema con una TCC.db falsa
- Se confirmó mediante pruebas reales que de esta forma se podía afectar el funcionamiento de TCC
Línea de tiempo
1.
- 2024-05-02 : Se realizó el reporte inicial a Apple Product Security y se enviaron mensajes adicionales
2.
- 2024-05-03 : Apple Product Security pidió explicaciones adicionales y estas fueron respondidas
- Ese mismo día se descubrió la posibilidad de evasión total de TCC y se volvió a reportar a Apple
3.
- 2024-05-04 : Continuaron las pruebas del PoC y se dejaron mensajes con actualizaciones adicionales
4.
- 2024-05-06 : Apple Product Security agradeció la información proporcionada
5.
- Después de eso se siguió consultando periódicamente por el estado del parche y verificando la situación; entre 2024-06 y 2025-02 se mantuvo comunicación constante con Apple, pero no se corrigió durante mucho tiempo
6.
- 2025-05-12 : Se publicó la actualización que corrige el bug
Conclusión
Otros puntos
- TCC aparece en la app System Settings, en Privacy & Security (antes Security & Privacy), y en su sección de automatización correspondiente
- Sin embargo, el historial de consentimientos relacionados con Apple Events no se muestra en la GUI, por lo que al usuario le resulta difícil revocarlo directamente
- Se puede revocar con la herramienta CLI
tccutil, pero casi nadie la conoce
- Recientemente se añadió al framework Apple Endpoint Security una función para monitorear cambios en la base de datos de TCC
- Si funciona correctamente, podría ayudar a evitar abusos al informar al usuario cuál fue la app que realmente recibió el permiso
El parche de Apple
- El contenido real del parche es complejo, pero se cambió el comportamiento para que en
tccd los mensajes externos con un indirect object especificado arbitrariamente sean ignorados silenciosamente
- Al verificar el comportamiento, se confirmó que ya no es posible hacer spoofing
- Si el parche fuera incompleto, podría ser necesario aplicar medidas adicionales en futuras actualizaciones
Reflexión final
- A esta vulnerabilidad se le dio el nombre "TCC, Who?"
- Desde la perspectiva de un investigador de seguridad, vuelve a resaltarse la importancia de la confiabilidad del sistema de permisos
- También deja entrever que podrían descubrirse fallas similares en el futuro
- Sugiere que los usuarios no deberían confiar ciegamente en los pop-ups de permisos de macOS
1 comentarios
Opiniones en Hacker News
Apostando a la pequeñísima posibilidad de que alguien de Apple vea esto, voy a repetir algo que siempre he querido pedir: ojalá Apple deje de mostrar en cualquier momento y de forma aleatoria cuadros de diálogo de “ingresa ahora la contraseña del administrador local”, solo porque a la computadora se le ocurrió que quiere actualizarse o instalar algo. Con conocimientos técnicos muy básicos, es fácil hacer en la web un popup falso que se vea casi idéntico, y la mayoría de los usuarios —salvo quizá el 20% más técnico— ni siquiera pensaría en distinguir si es real o si es una falsificación generada dentro del navegador. Para prevenir este problema de raíz, habría que acostumbrar a los usuarios a que el software legítimo no muestra de repente cuadros de contraseña sin aviso en medio de lo que están haciendo, pero la UI de seguridad actual de macOS hace exactamente lo contrario. Deberían cambiarlo por algo como un ícono colorido y llamativo en la barra de menú, o una pantalla de seguridad breve como en Windows. El diseño actual de la UI realmente tiene muchos problemas
Lo que más odio de estos popups es que no tengo idea de por qué lo piden, qué pasa si me niego, ni qué tendría que hacer después si quisiera cambiar esa configuración. Cuando una app te dice “abre el panel de configuración y concede el permiso XXX”, puedes ver claramente qué app es, qué permiso pide y qué interruptor debes activar, pero el popup de contraseña no ofrece esa UX. Por eso terminé detestando un poco el concepto de “capabilities”; la UX es tan mala que parece inevitable. Seguro terminarían mostrando algo como “para usar por completo la app, permite <root my computer>”, porque si el proveedor define el mensaje, siempre sale algo así. Es una UX que no ayuda en nada
Si macOS siguiera mostrando estas ventanas modales adjuntas a la ventana correspondiente, creo que esto sería un poco menos grave. No lo solucionaría por completo, pero sí sería mejor. Ahora, como el modal queda flotando encima de la barra de herramientas, da de inmediato la sensación de que “es parte de la app”. Incluso Steve Jobs, cuando mostró Aqua, enfatizaba que estos modales flotantes perjudicaban la usabilidad, pero creo que ahora Apple terminó así por una extraña obsesión con querer usar UI móvil en todas las pantallas
Mi familia, que no es técnica, ni siquiera distingue entre la contraseña local del equipo y la contraseña de iCloud/Apple ID; al final meten cualquier cosa hasta que una funciona (y eso pasa porque la UI es poco clara e inconsistente). Apple antes se burlaba del UAC de Vista, pero ahora ellos mismos llenaron todo de avisos inesperados y una UI bastante torpe
Me cambié hace poco de Linux a Mac, y estos popups aleatorios pidiendo la contraseña de root de verdad me confundieron. No explican qué app o comando está pidiendo privilegios de root ni por qué los necesita, así que acepté varias veces y luego simplemente empecé a rechazar. Desde entonces ya no han vuelto a aparecer. Pero sigo sin tener idea de para qué salían ni por qué ya no salen
Quiero recomendar otra vez este artículo clásico: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/
El popup de Passkey es un error de seguridad especialmente grave porque no se distingue en absoluto de un popup hecho con JavaScript
En situaciones así, el lector de huellas integrado se agradece muchísimo. Normalmente uso la laptop cerrada y solo con monitor externo, pero cuando hace falta autenticación del sistema, la abro a propósito y autentico con la huella
Giro inesperado: ¡en realidad ese cuadro de diálogo nunca existió! ¡Ya habías caído en la trampa!
Quiero aprovechar el comentario más popular por ahora para compartir un dato: este artículo tiene una actualización importante: https://news.ycombinator.com/item?id=43969087
Me pregunto cuál sería el modelo de amenaza al hacer clic en un popup falso. Si en realidad no es del sistema, ¿no sería una interacción sin efecto real?
Cuando inicias sesión en iCloud aparece un popup que pide la contraseña local de la computadora, y si la ingresas, esa contraseña se sube al servidor de iCloud
Hace poco descubrí que las apps de Mac deberían instalarse en el directorio Applications de mi carpeta personal (~/Applications) en lugar de en Applications del sistema, claro, siempre que la computadora la use una sola persona. Si me bajo a mí mismo a un usuario no administrador y luego instalo las apps en Applications dentro del home, dejan de aparecer esos molestos avisos pidiendo permisos para actualizar. La mayoría de las apps se actualizan solas aunque no seas administrador. Solo algunas excepciones, como Tailscale u otras que necesitan integrarse con el OS, requieren permisos aparte. Por cierto, es una práctica que recomienda una app llamada Pareto Security
Lamentablemente, casi ningún desarrollador de apps conoce este método, y además muchas apps exigen instalarse únicamente en la ruta /Applications, así que ni siquiera funcionan si están en otro lugar
Si instalas una app en ~/Applications, puede actualizarse automáticamente sin root, pero eso también significa que código sospechoso podría sobrescribirla fácilmente sin permisos de root
Estoy usando macOS 15.4.1 y ni siquiera existe la carpeta ~/Applications
¡Me parece genial! Yo sí necesito una cuenta admin para mi uso diario, así que no me sirve mucho, pero para quien aplique, de verdad parece una muy buena opción
Hace falta una corrección importante en el contenido de este artículo. Antes decía que el CVE se corrigió en macOS Sequoia 15.5, pero en realidad el parche no se aplicó a macOS Ventura 13.7.6 ni a macOS Sonoma 14.7.6, publicados el mismo día. Yo asumí que Apple obviamente habría incluido el parche en todas las versiones y por eso lo escribí así, pero al revisar las notas de lanzamiento de seguridad vi que mi nombre no aparecía en esas otras dos versiones y contacté directamente a Apple. Todavía no he recibido respuesta. Para comprobarlo por mi cuenta, levanté una máquina virtual, apliqué el parche en macOS Sonoma 14.7.6 y ejecuté mi PoC; la vulnerabilidad sigue funcionando. Supongo que en Ventura 13.7.6 pasa lo mismo. No entiendo por qué Apple no incluyó el parche. Si consigo más información, volveré a actualizar el artículo
El sistema TCC de macOS tiene fama de ser un mecanismo de privacidad sólido, pero deja una sensación amarga pensar que en la práctica puede eludirse fácilmente con una sola entrada en la base de datos. El popup de consentimiento del usuario pierde mucho sentido frente a una simple manipulación de la base de datos, especialmente en entornos de desarrollo con SIP desactivado. Al final esto es un problema de confianza. Da para preguntarse si el consentimiento a nivel de UX sigue siendo realmente una frontera de seguridad efectiva. Cada vez dependemos más de los popups de permisos a nivel del sistema operativo, pero si ese límite en realidad es una ilusión (o una simple puesta en escena), entonces hay que replantearse no cómo “mostrar” la confianza en los permisos, sino cómo mantenerla de verdad
Recuerdo que en los anuncios de “I'm a Mac and I'm a PC” se burlaban precisamente de estas cosas de Vista. Pero ahora mi Mac me parece incluso peor que Vista. Es realmente irritante
Parece que el compromiso entre seguridad y extensibilidad es un destino inevitable. Aun así, también es cierto que la línea base se ha movido respecto a antes. Al menos macOS no está tan inundado de procesos maliciosos como el Windows de antaño. O quizá simplemente he tenido suerte y he sido cuidadoso
Solo por curiosidad: ¿qué fue exactamente lo que te molestó tanto?
El sistema TCC fue una chapuza desde el principio. Solo complica la vida a los desarrolladores legítimos y bombardea a los usuarios con popups de permisos, mientras que las apps maliciosas siguen encontrando, como han mostrado una y otra vez los investigadores, distintas formas de saltarse este “teatro de seguridad”. No soy investigador de seguridad, pero como desarrollador de Mac yo mismo he encontrado varias formas de eludirlo. Incluso dudo que los ingenieros de Apple entiendan realmente la tecnología que usan. Me pregunto cuántos desarrolladores tradicionales de Mac seguirán quedando
Uso una Mac de trabajo y periódicamente me sale una alerta de “Slack está intentando instalar una nueva helper tool”. No tengo idea de qué es eso ni por qué aparece. Le pregunté al equipo de IT y tampoco supieron cómo comprobarlo. A menudo pienso que esto podría explotarse de forma maliciosa, porque sigue pidiéndome la contraseña, y aunque le doy cancelar cada vez, vuelve a aparecer
Ese cuadro de diálogo lo envía el framework System Management. Es el proceso para instalar una helper tool con privilegios elevados para que Slack pueda actualizarse por sí mismo sin importar dónde esté instalado ni qué usuario lo haya instalado
Cada vez que sale uno de estos popups, no hay manera de saber qué información debería mirar para decidir si lo permito o lo rechazo, así que siempre termino cancelándolo
Yo uso Slack como app web (pero en una ventana independiente, no dentro del navegador) https://support.apple.com/en-us/104996 También se puede usar Discord de la misma forma. En mi experiencia se siente mucho más ágil que una app Electron. De hecho, para la mayoría de apps Electron este enfoque es mejor
Nunca he visto personalmente el popup de “helper tool”, pero no entiendo por qué una app tan simple de mensajería como Slack necesitaría ese tipo de privilegios. Sería bueno contactar al soporte de Slack (y ojalá te den una respuesta de verdad útil)
Igual que cualquier app que requiera contraseña (por ejemplo, un binario en Linux que solo corre como root), claramente existe potencial de abuso. Al final se trata de si puedes confiar en el desarrollador y en que la app sea auténtica. El día que Apple bloquee por completo que apps de terceros obtengan privilegios de root, ese será el día en que la Mac se convierta en un ecosistema totalmente cerrado, y aquí en HN se llenará de quejas. En resumen, es importante mantener una “buena desconfianza” y no dar root a apps como Slack, donde la necesidad no es nada evidente
Te roba el foco de entrada, y el texto que estabas escribiendo en un mensaje de pronto empieza a irse al campo de contraseña. Es una experiencia muy molesta
Los popups se acumulan con retraso. Si enciendo la computadora después del fin de semana, salen una y otra vez, así que termino cerrando Slack por completo. Llevo un año así. No sé cómo revocarle a Slack ese permiso, y se siente un poco malicioso
Este tipo de herramientas de bloqueo “de seguridad” son realmente tontas. En realidad entrenan a la gente para volverse más ingenua. Que hoy sea auténtico no significa que mañana también lo sea. Mi banco me llama seguido para pedirme datos personales “por protección de identidad”, y todos estos mecanismos terminan entrenando a la gente a entregar información privada a desconocidos
No soy desarrollador de macOS, pero me preguntaba si cualquier app (maliciosa) podría imitar el estilo visual de los popups del sistema y robar la contraseña del usuario
VSCode también muestra el mismo popup en la Mac corporativa que me dieron. Llevo años simplemente ignorándolo
Si usas varias cuentas de usuario del sistema con cualquier app basada en Electron, salen este tipo de popups
nordVPN presenta exactamente el mismo comportamiento
A Apple le tomó exactamente un año sacar el parche. Se siente bastante largo. <i>2024-05-04 dejé varios mensajes de actualización, sigo probando el PoC</i> <i>2025-05-12 se publicó el parche</i>
Adobe Creative Cloud sigue ejecutando varios procesos en segundo plano incluso si desactivas explícitamente la ejecución en segundo plano en la configuración del sistema operativo
Me gusta muchísimo la investigación de esta persona, y además siento que presenta súper bien