Gestor de contraseñas de Google afectado por las nuevas vulnerabilidades Pass-ta-key

La adopción masiva de las llaves de acceso (passkeys) ha sido aclamada como el hito definitivo para erradicar las vulnerabilidades asociadas al robo de credenciales tradicionales. Al reemplazar combinaciones de usuario y clave por pares de claves criptográficas asimétricas integradas en hardware o sincronizadas en la nube, el ecosistema digital parecía haber encontrado un refugio inexpugnable contra el phishing y los ataques de fuerza bruta. Sin embargo, un análisis técnico detallado publicado por el equipo de inteligencia de amenazas Unit 42 de Palo Alto Networks revela que la transición hacia un futuro sin contraseñas alberga sus propios vectores de ataque complejos. Al examinar cómo el gestor de contraseñas de Google implementa la sincronización de credenciales en el navegador Chrome para Windows equipado con un Módulo de Plataforma de Confianza (TPM), los investigadores identificaron tres técnicas de explotación inéditas: Pass-ta-key, Silver Pass-ta-key y Golden Pass-ta-key.

Estas investigaciones no rompen la criptografía subyacente del estándar WebAuthn ni comprometen los algoritmos matemáticos que respaldan a la infraestructura de clave pública (PKI). En su lugar, los ataques aprovechan vulnerabilidades en los procesos de confianza del dispositivo, la incorporación (onboarding), la recuperación en la nube y la falta de validación estricta en los servidores receptores. La premisa fundamental de estos hallazgos es crítica para los profesionales de la ciberseguridad: cuando un programa malicioso (malware) logra ejecutarse con privilegios de usuario estándar en un entorno Windows comprometido, es capaz de manipular el comportamiento circundante de Chrome para secuestrar cuentas, eludir la verificación biométrica y extraer en forma definitiva las claves privadas almacenadas.

Anatomía del Entorno: El Gestor de Contraseñas de Google y la Autenticación Sincronizada

Para comprender el alcance de los vectores Pass-ta-key, es necesario desglosar el flujo de arquitectura que utiliza el gestor de contraseñas integrado en Google Chrome sobre sistemas Windows dotados de TPM. Cuando un usuario guarda una passkey en su cuenta de Google a través de Chrome, la credencial no permanece aislada exclusivamente en el hardware local. Para permitir una experiencia cross-device fluida, Google utiliza un autenticador en la nube (Cloud Authenticator) que sincroniza los registros entre múltiples dispositivos mediante una infraestructura de enclaves seguros (accesible a través de dominios como enclave.ua5v.com).

En el endpoint de Windows, los metadatos y registros sincronizados de las credenciales se almacenan localmente en una base de datos LevelDB accesible mediante la ruta:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

Un aspecto determinante descubierto por Unit 42 es que cualquier proceso que se ejecute bajo el contexto del usuario actual —sin necesidad de elevados privilegios de administrador (SYSTEM o UAC elevation)— puede leer el contenido de esta base de datos. Si bien las claves privadas no se encuentran expuestas directamente en texto plano en la estructura LevelDB, la base de datos contiene una hoja de ruta completa de la identidad del usuario: identificadores de credenciales (credential IDs), nombres de usuario, dominios de servicio (RP ID) y blobs criptográficos cifrados. Con esta información previa, el malware local puede iniciar la cadena de ataques Pass-ta-key aprovechando los propios mecanismos de la API de Windows y la identidad de dispositivo emitida por el TPM.

Desglose Técnico de los Vectores de Ataque: De Pass-ta-key a Golden Pass-ta-key

Los tres métodos identificados por Unit 42 operan en diferentes niveles de profundidad, escalando desde la generación silenciosa de firmas instantáneas hasta el compromiso permanente del secreto maestro de la cuenta.

1. Pass-ta-key: Impersonación de Dispositivo de Confianza

El primer vector, denominado Pass-ta-key, permite a un malware sin privilegios de administrador hacerse pasar por el dispositivo de confianza del usuario frente al autenticador en la nube de Google. En un flujo legítimo, Chrome genera una clave de identidad de dispositivo respaldada por el TPM de Windows. No obstante, en la implementación examinada, dicha clave se gestiona mediante blobs de claves temporales que el software puede operar mediante las APIs criptográficas estándar de Windows.

El proceso de explotación ocurre sin que el usuario note ninguna actividad en pantalla:

• El malware lee los metadatos de la passkey desde la estructura Sync Data\LevelDB de Chrome.
• Utilizando las llamadas a la API del sistema dentro de la sesión activa del usuario, el código malicioso firma una solicitud de autenticación dirigida al Cloud Authenticator de Google simulando ser el navegador Chrome.
• El servicio en la nube de Google valida que la firma proviene de un dispositivo previamente registrado y confiable, respondiendo con una aseveración (assertion) WebAuthn válida para iniciar sesión en el servicio objetivo.

