Los investigadores de Palo Alto Networks Unit 42 publicaron un estudio sobre tres técnicas de postexplotación que permiten a malware que se ejecuta con privilegios de usuario estándar en un sistema Windows con TPM autenticarse en cuentas de la víctima protegidas con passkey, sin biometría, sin PIN y sin ningún tipo de notificación en pantalla. Los ataques van dirigidos contra Google Password Manager en el navegador Chrome y no rompen la criptografía de WebAuthn, sino que aprovechan características del almacenamiento de claves, de la lógica de registro de dispositivo repetido y de la comprobación del flag de verificación de usuario en el lado de los servicios web. No se han registrado casos de explotación en ataques reales, no se han asignado identificadores CVE y el estado completo de las correcciones sigue siendo desconocido.
Supuestos arquitectónicos de los ataques
Los tres métodos — Pass-ta-key, Silver Pass-ta-key y Golden Pass-ta-key — requieren la ejecución previa de código malicioso en el dispositivo de la víctima. Se trata de técnicas de postexplotación: describen qué puede hacer un atacante en una máquina ya comprometida, no el método de intrusión inicial.
Según los investigadores, Chrome almacena las credenciales sincronizadas en el directorio %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, y un proceso sin privilegios es capaz de leer los metadatos, incluidos los identificadores de los servicios (relying party), los nombres de usuario, los identificadores de credenciales y el material cifrado de claves privadas.
Una característica arquitectónica clave queda confirmada por el código fuente de Chromium: Chrome crea una clave TPM sin nombre (lo que, según el comentario en el código, impide que se guarde en disco), la exporta como un blob opaco y luego la vuelve a cargar. Para la firma se utiliza el flag NCryptSignHash, que suprime cualquier solicitud al usuario. En ese mismo archivo hay un comentario TODO con un enlace al issue Chromium 398125799, que propone marcar este tipo de claves.
Tres vectores de ataque
Pass-ta-key: evasión sin verificación de usuario
El primer método extrae la clave de identificación de dispositivo de Chrome ya envuelta y, a través de la API Windows CNG, solicita al mismo TPM una firma para una petición controlada por el atacante. El autenticador en la nube de Google devuelve una assertion válida que solo se diferencia de la legítima en un bit: el flag User Verified (UV), que permanece sin establecer.
De acuerdo con la especificación Web Authentication Level 3, si el servicio establece el parámetro userVerification en el valor «required», está obligado a rechazar la autenticación si falta el bit UV. Según Unit 42, GitHub realizaba esta comprobación correctamente, mientras que eBay aceptaba dichas assertions hasta que corrigió el problema tras la divulgación de la información.
Silver Pass-ta-key: suplantación de la clave de verificación
El segundo método se dirige al proceso de registro repetido del dispositivo. El malware fuerza la nueva inscripción de Chrome y, en la ventana temporal que se crea —cuando el navegador todavía no ha generado la clave de verificación de usuario—, el atacante registra su propia clave. El código fuente de Chromium confirma la existencia del estado deferred_uv_key_creation para los dispositivos recién registrados.
Según los investigadores, el lado servidor no comprueba si la nueva clave registrada se ha obtenido de un módulo de seguridad de hardware. Las assertions firmadas con la clave suplantada llevan el flag UV establecido, lo que, según se indica, permite autenticarse desde el dispositivo del atacante sin necesidad de acceder a la máquina de la víctima. No obstante, el código público de Chromium no permite verificar de forma independiente la parte de servidor de este ataque para la versión estable actual de Chrome.
Golden Pass-ta-key: extracción del secreto maestro
El tercer método, el más grave, se dirige al Security Domain Secret (SDS) El código fuente de Chromium confirma que Chrome crea u obtiene secretos de dominio de seguridad de 32 bytes en estructuras de datos del proceso cliente. Sin embargo, la fiabilidad de la extracción, la posibilidad de tomar el control de la cuenta y la conservación del acceso cuando cambian las epochs del secreto siguen sin estar respaldadas por fuentes independientes. Los investigadores señalan que Google eliminó una fuga previa de SDS a través de los FIDO logs de Chrome; sin embargo, el secreto sigue llegando a la memoria del cliente, lo que no cierra el vector descrito. La divulgación no aclara si se han cerrado los tres vectores de ataque. El estudio no incluye identificadores CVE, ni una lista de versiones afectadas de Chrome, ni el estado completo de las correcciones. La documentación pública de Google permite a los usuarios cambiar el PIN de Google Password Manager o eliminar todos los datos del gestor de contraseñas, pero no describe un mecanismo de rotación o revocación del SDS. Sigue abierta una cuestión crítica: si cambiar el PIN o eliminar los datos invalida el secreto que ya ha sido extraído por el atacante. El impacto se limita a los usuarios de Chrome en Windows con TPM que utilizan Google Password Manager para sincronizar passkeys. Dos de los tres métodos (Silver y Golden Pass-ta-key), según los investigadores, permiten restablecer el acceso desde el entorno del atacante tras la primera intrusión, lo que convierte un incidente puntual en un canal persistente de acceso a las cuentas de la víctima. Es importante tener en cuenta el contexto: todas las técnicas requieren la ejecución previa de código en el dispositivo. No se trata de un ataque remoto contra la tecnología passkey como tal, sino de una ampliación de las capacidades de un atacante que ya se ha afianzado en el sistema. No obstante, para las organizaciones que consideran las passkeys como un sustituto de las contraseñas con mayor resistencia a la compromisión, estos hallazgos demuestran que el panorama de postexplotación es más complejo de lo que se pensaba. Para operadores de servicios web (relying party): Para proveedores de credenciales (credential providers): Para usuarios finales: El estudio de Unit 42 pone de manifiesto un problema sistémico: la seguridad de las passkeys depende no solo de la criptografía, sino de toda la cadena, desde el almacenamiento de claves en el dispositivo hasta la validación en el servidor. Mientras Google no publique una respuesta oficial con la confirmación del estado de las correcciones y del mecanismo de rotación del SDS, las organizaciones deberían, como mínimo, asegurarse de que sus servicios web comprueban estrictamente el flag UV, y los usuarios deberían mantener actualizada su versión de Chrome y controlar la protección de sus endpoints.Incertidumbre sobre el estado de las correcciones
Evaluación del impacto
Recomendaciones
