Ataques Pass-ta-key: cómo los hackers pueden secuestrar tus passkeys de Google
Investigadores de seguridad han descubierto tres ataques que permiten que malware en dispositivos Windows ya comprometidos abuse de los passkeys sincronizados de Google Password Manager para tomar control de cuentas, evadir la verificación de usuario y extraer claves privadas de passkeys. Los passkeys son un método de autenticación sin contraseña que utiliza claves criptográficas almacenadas en el dispositivo del usuario para iniciar sesión en cuentas en línea. Se consideran más seguros que las contraseñas porque no pueden adivinarse, reutilizarse ni robarse fácilmente mediante phishing, y además permiten autenticarse con PIN o datos biométricos.
Sin embargo, un nuevo informe de Unit 42 de Palo Alto Networks demuestra tres ataques novedosos, denominados colectivamente 'Pass-ta-key', que apuntan a Google Password Manager en Chrome en dispositivos Windows equipados con Trusted Platform Module (TPM). Todos los ataques requieren que el malware ya esté ejecutándose en el ordenador de la víctima y no rompen la criptografía utilizada por los passkeys. En su lugar, explotan debilidades en cómo Chrome y el autenticador en la nube de Google manejan la confianza del dispositivo, el onboarding, la recuperación y las credenciales sincronizadas.
Primera técnica: Pass-ta-key
La primera técnica, llamada Pass-ta-key, permite que malware sin privilegios se haga pasar por un dispositivo confiable y solicite una respuesta de autenticación válida para uno de los passkeys de la víctima. El malware abusa de la clave de identidad del dispositivo respaldada por TPM de Chrome para firmar una solicitud enviada al autenticador en la nube de Google. Esto puede hacerse sin privilegios de administrador, interacción del usuario, biometría o desbloqueo del dispositivo. El autenticador en la nube de Google trata la solicitud como si viniera del ordenador confiable de la víctima y devuelve una respuesta de autenticación firmada, conocida como 'assertion', que puede usarse para iniciar sesión en la cuenta objetivo.
Sin embargo, la respuesta incluye una marca de Usuario Verificado que indica si se realizó verificación biométrica o de PIN. Esto hace que el ataque falle si un servicio requiere y valida correctamente que la verificación de usuario fue exitosa. Mientras que el ataque falló contra GitHub, que verifica correctamente esta marca, Unit 42 dice que lo probó con éxito contra eBay. Aunque eBay requería verificación de usuario, no validaba adecuadamente la marca que indicaba si esa verificación ocurrió. eBay ha solucionado el problema después de que los investigadores lo informaran.
Segunda técnica: Silver Pass-ta-key
La segunda técnica, llamada Silver Pass-ta-key, va más allá y permite a los atacantes registrar su propia clave de verificación de usuario con el autenticador en la nube de Google. El atacante primero usa malware en el dispositivo comprometido para forzar a Chrome a re-registrarlo invalidando su clave de verificación existente o eliminando el archivo local que contiene el estado de sus passkeys. Durante el proceso de re-registro, el atacante puede registrar una clave de verificación de usuario que controla porque el autenticador en la nube no valida si la nueva clave proviene de hardware confiable.
Google luego acepta solicitudes firmadas con la clave del atacante como prueba de que la víctima desbloqueó el dispositivo con un PIN o datos biométricos. Esto permite al atacante acceder a cuentas que requieren y validan correctamente la verificación de usuario. Una vez que la clave maliciosa está registrada, el atacante puede autenticarse desde otro sistema sin necesidad de acceso adicional al ordenador de la víctima.
Tercera técnica: Golden Pass-ta-key
La tercera y más grave técnica, llamada Golden Pass-ta-key, permite que el malware obtenga la clave maestra utilizada para cifrar todos los passkeys sincronizados a través de la cuenta de Google Password Manager de la víctima. Esta clave maestra, conocida como secreto del dominio de seguridad, se envía temporalmente a Chrome cuando un dispositivo se registra o recupera el acceso a la cuenta. Unit 42 inicialmente encontró que Chrome exponía el secreto en texto plano a través de sus registros FIDO internos. Google eliminó el secreto de los registros después de que los investigadores lo informaran, pero Unit 42 dice que aún se envía a Chrome y permanece temporalmente accesible en la memoria del proceso del navegador.
Aunque Google eliminó este secreto de la salida de registro de Chrome tras nuestro informe, el SDS todavía se envía al cliente y permanece accesible en la memoria del proceso de Chrome. Si el atacante fuerza a la víctima a re-registrarse con el autenticador en la nube y conoce el patrón a buscar, puede extraer el SDS directamente de la memoria.
El atacante puede entonces usar la clave maestra robada para descifrar los registros de passkeys sincronizados de la víctima y recuperar sus claves privadas. Esas claves privadas pueden transferirse a otro sistema y usarse para hacerse pasar por la víctima e iniciar sesión en sus cuentas. Unit 42 advierte que la clave maestra robada también podría usarse para descifrar futuros passkeys sincronizados a la cuenta. Según los investigadores, la implementación actual de Google no proporciona forma de rotar o revocar la clave, lo que significa que los passkeys sincronizados actuales y futuros permanecen protegidos por el mismo secreto.
Recomendaciones y respuesta
Aunque los investigadores dicen que los passkeys siguen siendo significativamente más seguros que las contraseñas tradicionales, los ataques demuestran que no eliminan los riesgos planteados por el malware que ya se ejecuta en un dispositivo comprometido. Unit 42 recomienda que los sitios web requieran y validen correctamente la verificación de usuario. Los gestores de credenciales también deberían validar las nuevas claves de dispositivos registrados, endurecer los procesos de recuperación y re-registro de dispositivos, y evitar que las claves maestras sean accesibles en la memoria del navegador.
Los investigadores revelaron los ataques contra Google Password Manager a Google y reportaron fallas relacionadas con la verificación de usuario a servicios afectados, incluido eBay, antes de publicar sus hallazgos. BleepingComputer contactó a Google para obtener comentarios sobre los hallazgos de Unit 42 y preguntar si los ataques descritos han sido completamente abordados, pero no se obtuvo respuesta inmediata.