El ataque se ejecuta sin solicitar escaneo de huella dactilar, reconocimiento facial, PIN de Windows Hello ni interacción humana alguna. No obstante, la aseveración generada mediante Pass-ta-key carece del indicador de verificación de usuario activado (la flag User Verified / UV se establece en false). Durante las pruebas de laboratorio, los investigadores notaron que servicios como GitHub rechazaron correctamente el intento de inicio de sesión debido a que su servidor exige de forma estricta el flag UV=true. Sin embargo, otras plataformas como eBay aceptaron la aseveración en su momento al no validar rigurosamente la presencia de la verificación humana, permitiendo el compromiso inmediato de la cuenta.

2. Silver Pass-ta-key: Inyección de Llaves de Verificación y Persistencia Externa

Para superar la limitación de la flag User Verified, Unit 42 ideó el ataque Silver Pass-ta-key. Esta técnica abusa de los flujos de reincorporación (re-onboarding) y recuperación de estado en Google Chrome cuando los archivos de estado local se dañan o eliminan.

El malware elimina o altera intencionalmente los archivos de estado de las passkeys locales en el perfil de Chrome, forzando al navegador a entrar en un proceso de re-registro contra el Cloud Authenticator de Google. Durante esta ventana de re-onboarding, la aplicación maliciosa intercepta o inyecta una nueva clave de verificación de usuario controlada por el atacante. El servidor en la nube de Google asocia esta nueva clave como un método de verificación legítimo para el dispositivo.

A partir de este instante, el atacante puede calcular firmas que incluyan explícitamente la flag User Verified (UV = true). Esto otorga al adversario la capacidad de:

1. Burlar las protecciones de servidores exigentes (como GitHub) que requieren validación biométrica o PIN.
2. Exportar los parámetros de autenticación a una máquina remota bajo el control del atacante, manteniendo el acceso persistente a la cuenta de la víctima incluso si el equipo original se apaga o la sesión de malware local finaliza.

3. Golden Pass-ta-key: Exfiltración del Security Domain Secret (SDS)

La variante más severa y destructiva es Golden Pass-ta-key. Este ataque no se limita a solicitar aseveraciones al servidor en la nube; en su lugar, apunta directamente a la raíz criptográfica del vault sincronizado: el Security Domain Secret (SDS).

El SDS es un secreto maestro de 32 bytes utilizado por el ecosistema de Google para cifrar de extremo a extremo las llaves privadas de las passkeys sincronizadas entre dispositivos. Sin embargo, al explotar las fallas en el flujo de recuperación y descifrado de credenciales desde el contexto del sistema infectado, Golden Pass-ta-key permite al malware extraer el blob de 32 bytes del SDS en texto plano.

Una vez que el atacante obtiene el Security Domain Secret, el impacto es catastrófico:

• El atacante descarga la base de datos cifrada de passkeys de la víctima desde los servidores de sincronización.
• Descifra offline y de forma irrestricta absolutamente todas las claves privadas guardadas en el gestor de contraseñas de Google.
• Las passkeys extraídas pueden ser importadas en hardware o software externo, vendidas en mercados negros de credenciales o utilizadas indefinidamente sin requerir acceso continuo a la computadora comprometida ni depender de la presencia del Módulo de Plataforma de Confianza (TPM) original.

Implicaciones para el Paradigma Passwordless y la Seguridad Empresarial

El descubrimiento de los ataques Pass-ta-key marca un punto de inflexión en la percepción de seguridad que rodea a las tecnologías sin contraseñas. Durante años, la industria ha promovido las passkeys como una solución definitiva contra el robo de credenciales. Sin embargo, la investigación de Unit 42 demuestra que la seguridad de una passkey sincronizada está estrictamente acotada por la postura de seguridad del endpoint donde opera el navegador.

Es vital recalcar que estos métodos son técnicas post-compromiso (post-exploitation). El atacante debe contar previamente con acceso de ejecución de código en la sesión del usuario para poder manipular la base de datos LevelDB de Chrome y la API de Windows. No obstante, en un entorno corporativo donde el robo de información mediante infostealers es un vector primario de intrusión, la capacidad de extraer claves privadas o suplantar verificaciones biométricas degrada significativamente las garantías del estándar FIDO2/WebAuthn.

Adicionalmente, el caso deja al descubierto una falla sistémica en la validación del lado del servidor (Relying Party). Muchos servicios web adoptaron passkeys simplemente verificando la firma de la clave pública, omitiendo la inspección obligatoria de la flag