En la conferencia DEF CON 33 se presentó un método de ataque a las extensiones de navegador que sustituyen sus elementos de interfaz en la página visualizada. La aplicación de este ataque a las extensiones con administradores de contraseñas puede dar lugar a una filtración de la información almacenada en los administradores de contraseñas, como parámetros de autenticación, datos de tarjetas de crédito, información personal y contraseñas de un solo uso para la autenticación de dos factores. El problema afecta a todos los administradores de contraseñas probados, incluidos 1Password, Bitwarden, LastPass, KeePassXC-Browser, NordPass, ProtonPass y Keeper.
El método de ataque se basa en que las extensiones del navegador insertan un diálogo que solicita la autocompleción de contraseñas directamente en la página mostrada, integrando sus elementos en el DOM (Modelo de Objetos del Documento) de dicha página. Si el atacante tiene la capacidad de ejecutar su código JavaScript en la página, por ejemplo, explotando una vulnerabilidad XSS en el sitio, puede manipular todos los elementos en el DOM, incluidas las extensiones del navegador insertadas.
Entre otras cosas, existe la posibilidad de hacer que el diálogo de confirmación sea transparente y alinear espacialmente el botón en este diálogo con el botón de un diálogo falso, creado por el atacante y que incita al usuario a hacer clic. Diálogos engañosos como solicitudes ficticias de permisos para trabajar con Cookies, banners publicitarios o formularios con captcha pueden ser utilizados como tales. Al colocar el diálogo falso debajo del diálogo transparente del administrador de contraseñas y alinear las ubicaciones de los botones en la pantalla, se puede lograr que el clic del usuario caiga en el botón de confirmación para completar los parámetros de autenticación en el diálogo del administrador de contraseñas, aunque el usuario crea que ha hecho clic, por ejemplo, en el botón de cerrar la ventana de la publicidad.
El ataque se resume en los siguientes pasos:
- Crear un elemento intrusivo en la página que incentive a hacer clic.
- Añadir un formulario web a la página para iniciar sesión o completar datos personales.
- Establecer la transparencia para el formulario web (‘opacity: 0.001’ en CSS).
- Utilizar el método focus() para establecer el foco de entrada en un campo del formulario, lo que activará el diálogo de autocompleción del administrador de contraseñas.
- Buscar el diálogo del administrador de contraseñas que ha aparecido en el DOM y establecer la transparencia para él.
- Esperando que el usuario haga clic en un elemento visible y persistente en la página, que mediante la combinación adecuada de elementos visibles e invisibles llevará a presionar el botón en un diálogo transparente y a completar los campos del gestor de contraseñas.
- Extracción de datos de un formulario web completado y envío de estos al servidor del atacante.
Dado que el autocompletado de los parámetros de autenticación en el gestor de contraseñas se activa solo para los sitios en los que se han guardado esos parámetros, para llevar a cabo el ataque es necesario tener la capacidad de ejecutar su propio código JavaScript en el sitio atacado o en un subdominio. Así, para ejecutar el ataque, se debe obtener un subdominio en el mismo dominio que el sitio atacado o encontrar una vulnerabilidad XSS en el sitio que permita inyectar su código en el contenido presentado al usuario.
Se observa que muchos usuarios utilizan un solo gestor de contraseñas tanto para almacenar los parámetros de inicio de sesión como para generar contraseñas de un solo uso para la autenticación en dos pasos, lo que permite emplear el método de ataque considerado al autocompletar las contraseñas de un solo uso. Como ejemplo, se demuestra un ataque en el sitio issuetracker.google.com, que presenta una vulnerabilidad XSS. Para obtener los parámetros de inicio de sesión y el código para la autenticación de dos factores, basta con enviar al usuario un enlace que explote la vulnerabilidad XSS y lograr tres clics mediante la sustitución de solicitudes persistentes ficticias (autorización para procesar Cookies, autorización para la personalización y aceptación de la política de privacidad).
Además de los sitios con vulnerabilidades XSS, el ataque puede realizarse en servicios que ofrecen subdominios a cualquier interesado; la mayoría de los gestores de contraseñas en configuración por defecto realizan el autocompletado de los parámetros de inicio de sesión no solo para el dominio principal, sino también para los subdominios.
El ataque también puede utilizarse para identificar la información personal guardada en el gestor de contraseñas del usuario y los detalles de sus tarjetas de crédito. Para filtrar este tipo de datos, no es necesario ejecutar código JavaScript en el contexto de un sitio ajeno; basta con atraer a la víctima a una página del sitio del atacante. En el caso de la información personal, el llenado de formularios web se realiza según su tipo (dirección, número de tarjeta de crédito, nombre completo), sin relación a el dominio. La filtración más peligrosa son los detalles de las tarjetas de crédito, ya que los gestores de contraseñas no solo insertan el número de la tarjeta, sino también la fecha de vencimiento y el código de verificación.
El investigador que descubrió el problema probó 11 extensiones de navegador con gestores de contraseñas, sumando un total de 39.7 millones de instalaciones activas, y todas ellas resultaron no estar protegidas contra este tipo de ataques. Algunos fabricantes han lanzado actualizaciones (NordPass 5.13.24, ProtonPass 1.31.6, RoboForm 9.7.6, Dashlane 6.2531.1, Keeper 17.2.0, Enpass 6.11.6, Bitwarden 2025.8.1) que intentan bloquear el ataque por vías alternativas. Otras extensiones (KeePassXC-Browser, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce) aún permanecen sin solución. Se ha publicado un conjunto de páginas de prueba para evaluar la manifestación de la vulnerabilidad en diferentes gestores de contraseñas.
La posición de los desarrolladores de 1Password, que no han lanzado una solución, es que la vulnerabilidad es fundamental y no está directamente relacionada con una extensión específica del navegador. Por lo tanto, los intentos de solucionarla desde la extensión solo bloquean vectores de ataque individuales, sin resolver el problema en sí, que debe abordarse en el navegador o mediante la solicitud de una confirmación adicional antes del autocompletado de los campos. Se menciona que en 1Password ya se admite la generación de una solicitud de confirmación antes del autocompletado de los detalles de pago, y en la próxima versión se añadirá una opción para presentar dicha solicitud para todos los tipos de datos autocompletables (debido a la disminución de la comodidad, esta opción no se activará por defecto).
Entre los métodos de protección propuestos por el autor del estudio se menciona el seguimiento de los cambios en los estilos de los elementos que se insertan en la página mediante la API MutationObserver, la restricción de cambios a través de Shadow DOM en modo "closed", la monitorización de la transparencia de los elementos, la utilización de la API Popover para mostrar diálogos, la verificación de superposiciones de capas, y la desactivación temporal de la gestión de eventos de puntero (pointer-events:none) en todos los elementos flotantes durante la presentación del diálogo del gestor de contraseñas. Esto es necesario para bloquear completamente la clase mencionada. de ataques se recomienda, a nivel del navegador, implementar una API separada para la protección contra el clickjacking.
Como método universal de protección en navegadores basados en el motor Chromium, se recomienda a los usuarios activar el modo de confirmación de acceso de la extensión al sitio (Configuración de la extensión → "acceso al sitio" → "al hacer clic"), donde la extensión solo obtiene acceso al sitio después de hacer clic en el ícono en la parte derecha de la barra de direcciones. Como solución alternativa de protección, también se menciona la desactivación del autocompletado de formularios y la copia manual de contraseñas a través del portapapeles, pero esto plantea el problema de posibles fugas de datos del portapapeles compartido y el riesgo de no notar intentos de phishing.
Fuente: opennet.ru
