Una vulnerabilidad en listas de Adblock Plus permite ejecutar códigos maliciosos

browser

Recientemente se ha descubierto una vulnerabilidad que podría permitir a los mantenedores de bloquear las listas de filtros para Adblock Plus, AdBlock y las extensiones de navegador uBlocker para crear filtros que inyecten scripts remotos en los sitios web.

Con una base de usuarios que ha cruzado la marca de los 10 millones, si se inyectaran scripts maliciosos en los bloqueadores de anuncios, esto tendría un impacto considerable porque podrían realizar actividades no deseadas, como el robo de cookies, información conexión, causando redirecciones de página u otro comportamiento no deseado.

Para aquellos que no están familiarizados con los bloqueadores de publicidad, básicamente estas utilizan listas de URL relacionadas con anuncios y comportamientos maliciosos.

Por lo general, son dirigidos por un pequeño equipo de personas o incluso una sola persona.

Cuando estas listas se cargan con una extensión de bloqueo de anuncios como Adblock Plus, esta extensión evitará que el navegador se conecte a las URL puestas en la lista y por lo tanto esto evita la conexión a anuncios o scripts maliciosos.

La opción de filtro $ rewrite es la causante del problema

Cuando Adblocker Plus 3.2 se lanzó en 2018, se agregó una nueva opción de lista de filtros, llamada $rewrite.

Esta opción permitió a un mantenedor de listas reemplazar una solicitud web que coincida con una expresión regular en particular con otra URL.

Hubert Figuière, quien introdujo esta función, explicó que:

“Desde Adblock Plus 3.2 para Chrome, Firefox y Opera (y versiones de desarrollo del 3.1.0.2053), una nueva opción de filtro $ rewrite le permite volver a escribir la URL Un recurso en lugar de bloquearlo.

Cuando Adblock Plus asigna una URL de solicitud a un filtro con la opción $ rewrite, transforma la URL según la regla provista y le dice al navegador que cargue el recurso al mismo tiempo”.

La sintaxis de la regla de $ rewrite especifica una cadena que sirve como plantilla para la nueva URL.

$ n se sustituye por la expresión regular n-th sub-match del filtro. Es la misma sintaxis que la función String.prototype.replace () de JavaScript.

Si la URL resultante es relativa (es decir, no tiene un host), el origen de la consulta original se usará como base. En cualquier caso, si la nueva URL no comparte el origen, la reescritura se considerará como fallida y la solicitud inicial se pasará.

“Además, los filtros $ rewrite se ignoran para las consultas SCRIPT, SUBDOCUMENT, OBJECT y OBJECT_SUBREQUEST por razones de seguridad. Esta opción es conveniente para modificar o eliminar parámetros de consulta”.

El único inconveniente es que la cadena de reemplazo debe ser una URL relativa, lo que significa que no contiene un nombre de host y que, cuando se reescribe, debe pertenecer al mismo dominio de origen que la solicitud.

La ejecución de código incluso se realiza en google maps

Un investigador de seguridad explicó que:

bajo ciertas condiciones, es posible que un mantenedor de filtros malicioso no autorizado cree una regla que inyecta un script remoto en un sitio en particular.

Para hacer esto, solo se debe buscar un sitio que cargue secuencias de comandos de cualquier dominio que contenga un redireccionamiento abierto y use XMLHttpRequest o Fetch para descargar las secuencias de comandos para ejecutar.

No fue demasiado difícil de encontrar porque para hacer esto solo basta con hacer usó de Google Maps como prueba de concepto.

El investigador explicó que se deben cumplir los siguientes criterios para que un servicio web pueda explotarse con este método:

  • La página debe cargar una cadena JS utilizando XMLHttpRequest o Fetch y ejecutar el código devuelto.
  • La página no debe restringir los orígenes desde los que se puede recuperar mediante las directrices de la política de seguridad de contenido, ni validar la URL de solicitud final antes de ejecutar el código descargado.
  • El origen del código recuperado debe tener un redireccionamiento abierto del lado del servidor o contenido de usuario arbitrario del host.

El uso de XMLHttpRequest o Fetch para descargar scripts y abrir la redirección son las dos claves del problema.

Para mitigar este problema, se recomienda que los sitios web utilicen el encabezado de política de seguridad de contenido y la opción connect-src para especificar una lista blanca de sitios desde los que se pueden cargar los scripts.


Sé el primero en comentar

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.