En la conferencia DEF CON 33 se presentó un método de ataque a las extensiones del navegador que inyectan sus elementos de interfaz en la página que se está viendo. La aplicación de este ataque a las extensiones con gestores de contraseñas podría resultar en la filtración de información almacenada, como parámetros de autenticación, detalles de tarjetas de crédito, datos personales y contraseñas de un solo uso para la autenticación de dos factores. El problema afecta a todos los gestores 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 autocompletació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, podrá manipular todos los elementos del DOM, incluidas las extensiones del navegador que han sido inyectadas.
Entre otras cosas, existe la posibilidad de hacer que el diálogo de confirmación sea transparente y combinar espacialmente el botón en este diálogo con el botón del diálogo falso creado por el atacante, que incita al usuario a hacer clic. Como tales diálogos falsos pueden usarse solicitudes ficticias de permisos para cookies, anuncios o formularios con CAPTCHA. Al colocar el diálogo falso debajo del diálogo transparente del gestor de contraseñas y alinear las posiciones de los botones en la pantalla, se puede lograr que el clic del usuario caiga en el botón de confirmación de llenado de parámetros de autenticación en el diálogo del gestor de contraseñas, aunque el usuario crea que hizo clic, por ejemplo, en el botón de cerrar una ventana de anuncio.
El ataque consta de los siguientes pasos:
- Crear un elemento intrusivo en la página que incite a hacer clic.
- Agregar un formulario web para iniciar sesión o llenar datos personales en la página.
- Establecer la transparencia del 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 activa el diálogo de autocompletado del gestor de contraseñas.
- Buscar el diálogo del gestor de contraseñas que aparece en el DOM y establecerle transparencia.
- Esperando el clic del usuario en un elemento visible y prominente en la página, que, con la adecuada combinación de elementos visibles e invisibles, llevará a presionar un botón en un diálogo transparente y a llenar los campos por el administrador de contraseñas.
- Extracción de datos de un formulario web completo y envío de esa información al servidor del atacante.
Dado que el autocompletado de los parámetros de autenticación en el administrador de contraseñas se activa solo para los sitios donde se guardaron esos parámetros, para llevar a cabo un ataque es necesario poder ejecutar un código JavaScript propio en el sitio atacado o en un subdominio. Así, para el ataque se requiere 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 que se muestra al usuario.
Se señala que muchos usuarios utilizan un solo administrador de contraseñas tanto para almacenar parámetros de inicio de sesión como para generar contraseñas de un solo uso para la autenticación de dos factores, lo que permite usar el método de ataque considerado al autocompletar contraseñas de un solo uso. Como ejemplo, se demuestra un ataque al sitio issuetracker.google.com, que contiene 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 a través de la sustitución de solicitudes invasivas ficticias (permitir el manejo de Cookies, permitir la personalización y aceptar la política de privacidad).
Además de los sitios con vulnerabilidades XSS, el ataque puede llevarse a cabo en servicios que ofrecen subdominios a todos — la mayoría de los administradores de contraseñas, en la configuración predeterminada, completan 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 obtener los datos personales del usuario y los detalles de la tarjeta de crédito guardados en el gestor de contraseñas. Para que estos datos se filtren, no es necesario ejecutar código JavaScript en el contexto de un sitio web ajeno; basta con atraer a la víctima a la página del sitio del atacante. En el caso de los datos personales, el llenado de formularios web se realiza en base a su tipo (dirección, número de tarjeta de crédito, nombre completo), sin necesidad de vinculación a el dominio. La filtración más peligrosa es la de los parámetros de la tarjeta de crédito, ya que los gestores de contraseñas no solo introducen el número de la tarjeta, sino también la fecha de caducidad y el código de verificación.
El investigador que descubrió el problema probó 11 complementos de navegador con gestores de contraseñas, que suman 39.7 millones de instalaciones activas, y todos resultaron ser vulnerables a 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 intentaron bloquear el ataque de forma indirecta. Otros complementos (KeePassXC-Browser, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce) aún no han recibido correcciones. Para verificar la manifestación de la vulnerabilidad en varios gestores de contraseñas, se publicó un conjunto de páginas de prueba.
La posición de los desarrolladores de 1Password, que no han lanzado una corrección, es que la vulnerabilidad es fundamental y no está directamente relacionada con un complemento de navegador específico, por lo que los intentos de solucionarla desde el lado del complemento solo bloquean vectores de ataque individuales, pero no resuelven el problema en sí, que debe abordarse en el navegador o mediante una solicitud de confirmación antes de autocompletar los campos. Se menciona que en 1Password ya se admite la emisión de una solicitud de confirmación antes de autocompletar los parámetros de pago y que en la próxima versión se añadirá una opción para emitir dicha solicitud para todos los tipos de datos autocompletables (debido a la reducción de la comodidad de uso, esta opción no se activará por defecto).
Entre los métodos de protección propuestos por el autor de la investigación, se menciona el seguimiento de cambios en los estilos de los elementos insertados en la página mediante la API MutationObserver, la restricción de cambios a través de Shadow DOM en modo 'cerrado', la monitorización de la transparencia de los elementos, el uso de la API Popover para mostrar diálogos, la verificación de superposiciones de capas, así como la desactivación temporal del procesamiento de eventos de puntero (pointer-events:none) en todos los elementos flotantes durante la apertura del diálogo del gestor de contraseñas. Para bloquear completamente la clase descrita se recomienda implementar a nivel del navegador 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 extensiones al sitio (Configuraciones de la extensión → 'acceso al sitio' → 'al hacer clic'), en el que la extensión obtiene acceso al sitio solo después de hacer clic en el icono en la parte derecha de la barra de direcciones. También se menciona como solución alternativa 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 la posible filtración de datos desde el portapapeles compartido y el riesgo de no detectar intentos de phishing.
Fuente: opennet.ru
