Microsoft descubrió una nueva vulnerabilidad de macOS, «powerdir», que podría permitir a un atacante eludir la tecnología de Transparencia, Consentimiento y Control (TCC) del sistema operativo, obteniendo así acceso no autorizado a los datos protegidos de un usuario.
Introducido por Apple en 2012 en macOS Mountain Lion, TCC está esencialmente diseñado para ayudar a los usuarios a configurar los ajustes de privacidad de sus apps, como el acceso a la cámara, el micrófono o la localización del dispositivo, así como el acceso al calendario o la cuenta de iCloud del usuario, entre otros. Para proteger la TCC, Apple introdujo una función que impide la ejecución de código no autorizado y aplicó una política que restringe el acceso a la TCC sólo a las apps con acceso total al disco. Descubrimos que es posible cambiar mediante programación el directorio de inicio de un usuario objetivo y plantar una base de datos TCC falsa, que almacena el historial de consentimiento de las solicitudes de apps. Si se explota en sistemas sin parches, esta vulnerabilidad podría permitir a un actor malicioso orquestar potencialmente un ataque basado en los datos personales protegidos del usuario. Por ejemplo, el atacante podría secuestrar una aplicación instalada en el dispositivo -o instalar su propia aplicación maliciosa- y acceder al micrófono para grabar conversaciones privadas o capturar información sensible que aparezca en la pantalla del usuario.
Cabe señalar que otras vulnerabilidades de la TCC fueron notificadas anteriormente y posteriormente parcheadas antes de nuestro descubrimiento. También fue a través de nuestro examen de una de las últimas correcciones que nos encontramos con este fallo. De hecho, durante esta investigación, tuvimos que actualizar nuestro exploit de prueba de concepto (POC) porque la versión inicial ya no funcionaba en la última versión de macOS, Monterey. Esto demuestra que incluso cuando macOS u otros sistemas operativos y aplicaciones se endurecen con cada versión, los proveedores de software como Apple, los investigadores de seguridad y la comunidad de seguridad en general, necesitan trabajar continuamente juntos para identificar y corregir las vulnerabilidades antes de que los atacantes puedan aprovecharse de ellas.
Los investigadores de seguridad de Microsoft siguen vigilando el panorama de las amenazas para descubrir nuevas vulnerabilidades y técnicas de ataque que podrían afectar a macOS y a otros dispositivos que no son de Windows. Los descubrimientos y conocimientos de nuestra investigación enriquecen nuestras tecnologías y soluciones de protección, como Microsoft Defender for Endpoint, que permite a las organizaciones obtener visibilidad de sus redes, cada vez más heterogéneas. Por ejemplo, esta investigación sirvió de base para la detección genérica del comportamiento asociado a esta vulnerabilidad, lo que permite a Defender for Endpoint proporcionar inmediatamente visibilidad y protección contra los exploits incluso antes de que se aplique el parche. Esta visibilidad también permite a las organizaciones detectar, gestionar, responder y remediar las vulnerabilidades y las amenazas multiplataforma más rápidamente.
TCC overview
Como se ha mencionado anteriormente, la TCC es una tecnología que impide que las aplicaciones accedan a la información personal de los usuarios sin su consentimiento y conocimiento previos. El usuario suele gestionarla en las Preferencias del Sistema de macOS (Preferencias del Sistema > Seguridad y Privacidad > Privacidad):
TCC mantiene bases de datos que contienen el historial de consentimiento de las solicitudes de las aplicaciones. Por lo general, cuando una aplicación solicita acceso a datos protegidos del usuario, puede ocurrir una de estas dos cosas:
- Si la aplicación y el tipo de solicitud tienen un registro en las bases de datos de la TCC, un indicador en la entrada de la base de datos dicta si se permite o se deniega la solicitud de forma automática y sin ninguna interacción del usuario.
- Si la aplicación y el tipo de solicitud no tienen un registro en las bases de datos de la TCC, se presenta un aviso al usuario, que decide si concede o deniega el acceso. Dicha decisión se guarda en las bases de datos, de modo que las siguientes solicitudes similares quedarán en el primer caso.
Bajo el capó, hay dos tipos de bases de datos TCC. Cada tipo mantiene sólo un subconjunto de los tipos de solicitudes:
- Base de datos específica del usuario: contiene tipos de permisos almacenados que sólo se aplican al perfil de usuario específico; se guarda en ~/Library/Application Support/com.apple.TCC/TCC.db y puede acceder a ella el usuario propietario de dicho perfil
- Base de datos de todo el sistema: contiene los tipos de permisos almacenados que se aplican a nivel del sistema; se guarda en /Library/Application Support/com.apple.TCC/TCC.db y pueden acceder a ella los usuarios con acceso de root o de disco completo
macOS implementa la lógica de TCC utilizando un demonio especial llamado tccd. De hecho, hay al menos dos instancias de tccd: una ejecutada por el usuario y la otra por root.
Cada tipo de solicitud comienza con un prefijo kTCCService. Aunque no se trata de una lista exhaustiva, a continuación se muestran algunos ejemplos:
| Request type | Description | Handled by |
|---|---|---|
| kTCCServiceLiverpool | Location services access | User-specific TCC database |
| kTCCServiceUbiquity | iCloud access | User-specific TCC database |
| kTCCServiceSystemPolicyDesktopFolder | Desktop folder access | User-specific TCC database |
| kTCCServiceCalendar | Calendar access | User-specific TCC database |
| kTCCServiceReminders | Access to reminders | User-specific TCC database |
| kTCCServiceMicrophone | Microphone access | User-specific TCC database |
| kTCCServiceCamera | Camera access | User-specific TCC database |
| kTCCServiceSystemPolicyAllFiles | Full disk access capabilities | System-wide TCC database |
| kTCCServiceScreenCapture | Screen capture capabilities | System-wide TCC database |
También hay que tener en cuenta que el archivo TCC.db es una base de datos SQLITE, por lo que si se concede un acceso completo al disco a un usuario, éste puede ver la base de datos e incluso editarla:
Las columnas de la base de datos se explican por sí mismas, salvo la columna csreq. Los valores de csreq contienen un bloque hexadecimal que codifica los requisitos de firma de código para la aplicación. Estos valores pueden calcularse fácilmente con las utilidades codesign y csreq, como se ve en la figura 4:
Teniendo en cuenta esto, si un actor malicioso obtuviera acceso completo al disco de las bases de datos de TCC, podría editarlo para conceder permisos arbitrarios a cualquier aplicación que desee, incluida su propia aplicación maliciosa. Además, el usuario afectado no tendría que permitir o denegar dichos permisos, lo que permitiría que la aplicación se ejecutara con configuraciones que podría desconocer o consentir.
Asegurar (y bypassing) la TCC: técnicas y vulnerabilidades previamente reportadas
Anteriormente, las aplicaciones podían acceder directamente a las bases de datos TCC para ver e incluso modificar su contenido. Dado el riesgo de bypass mencionado anteriormente, Apple realizó dos cambios. En primer lugar, Apple protegió la base de datos TCC.db de todo el sistema mediante la protección de integridad del sistema (SIP), una función de macOS que impide la ejecución de código no autorizado. En segundo lugar, Apple aplicó una política de TCC según la cual sólo las aplicaciones con acceso total al disco pueden acceder a los archivos TCC.db. Sin embargo, hay que tener en cuenta que esta política también fue abusada posteriormente, ya que algunas aplicaciones requerían dicho acceso para funcionar correctamente (por ejemplo, el demonio SSH, sshd).
Curiosamente, los atacantes aún pueden averiguar si el Terminal de un usuario tiene acceso total al disco simplemente intentando listar los archivos en /Library/Application Support/com.apple.TCC. Un intento exitoso significa que el Terminal tiene capacidades de acceso total al disco, y un atacante puede, por lo tanto, modificar libremente el TCC.db del usuario.
Además, se han reportado previamente varias vulnerabilidades relacionadas con el bypass de TCC. Entre ellas se encuentran las siguientes:
- Time Machine mounts (CVE-2020-9771): macOS ofrece una solución integrada de copia de seguridad y restauración llamada Time Machine. Se descubrió que las copias de seguridad de Time Machine podían montarse (mediante la utilidad apfs_mount) con la bandera «noowners». Dado que estas copias de seguridad contienen los archivos TCC.db, un atacante podría montar esas copias de seguridad y determinar la política TCC del dispositivo sin tener acceso completo al disco.
- Environment variable poisoning (CVE-2020-9934): Se descubrió que el tccd del usuario podía construir la ruta al archivo TCC.db expandiendo $HOME/Library/Application Support/com.apple.TCC/TCC.db. Como el usuario podía manipular la variable de entorno $HOME (introducida en tccd por launchd), un atacante podía colocar un archivo TCC.db elegido en una ruta arbitraria, envenenar la variable de entorno $HOME y hacer que TCC.db consumiera ese archivo en su lugar.
- Bundle conclusion issue (CVE-2021-30713): Revelado por primera vez por Jamf en una entrada de blog sobre la familia de malware XCSSET, este fallo abusaba de la forma en que macOS deducía la información del paquete de aplicaciones. Por ejemplo, supongamos que un atacante conoce una aplicación específica que suele tener acceso al micrófono. En ese caso, podría plantar su código de aplicación en el paquete de la aplicación objetivo y «heredar» sus capacidades TCC.
Desde entonces, Apple ha parcheado estas vulnerabilidades. Sin embargo, basándonos en nuestra investigación, el bypass potencial a TCC.db todavía puede ocurrir. La siguiente sección discute la vulnerabilidad que descubrimos y algunos detalles sobre los exploits POC que desarrollamos para probar dicha vulnerabilidad.
Modificación del directorio de inicio: La vulnerabilidad de ‘powerdir’
Al evaluar las anteriores vulnerabilidades de la TCC, hemos valorado cómo ha solucionado Apple cada problema. Una de las correcciones que nos llamó la atención fue la de CVE-2020-9934 (la vulnerabilidad de envenenamiento de la variable de entorno $HOME). La solución puede verse en la función _db_open de tccd:
Observamos que en lugar de expandir la variable de entorno $HOME, Apple decidió invocar getpwuid() sobre el usuario actual (recuperado con getuid()). Primero, la función getpwuid recupera una estructura en memoria (struct password*) que contiene información sobre el usuario dado. Luego, tccd extrae de ella el miembro pwdir. Este miembro pwdir incluye el directorio principal del usuario, y su valor persiste incluso después de que la variable de entorno $HOME sea modificada.
Si bien la solución previene un ataque por envenenamiento de variables de entorno, no protege contra el problema principal. Por lo tanto, nos propusimos investigar: ¿puede una aplicación cambiar mediante programación el directorio personal del usuario y plantar un archivo TCC.db falso?
The first POC exploit
Nuestro primer intento de responder a la pregunta anterior fue sencillo: plantar un archivo TCC.db falso y cambiar el directorio de inicio utilizando la utilidad de línea de comandos de los Servicios de Directorio (dscl):
Aunque requiere acceso de root, descubrimos que esto sólo funciona si la aplicación tiene concedida la política TCC kTCCServiceSystemPolicySysAdminFiles, que mantiene el TCC.db local o específico del usuario. Eso es más débil que tener acceso completo al disco, pero logramos saltarnos esa restricción con las utilidades dsexport y dsimport.
A continuación, simplemente exportando la entrada de Servicios de Directorio de un usuario, manipulando el archivo de salida, e importando el archivo de nuevo, logramos eludir la restricción de la política TCC de dscl.
Nuestro primer exploit POC, por lo tanto, hace lo siguiente:
- Obtener un blob csreq para la aplicación de destino.
- Colocar un archivo TCC.db falso con el 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 principal del usuario.
- Importe la entrada modificada de Servicios de Directorio con dsimport.
- Detener el tccd del usuario y reiniciar el proceso.
Usando este exploit, un atacante podría cambiar la configuración de cualquier aplicación. En la siguiente captura de pantalla, mostramos cómo el exploit podría permitir a los atacantes habilitar el acceso al micrófono y a la cámara en cualquier aplicación, por ejemplo, Teams.
Monterey release and the second POC exploit
Microsoft compartió los hallazgos con Apple a través de Coordinated Vulnerability Disclosure (CVD) vía Microsoft Security Vulnerability Research (MSVR) antes del lanzamiento de macOS Monterey en octubre. Sin embargo, tras el lanzamiento de dicha versión, nos dimos cuenta de que nuestro exploit POC inicial ya no funcionaba debido a los cambios realizados en el funcionamiento de la herramienta dsimport. Por lo tanto, buscamos otra forma de cambiar el directorio de inicio de forma silenciosa.
Mientras examinábamos macOS Monterey, nos encontramos con /usr/libexec/configd, un binario de Apple incluido en la última versión de macOS que es un demonio de configuración del sistema responsable de muchos aspectos de la configuración del sistema local. Hay tres aspectos de configd de los que tomamos nota y aprovechamos:
- Es un binario firmado por Apple con el título «com.apple.private.tcc.allow» con el valor kTCCServiceSystemPolicySysAdminFiles. Esto significa que puede cambiar el directorio de inicio de forma silenciosa.
- Tiene extensibilidad en los agentes de configuración, que son paquetes de macOS bajo el capó. Esto sugiere que podría cargar un Bundle personalizado, lo que significa que podríamos inyectar código para nuestros propósitos.
- No tiene el indicador de tiempo de ejecución endurecido para cargar agentes de configuración personalizados. Aunque este aspecto es probablemente por diseño, también significa que podríamos cargar código completamente sin firmar en él.
Al ejecutar configd con la opción -t, un atacante podría especificar un Bundle personalizado para cargar. Por lo tanto, nuestro nuevo exploit POC reemplaza el método dsexport y dsimport de cambiar el directorio de inicio del usuario con una inyección de código configd. Esto resulta en el mismo resultado que nuestro primer exploit POC, que permite la modificación de la configuración para conceder, por ejemplo, cualquier app como Teams, para acceder a la cámara, entre otros servicios.
