- Apple corrigió CVE-2024-54471 en macOS Sequoia 15.1, Sonoma 14.7.1 y Ventura 13.7.1, distribuidos el 28 de octubre de 2024; en sistemas sin actualizar, las credenciales guardadas podían quedar expuestas a través de NetAuthAgent
- El núcleo del problema era que el servidor MIG de NetAuthAgent dejaba expuestas rutinas para consultar, crear y sobrescribir parcialmente credenciales de servidores de archivos sin verificar al remitente del mensaje
- Un atacante podía enviar mensajes al servicio Mach
com.apple.netauth.user.guipara hacer que consultara en su nombre entradas de tipointernet passworddel Keychain y obtener nombre de usuario y contraseña - El impacto no se limitaba a las credenciales de FTP, Samba, WebDAV y servidores de impresión guardadas desde “Connect to Server” de Finder, sino que mediante otra cadena también podía llegar a la exposición de datos de cuenta de iCloud y tokens de API
- Tras el parche, NetAuthAgent inspecciona los audit token de los mensajes Mach para revisar el entitlement del proceso remitente, y no responde si no tiene
com.apple.private.netauth.useragent.allow=true
Alcance del parche de CVE-2024-54471
- CVE-2024-54471 es una vulnerabilidad de macOS corregida dentro de las actualizaciones de seguridad de Apple
- Las versiones que incluyen el parche fueron lanzadas el 28 de octubre de 2024
- macOS Sequoia 15.1
- macOS Sonoma 14.7.1
- macOS Ventura 13.7.1
- Cualquier equipo con macOS que no se haya actualizado a esas versiones debe actualizarse de inmediato
IPC de macOS y la arquitectura basada en Mach
- El kernel de macOS y de la mayoría de los sistemas operativos de Apple es XNU, un kernel híbrido que incluye componentes de la familia BSD y una variante muy modificada del kernel Mach
- Incluso en el macOS moderno, Mach se basa en cuatro abstracciones
- task: entorno de ejecución donde corren los hilos y unidad básica de asignación de recursos
- thread: unidad básica de uso de CPU
- port: canal de comunicación que corresponde a una cola de mensajes protegida por el kernel
- message: conjunto de objetos de datos tipados usados para la comunicación entre hilos
- Los puertos de Mach no se tratan como colas expuestas directamente al espacio de usuario, sino como port right dentro del espacio de nombres de puertos de cada task
- Hay dos privilegios principales
- send right: puede estar en manos de varios task para el mismo puerto
- receive right: solo puede tenerlo un único task
- Esta estructura crea un modelo cliente-servidor en el que un task servidor recibe mensajes de varios task cliente
- El bootstrap server de macOS entrega un puerto sobre el que todos los task tienen send right y permite que los clientes pidan el send right de servicios Mach registrados por nombre de cadena
El hueco de autenticación en el servidor MIG
- MIG es una herramienta que envuelve el envío y recepción de mensajes Mach en una interfaz funcional
- MIG está compuesto por un pseudo-IDL en C y un compilador, y desde un archivo IDL genera los siguientes archivos
- código fuente en C para el cliente
- código fuente en C para el servidor
- encabezados C usados por ambos lados
- Cada función se llama routine, y al conjunto de routines se le llama subsystem; el número de subsystem y el índice de la routine se reflejan en el ID del mensaje
- Aunque en la comunicación de espacio de usuario en macOS MIG fue desplazado en gran parte por la API XPC, XPC también está construida sobre mensajes Mach
- El servidor MIG en sí no tiene un mecanismo de autenticación forzado, así que si el servidor no valida al remitente, cualquier task con send right puede invocar routines remotas
- Para explorar servidores MIG resulta útil el CLI ipsw de blacktop, usando un método que busca binarios que importan el símbolo
NDR_record- Este método encuentra no solo servidores MIG, sino también clientes MIG
- El código de servidor y cliente puede distinguirse con relativa facilidad en un desensamblador o descompilador
Las credenciales que maneja NetAuthAgent
- NetAuthAgent es un agente de usuario de macOS que maneja credenciales de servidores de archivos como FTP, Samba y WebDAV
- El cuadro de autenticación que aparece al conectarse a un servidor de archivos desde “Go → Connect To Server” en Finder lo proporciona NetAuthAgent o un proceso relacionado
- Si el usuario marca la casilla para guardar la contraseña, la credencial se almacena en el Keychain de macOS
- NetAuthAgent no guarda la contraseña directamente, sino que usa el Keychain como un almacén central de secretos
- Las entradas del Keychain tienen su propia lista de control de acceso, por lo que normalmente una aplicación no puede acceder a secretos a los que no debería tener acceso
- Sin embargo, si un proceso expone un mecanismo para hacer consultas al Keychain en nombre de otro proceso, todo el modelo de seguridad puede debilitarse
El servicio MIG vulnerable de NetAuthAgent
- NetAuthAgent exponía un servidor MIG que podía encontrarse a través del bootstrap server
- El nombre del servicio es
com.apple.netauth.user.gui - Este servidor ofrecía routines para leer, crear y en algunos casos sobrescribir credenciales de servidores de archivos
- Antes del parche, estas routines no validaban al remitente del mensaje
- La routine 19, con ID de mensaje 40219, podía hacer de proxy para consultar entradas de la clase
internet passworddel Keychain - Esta routine recibía un diccionario de opciones serializado como descriptor de datos out-of-line y devolvía el nombre de usuario y la contraseña como dos descriptores de datos out-of-line
Flujo del ataque y estructura del PoC
- El PoC usa la herramienta de investigación de seguridad Kass, escrita en Swift, para manejar mensajes Mach y clientes MIG
- El cliente de NetAuthAgent se define con los siguientes valores
- nombre del servicio:
com.apple.netauth.user.gui - ID de routine según el subsystem: 40200
- nombre del servicio:
- Las opciones de consulta se serializan en formato Property List y pueden incluir campos como
Scheme,Host,AlternatePortyPath - La API de Keychain de macOS
SecItemCopyMatchingpuede usarse para obtener metadatos de entradas del Keychain desde procesos no autorizados, siempre que no se pida el valor secreto - Como la lista de control de acceso también es metadato, era posible verificar si la lista de aplicaciones confiables de una entrada incluía
/System/Library/CoreServices/NetAuthAgent.app - El código del ataque podía recorrer entradas
internet passwordaccesibles para NetAuthAgent y extraer la siguiente información- nombre para mostrar
- protocolo
- host
- puerto
- ruta
- nombre de usuario
- contraseña
Impacto de la filtración de credenciales de servidores de archivos
- Antes del parche, un proceso malicioso que obtuviera send right hacia NetAuthAgent podía extraer todas las credenciales de servidores de archivos
- En entornos empresariales, esas credenciales podían ser credenciales de SSO, lo que abriría la posibilidad de acceder a múltiples recursos de sistemas corporativos
- No se sabe qué tan extendido es el uso de Connect to Server en Finder, pero varios documentos de ayuda de universidades e instituciones educativas indicaban a estudiantes y personal que usaran esta función, y algunos incluso recomendaban marcar la casilla para guardar en el Keychain
- También se encontraron guías de proveedores de servidores de impresión para conectar impresoras, y NetAuthAgent también maneja credenciales de servidores de impresión
- Al menos un documento recomendaba no marcar la casilla de guardar porque actualizar una contraseña guardada desde la app Keychain Access puede ser difícil para usuarios comunes
- Si en un dispositivo administrado se reutilizaban las mismas credenciales como credenciales de superusuario, esto podría haber llevado a una escalación de privilegios, aunque no se confirmó por falta de pruebas en equipos administrados
- También en el caso de un usuario particular que se conectara a un NAS desde Finder y guardara sus credenciales, esas credenciales del NAS podían quedar expuestas ante un atacante
- Si esas mismas credenciales se reutilizaban en otras cuentas de internet, esas cuentas también podían quedar comprometidas
- FTP, Samba y WebDAV tienen interfaces bien definidas, por lo que tras filtrar credenciales resulta fácil automatizar la exploración y extracción de archivos del servidor
Abuso adicional usando el Keychain
- Como NetAuthAgent también exponía routines para crear entradas del Keychain, un proceso malicioso podía ocultar datos arbitrarios dentro del campo
password - Este método podía servir como una forma de ocultación que evita escribir directamente en disco y podría ayudar a evadir software de seguridad
- No se conoce software de seguridad que inspeccione explícitamente entradas sospechosas del Keychain
- Un proceso malicioso también podía guardar credenciales legítimas en el Keychain
- Aunque por sí sola esta acción puede tener un efecto limitado, podría usarse en ataques más complejos donde el atacante guarda credenciales de un servidor de archivos bajo su control y luego manipula socialmente al usuario
Cadena de explotación que llegaba hasta tokens de API de iCloud
- Incluso los usuarios que no usan Connect to Server no estaban libres del impacto de esta vulnerabilidad
- La mayoría de los equipos macOS contienen entradas del Keychain con ACL lo bastante amplias como para que NetAuthAgent pudiera acceder a ellas
- Esa entrada del Keychain contiene una clave de descifrado para descifrar cierto archivo en disco
- Ese archivo incluye datos de la cuenta de iCloud y tokens de API del usuario
- Con la entrada del Keychain y el archivo en una ubicación conocida, un atacante podía obtener la siguiente información
- nombre y apellido
- dirección de correo electrónico
- alias de correo
- funciones y endpoints habilitados
- varios tokens de API de larga duración
Qué se podía hacer con los tokens de iCloud
- Una investigación previa de Wojciech Reguła mostró que los mismos tokens de API podían encontrarse por otros métodos y usarse para filtrar los siguientes datos
- Contacts
- Calendars
- Reminders
- ubicación del usuario a través de Find My
- De esos resultados, se reprodujeron todos excepto Reminders
- En cuentas nuevas y cuentas migradas, Reminders pasó a estar cifrado y accesible solo de forma cifrada, ya que Apple lo movió a CloudKit, más seguro
- Además, también eran posibles las siguientes acciones
- filtración de fotos de contactos
- consultas a CloudKit, aunque sin poder descifrar
- filtración de datos del iCloud key-value store
- filtración de metadatos de respaldos de iCloud, incluidos números de serie de dispositivos
- filtración de la ubicación de los otros dispositivos del usuario mediante Find My
- filtración de la ubicación de los amigos del usuario mediante Find My
- ejecutar acciones de bloqueo, borrado y reproducción de sonido mediante Find My
- Se investigó el descifrado de datos de CloudKit, pero no se logró completar
- No puede descartarse que proveedores comerciales de análisis forense usen estos tokens de API, y cuando sea necesario también el PIN de un dispositivo iOS, para descifrar datos de CloudKit o datos de CloudKit dentro de respaldos de iCloud
Cómo lo corrigió Apple
- Después del parche, NetAuthAgent primero verifica el entitlement del remitente al recibir un mensaje
- Un entitlement es un par key-value adjunto a un binario durante la firma de código
- En macOS con la configuración de seguridad estándar, Apple Mobile File Integrity revisa los restricted entitlement al ejecutar un proceso y lo termina si no cuenta con el provisioning profile adecuado
- Como el provisioning profile debe estar firmado por Apple, esta revisión está diseñada para ser difícil de eludir
- El entitlement que exige NetAuthAgent es el siguiente
- clave:
com.apple.private.netauth.useragent.allow - valor: boolean
true
- clave:
- NetAuthAgent no responde a remitentes que no tengan este entitlement
- El trailer que el kernel añade al recibir un mensaje Mach incluye un audit token
- El task receptor puede identificar al task remitente con ese audit token, pedirle al kernel el diccionario de entitlement de ese task y luego verificar el valor
El eslabón débil de la arquitectura de seguridad
- Aunque las credenciales de servidores de archivos se guarden de forma que solo ciertas aplicaciones puedan acceder a ellas, si una de esas aplicaciones acepta órdenes de consulta de otras aplicaciones, esa aplicación se convierte en el eslabón débil
- Aunque los tokens de API de iCloud estén guardados en un archivo cifrado en disco, si la clave de descifrado está en una entrada del Keychain con una ACL amplia, esa ACL se convierte en el eslabón débil
- macOS cuenta con mecanismos de seguridad que dificultan la inyección de procesos, y su infraestructura general de seguridad suele considerarse sólida
- Sin embargo, como muestra esta vulnerabilidad, una omisión tan simple como no validar al remitente puede terminar exponiendo credenciales de servidores de archivos y tokens de API de iCloud
Recomendaciones para usuarios
- Si todavía es posible, se recomienda activar Advanced Data Protection
- Si no se usa iCloud desde el navegador web, otra opción es desactivar el acceso web a los datos de iCloud
- El sitio web de iCloud a veces usa endpoints de API distintos a los de la app de iCloud de Apple
- Aunque con esta vulnerabilidad ya no se puede acceder a los tokens, pudieron haber quedado expuestos por vulnerabilidades anteriores y podrían volver a exponerse por otras futuras
- No hay evidencia de que este exploit haya sido usado o encontrado por actores maliciosos
- Aun así, si preocupa especialmente el abuso de credenciales, conviene cambiar las contraseñas
- Los equipos que no hayan actualizado macOS desde octubre de 2024 deben actualizarse de inmediato
1 comentarios
Opiniones en Hacker News
El artículo está bien escrito y me recordó al zero-day en el que se podía eludir el inicio de sesión como root intentando dos veces con la contraseña vacía, que Apple en cierta medida intentó tapar. Fue alrededor de 2017, quizá 2018.
En cualquier cuadro de inicio de sesión de root, si ponías un nombre de usuario administrador y dejabas la contraseña en blanco, la primera vez decía que la contraseña era incorrecta, pero al cerrar la advertencia y presionar una segunda vez, iniciaba sesión como ese usuario.
Ese día se reproducía el 100% de las veces y, tras difundirse en redes sociales, se parcheó poco después; aun así, parecía un oversight enorme. Parece que todavía quedan restos viejos alrededor de los mecanismos de autenticación de Mac, y también es interesante que se mencione el sistema de ports del kernel Mach.
Cuando el búfer del nombre de usuario llegó a 256 caracteres arbitrarios, XDM crasheó y abrió un shell de root. Aunque esto fue a principios de los 90, cuando todos éramos mucho más ingenuos respecto de la seguridad.
grep, y funcionaba el 100% de las veces.“ACLs don't”: https://waterken.sourceforge.net/aclsdont/current.pdf
El artículo recibió una pequeña corrección: la verificación de entitlements no está en la capa Mach del kernel.
https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3
Es un cambio de una sola palabra que corrige un error factual en la parte que explicaba el funcionamiento de XNU.
La parte que dice “si un proceso expone un mecanismo para que otro proceso efectivamente haga de proxy de consultas al keychain, puede debilitar la seguridad de todo el sistema” parece el problema del diputado confundido: https://en.wikipedia.org/wiki/Confused_deputy_problem
Un diseño basado en capabilities debería poder evitar sistemáticamente este tipo de problemas.
Me pregunto dónde publicó el autor el código PoC real. Quisiera probar un poco las mitigaciones, pero el código de ejemplo se ve incompleto.
¿Qué tan realista es el riesgo?
En cuanto al riesgo, una app que pueda obtener un send right hacia NetAuthAgent —en la práctica, casi cualquier app no sandboxed— puede pedirle silenciosamente a NetAuthAgent credenciales guardadas de unidades de archivos como FTP, WebDAV o Samba. Esto también puede derivar en la filtración completa de contactos y calendarios de iCloud, además de otros datos relacionados con iCloud.
El sandboxing lo vuelve más difícil, pero no imposible. Si estás al día, el riesgo es 0, y el parche entró en octubre del año pasado, así que, francamente, ya deberías tener la actualización. Si no actualizaste y tampoco piensas hacerlo, el riesgo es mucho mayor, a menos que revises absolutamente todos los procesos que se ejecutan en tu dispositivo.
Es un artículo muy detallado, y me gustó que incluso cubriera la historia de varios kernels. Dicho eso, si es un artículo sobre un problema de seguridad serio, estaría bien tener al principio una explicación muy breve del alcance del impacto, las condiciones de ataque y si se trata de un error lógico o de corrupción de memoria.
Con algo simple, apenas lo suficiente para decidir si leer el resto, basta.
Es un artículo realmente interesante. No sabía que hubiera tanta historia detrás de cómo se crearon Mach y el kernel Darwin.
A estas alturas, Mach se siente como una fuente constante de bugs de macOS. Sé que Apple lo está cerrando con mucho esfuerzo, pero ¿hay algún camino para salir por completo de Mach?
Si un daemon no verifica el entitlement, no es seguro. En vez de culpar al mecanismo de mensajería, hay que culpar a cómo se usa.
De hecho, cualquier sistema de mensajería restringido necesita algo más que simple entrega de mensajes, por ejemplo, verificación del remitente. No es algo que obtengas sin más de un protocolo de comunicación de bajo nivel como Mach, salvo que Apple modifique el compilador MIG para agregar verificaciones de entitlements.
Mach es excelente cuando se usa junto con verificaciones de entitlements.
Técnicamente, esto podría aumentar la superficie potencial de ataque al hacer que coexistan más componentes distintos. Pero una superficie más especializada puede simplificar el control y, en consecuencia, permitir protegerla mejor.