En mi artículo anterior, hice una introducción al marco de Transparencia, Consentimiento y Control (TCC) de Apple. El objetivo principal de TCC es darles a los usuarios transparencia sobre cómo las aplicaciones acceden a sus datos y los usan. Esta vez, vamos a profundizar en el mecanismo que ejecuta TCC y en lo que ocurre detrás de escena.
El marco principal
TCC se administra mediante un binario tccd en el directorio System, en /System/Library/PrivateFrameworks/TCC.framework/Support/tccd. Vale la pena mencionar que antes este binario estaba ubicado dentro del directorio /Versions/A/ en el paquete .framework, pero desde entonces se movió.
Hay un aspecto de la terminología de TCC que quiero cubrir antes de profundizar demasiado. Hablaremos principalmente de dos () cuando nos refiramos al marco TCC: con frecuencia mencionaremos un cliente y un servicio. En este caso, el cliente es la aplicación que solicita el permiso, como Zoom, mientras que el servicio es el permiso que se solicita, como el acceso a la cámara o al micrófono. El cliente solicita acceso a un servicio.
Si extraemos las cadenas de este binario, podemos ver los diferentes servicios que cubre TCC, aunque sus nombres no son necesariamente claros.
Cuando observamos nuestras bases de datos de TCC, una de las columnas que veremos es service. Dentro de este campo de servicio, veremos uno de los valores anteriores, que relaciona la aplicación solicitante con el servicio solicitado.
Cuando un usuario, por ejemplo, quiere usar su micrófono en un programa que todavía no ha solicitado acceso, Apple mostrará una ventana emergente, preguntándole al usuario si quiere "Permitir" o "No permitir" el acceso. Estas ventanas pueden verse distintas según el servicio. Podemos extraer el contenido de la lista de propiedades binaria (plist) ubicada en /System/Library/PrivateFrameworks/TCC.framework/Resources/Localizable.loctable, y ver algunas de las ventanas de Apple en la plist.
<key>en</key>
<dict> <key>NOTIFY_BUTTON_kTCCServiceSystemPolicyAppBundles</key>
<string>Allow…</string>
<key>NOTIFY_SERVICE_kTCCServiceSystemPolicyAppBundles</key>
<string>"%@" was prevented from modifying apps on your Mac.</string> <key>REQUEST_ACCESS_ADD_MODIFY_ADDED</key> <string>Keep Add Only</string> <key>REQUEST_ACCESS_ADD_kTCCServiceCalendar_ADD</key> <string>OK</string> <key>REQUEST_ACCESS_ALLOW</key> <string>Allow</string> <key>REQUEST_ACCESS_ALLOW_kTCCServiceFocusStatus</key> <string>OK</string> <key>REQUEST_ACCESS_ALLOW_kTCCServiceGameCenterFriends</key> <string>Allow</string> <key>REQUEST_ACCESS_ALLOW_kTCCServicePhotos</key> <string>Allow Access to All Photos</string> <key>REQUEST_ACCESS_DENY</key> <string>Don't Allow</string> <key>REQUEST_ACCESS_DENY_kTCCServiceFocusStatus</key> <string>Don't Allow</string>
truncado
En nuestro caso, este es el par clave/valor que se aplica a nuestro caso de uso específico, donde %@ es el cliente que hace la solicitud.
<key>REQUEST_ACCESS_SERVICE_kTCCServiceMicrophone</key>
<string>“%@” would like to access the microphone.</string>
Examinemos nuestra base de datos TCC a nivel raíz, ubicada en /Library/Application Support/com.apple.TCC.db, demos un vistazo a una entrada y relacionemos las columnas con los valores. En este caso, estamos viendo la extensión del sistema de la herramienta Red Canary Mac Monitor de Red Canary.
kTCCServiceEndpointSecurityClient - service (una extensión del sistema con el permiso de Endpoint Security)
com.redcanary.agent.securityextension - client (por lo general, el Bundle Identifier (o la ruta) del cliente que hace la solicitud)
0 - client_type (el cliente es un bundle ID(0) o una ruta absoluta(1), algo común en herramientas de depuración o proyectos de Xcode)
2 - auth_value (acción tomada por el usuario - denegado(0), desconocido(1), permitido(2), limitado(3))
4 - auth_reason (cómo el usuario realizó la acción)
1 - auth_version
"X'212 bytes'" - csreq (blob binario)
NULL - policy_id
0 - indirect_object_identifier_type
UNUSED - indirect_object_identifier (bundle ID o ruta absoluta de la interacción del cliente)
NULL - indirect_object_code_identity (identidad del código del objeto indirecto)
0 - flags
1681493977 - last_modified (la última vez que se modificó, en tiempo epoch)
NULL - pid
NULL - pid_version
UNUSED - boot_uuid
0 - last_reminded
Entender estos distintos campos puede ayudarnos a navegar todo lo que TCC está rastreando.
Anulaciones de MDM
Una advertencia curiosa de TCC es el archivo MDMOverrides.plist ubicado en el mismo directorio com.apple.TCC. Esta lista de propiedades binaria contiene permisos TCC específicos de MDM. A través de los MDM, los administradores pueden implementar payloads, llamados payloads PPPC, que se agregan a System Settings > Profiles. Aquí, los administradores pueden especificar qué permisos TCC quieren habilitar o no. Esto es fundamental para permitir que los administradores implementen software de forma silenciosa, ejecuten comandos en el endpoint, y mucho más.
Sin embargo, como estos permisos se agregan al MDMOverrides.plist, en lugar del TCC.db, a veces no se reflejan en la interfaz. Esto puede hacer que la resolución de problemas de implementación sea tediosa al intentar comparar archivos. Mientras tanto, la mayoría de los usuarios no pueden ayudar, ya que la interfaz permanece sin cambios.
También hemos visto casos donde los MDM otorgan permisos demasiado amplios a algunos binarios del sistema. En un caso, observamos que un MDM le daba acceso total al disco (FDA) a bash para su payload principal listo para usar. Lamentablemente, en lugar de darle permisos solo a su propio agente firmado y luego llamar a bash desde ese agente, le dieron (y siguen dando) a bash carta blanca sobre todo el sistema. Cuando descubrí esto, revisé mis permisos TCC en la interfaz, luego revisé la base de datos sqlite real, mediante sqlite3 /Library/Application Support/com.apple.TCC/TCC.db, antes de darme cuenta de que esto estaba enterrado casi a la mitad de mi archivo MDMOverrides. Aunque entiendo la idea de diseño de Apple detrás de esto —hacer que los MDM puedan operar detrás de escena para agregar estos permisos—, si los administradores no son conscientes del efecto de los payloads que implementan, esto podría ser una forma fácil para que un actor de amenazas viva del terreno sin ser detectado.
Para cerrar
TCC es posiblemente una de las principales funciones de seguridad orientadas al usuario que ofrece Apple de forma predeterminada, y es una de las primeras líneas de defensa contra el abuso en disco. Entender sus componentes y su funcionamiento puede ayudar a los profesionales de seguridad, a los administradores e incluso a los usuarios finales a navegar su laberinto.
La próxima vez, en Full Transparency, hablaremos de la lista de propiedades MDMOverrides y de todos los matices que contiene.
