La víctima introduce los datos de su cuenta en la página de phishing, mientras iAuthFlow v2 opera un navegador independiente en el servidor del atacante. Este envía la entrada de la víctima a Google y retransmite las solicitudes de Google de vuelta a la víctima. El proceso se repite hasta que el flujo de autenticación se completa.

Una vez completada la autenticación, iAuthFlow v2 controla una sesión de navegador autenticada y la utiliza para registrar una llave de acceso controlada por el atacante, afirma Abnormal. Esa credencial puede seguir siendo válida después de que la víctima cambie su contraseña.

En lugar de enviar a la víctima a su bandeja de entrada de Gmail tras la autenticación, iAuthFlow v2 muestra una breve pantalla de carga que dice: "Verificación, Procesando". Mientras tanto, el kit de herramientas trabaja en segundo plano para registrar una llave de acceso en un dispositivo controlado por el atacante.

"Durante esa pausa, la demostración del vendedor muestra el módulo de llaves de acceso abriendo la configuración de llaves de acceso de Google del objetivo a través del navegador autenticado y solicitando una nueva credencial", dijo Abnormal [https://abnormal.ai/blog/iauthflow-v2-phishing-google-passkeys].

"Google puede requerir una verificación de identidad adicional antes de permitir el cambio. En la ejecución grabada, el registro del kit indica que la llave de acceso se creó seis segundos después de la autenticación".

No está claro dónde se almacena la clave privada asociada a la llave de acceso del atacante. Abnormal hipotetizó que el kit podría utilizar un autenticador virtual basado en Chromium capaz de completar el registro WebAuthn sin almacenar la clave privada en el dispositivo de la víctima.

Sin embargo, debido a que los investigadores no compraron ni probaron el kit, no pudieron confirmar su mecanismo de almacenamiento ni verificar independientemente las afirmaciones más amplias del vendedor.

Independientemente del mecanismo de almacenamiento, las organizaciones deben buscar llaves de acceso recién registradas al investigar el compromiso de una cuenta.

Los responsables de la respuesta también deberían buscar otros cambios posteriores al compromiso, incluyendo llaves de acceso fraudulentas, concesiones de OAuth, métodos de recuperación, filtros de Gmail y reglas de reenvío.

"La respuesta y la recuperación no pueden terminar con un restablecimiento de contraseña o la revocación de la sesión", dijo Abnormal. "Las organizaciones también deben examinar qué cambió después de la autenticación —especialmente las credenciales recién inscritas, los métodos de recuperación, las concesiones de OAuth y la configuración del buzón de correo— y eliminar cualquier cosa que el atacante haya dejado atrás.

"A medida que kits de herramientas como iAuthFlow v2 amplían sus capacidades post-autenticación, la respuesta efectiva depende cada vez más de tratar la restauración de la cuenta como una investigación exhaustiva, no como un simple restablecimiento".

Las llaves de acceso se presentan habitualmente como el futuro de la seguridad de las cuentas. Diseñadas para resistir el phishing, pueden reemplazar las contraseñas y formas más vulnerables de MFA.

Registrar una llave de acceso no hace que una cuenta sea blindada. Los atacantes pueden, en su lugar, dirigirse a los métodos de inicio de sesión alternativos, sesiones activas, procesos de recuperación de cuenta y otras debilidades que rodean la credencial.

El robo de cookies de sesión, a menudo a través de malware infostealer, puede otorgar acceso a una sesión autenticada sin activar una solicitud de llave de acceso.

Otra ruta es el phishing de código de dispositivo, aunque depende de que la organización permita el flujo de dispositivo OAuth subyacente, algo que generalmente se desaconseja a menos que sea operativamente necesario.

Fuente:
TheRegister