Un nuevo análisis de ciberseguridad advierte sobre ataques a Google Password Manager que podrían facilitar el secuestro de cuentas protegidas con passkeys. La clave del riesgo, según el reporte, no está en “romper” la criptografía, sino en el entorno que rodea al proceso de autenticación cuando ya existe malware ejecutándose en la máquina de la víctima.
En concreto, el estudio detalla tres rutas de ataque dirigidas al autenticador en la nube de Chrome para credenciales sincronizadas. Estas técnicas se centran en elementos como la forma en que Chrome guarda claves del dispositivo, cómo vuelve a inscribir el dispositivo tras ciertos estados internos y qué validaciones aplica el sitio que recibe la autenticación.
Por qué el problema no es la criptografía
De acuerdo con los investigadores, la criptografía de las passkeys no se “rompe”. En su lugar, los ataques apuntan a piezas del sistema que permiten que el flujo de autenticación se complete sin que aparezca evidencia en pantalla para el usuario.
El malware puede, silenciosamente, obtener una aserción de autenticación válida, instalar una clave para verificación controlada por el atacante o extraer un secreto del dominio de seguridad (SDS) que se usa para descifrar claves privadas sincronizadas. El resultado potencial es un acceso repetible desde el entorno del atacante, una vez que el equipo inicial ya fue comprometido.
Limitaciones importantes del escenario
El reporte recalca que el análisis se limita a un conjunto específico de condiciones. Los investigadores enfocaron Google Password Manager en Chrome para Windows en dispositivos que incluyen un Módulo de Plataforma Confiable (TPM). Además, cada ruta arranca con un paso previo: malware ya en ejecución en el equipo de la víctima.
También se menciona que la investigación es post-compromiso: describe lo que un atacante puede alcanzar cuando el sistema ya “está perdido”, no cómo lograr la intrusión inicial. Por otra parte, al revisar bases públicas, no se identificaron identificadores CVE asociados a las tres técnicas nombradas.
Primer camino: Pass-ta-key
La primera técnica, Pass-ta-key, se apoya en el material de identidad del dispositivo que usa Chrome para la nube. El malware extrae la clave de identidad del dispositivo “envuelta” (wrapped) y solicita al TPM firmar una petición bajo llamadas de Windows al entorno criptográfico (CNG: Next Generation).
El componente crítico del problema, según el análisis, es cómo el servicio de autenticación en la nube responde. La infraestructura puede generar una aserción válida, pero lo que la diferencia de una verificación realizada por un humano es un bit específico: la marca User Verified (UV). Si ese indicador queda sin establecer, el sistema podría aceptar la ceremonia como válida en ciertos contextos.
El reporte señala que las especificaciones Web Authentication contemplan que un “relying party” que exija userVerification=required debería fallar cuando la verificación no ocurrió. Sin embargo, se describe que algunos sitios implementaron inicialmente validaciones incompletas; tras divulgación, al menos uno de los casos corrigió el comportamiento.
Segundo camino: Silver Pass-ta-key
La segunda ruta, Silver Pass-ta-key, ataca una capa más: el proceso de re-inscripción del dispositivo. Aquí el malware fuerza a Chrome a reenrolar el equipo. Durante ese intervalo, el mecanismo de verificación de usuario no se crea de inmediato, creando una ventana para que el atacante registre su propia clave.
Los investigadores indican que el servicio no necesariamente valida si la nueva clave proviene de hardware seguro, o al menos no lo hace de forma que impida el escenario descrito. Las aserciones firmadas con esa clave podrían conservar el bit UV activado, posibilitando inicios de sesión posteriores sin requerir la verificación en el dispositivo original de la víctima.
Como parte del análisis, se corrobora que el estado interno puede permitir una creación diferida de la clave de verificación. Aun así, el informe aclara que, con el código público disponible, no se puede concluir por completo cómo se comporta la sustitución de clave en la versión más reciente de Chrome en el lado del servidor.
Tercer camino: Golden Pass-ta-key
El tercer enfoque, Golden Pass-ta-key, va directamente contra el secreto usado para proteger credenciales sincronizadas. La idea es que el malware provoque nuevamente el reenrolamiento, consiga leer el SDS desde la memoria del proceso cuando se encuentra brevemente en texto plano y lo utilice para recuperar claves privadas de passkeys sincronizadas.
El reporte sostiene que en el código revisado existe respaldo a la exposición conceptual: Chrome crea o recibe SDS de 32 bytes en estructuras de datos del proceso del cliente. Esto confirma que el secreto entra a memoria, aunque quedan preguntas abiertas sobre confiabilidad de extracción, persistencia a través de “épocas” futuras y alcance real del secuestro de cuentas.
Además, se menciona que se aplicaron cambios relacionados con el registro en logs de FIDO (y ajustes de validación UV en al menos un sitio). Sin embargo, los autores señalan que esos cambios no necesariamente cierran por completo el problema descrito, dado que el secreto seguiría alcanzando el cliente y permaneciendo en la memoria de Chrome durante el intervalo relevante.
Qué datos puede buscar un atacante antes de explotar
Antes de ejecutar cualquiera de las rutas, los investigadores describen una fase de reconocimiento local. En Windows, Chrome guarda registros sincronizados de credenciales bajo una ruta asociada al perfil y a los datos de sincronización.
Según el análisis, incluso un proceso sin privilegios podría leer metadatos suficientes para identificar “relying parties” y nombres de usuario vinculados a las passkeys de la víctima. También se citan identificadores de credenciales y material de claves privadas cifrado.
Esta etapa importa porque permite planear el objetivo y preparar el camino para la autenticación en el flujo que el malware busca aprovechar.
Cómo deberían responder los sitios y los proveedores
El reporte incluye recomendaciones orientadas a reducir el riesgo desde el lado de los “relying parties” y los proveedores de credenciales. En particular:
- Reliying parties: establecer userVerification en required y verificar el bit UV devuelto, en lugar de confiar solo en lo que el navegador indica en la solicitud.
- Credential providers: exigir atestación de hardware para claves recién inscritas, reforzar controles de re-registro y recuperación, y limitar el acceso al estado local de passkeys.
- Gestión de claves: mantener llaves maestras fuera de logs del cliente y fuera de memoria donde sea posible.
En resumen, las defensas apuntan a cerrar la brecha entre “la ceremonia” que exige verificación y la forma en que el sistema podría completar el proceso cuando el atacante controla el entorno del cliente.
¿Qué puede hacer un usuario si sospecha compromiso?
La divulgación revisada no ofrece una respuesta completa sobre el efecto de acciones del usuario sobre el material ya robado. Por ejemplo, se indica que la documentación pública permite cambiar el PIN de Google Password Manager o borrar los datos asociados, pero no se detalla un mecanismo específico de rotación o revocación ligado al SDS.
Por ese motivo, si un usuario sospecha que el dispositivo pudo haber sido comprometido, conviene priorizar medidas de respuesta que van más allá de la configuración: revisar seguridad del equipo, eliminar persistencia del malware y asegurar que las credenciales se revalidan en condiciones confiables. El punto de fondo es que el reporte habla de técnicas post-compromiso, por lo que la limpieza del endpoint es fundamental.
Estado de la mitigación y falta de detalles públicos
El informe no describe explotación en entornos reales en el momento de la publicación, y tampoco aporta identificadores CVE, versiones exactas afectadas o un estado completo de remediación. Asimismo, la búsqueda en una base pública no encontró coincidencias para las técnicas nombradas.
Además, aunque se revisó material del código base de Chromium para corroborar partes de la arquitectura, también se señala que esto no prueba que la última versión estable de Chrome siga explotable. En otras palabras: el análisis es sólido sobre el diseño, pero el alcance exacto en productos actuales requiere confirmación específica.
Conclusión
Las ataques a Google Password Manager descritas por los investigadores muestran cómo un atacante con malware en el dispositivo puede aprovechar debilidades de implementación alrededor de passkeys, sin romper necesariamente la criptografía subyacente. Las tres rutas analizadas apuntan a distintos componentes: la identidad del dispositivo y la validación UV, el re-enrolamiento y la sustitución de claves, y el secreto del dominio de seguridad en memoria.
Para reducir el impacto, los “relying parties” deberían validar estrictamente la verificación del usuario, y los proveedores de credenciales deberían reforzar atestación, controles de re-registro y protección del estado local. Y para los usuarios, la lección principal es clara: si el endpoint estuvo comprometido, la recuperación debe enfocarse primero en eliminar el malware y luego en revalidar y endurecer el sistema.
Fuente: https://thehackernews.com/2026/08/google-password-manager-attacks-could.html
