FOSSBYTES TECH SIMPLIFIED LOGO

yoEn julio de 2018, el popular software Adblock Plus lanzó su versión 3.2 que trajo una nueva función llamada $ rewrite. Esta característica le permitió a uno cambiar las reglas de filtrado y decidir qué contenido se bloqueó y cuál no. Se dijo que a menudo hay elementos de contenido que son difíciles de bloquear. Esta función pronto fue implementada por AdBlock y uBlock.

En un desarrollo preocupante, ha sido revelado que este la opción de filtro se puede aprovechar por actores notorios para inyectar código arbitrario en las páginas web. Con más de 100 millones de usuarios de estas herramientas de bloqueo de anuncios, este exploit tiene un gran potencial dañar a los usuarios de la web.

Cuando se introdujo la función $ rewrite, se le ocurrió un truco simple para asegurarse de que no se explote fácilmente. Necesitaba especificar una nueva URL para reemplazar una solicitud web en particular. Al hacerlo, era necesario que reemplazara la URL anterior con una nueva URL con el mismo host. Por ejemplo, tuvo que redirigir las solicitudes de example.com/ads.gif para example.com/doggos.gif. Aquí, el host example.com sigue siendo el mismo.

Entonces, ¿qué ha cambiado? ¿Qué ha hecho que $ rewrite sea explotable?

Bajo algunas condiciones, es posible explotar los servicios web usando $ rewrite. Por ejemplo, cuando un servicio usa XMLHttpRequest o Fetch para cargar código para su ejecución, $ rewrite les permite cumplir con solicitudes de orígenes arbitrarios.

Teniendo en cuenta estas condiciones, es posible que cualquier mantenedor de filtros de bloqueadores de anuncios cree un conjunto de reglas que pueden redirigir el servicio a una página con una carga útil maliciosa.

Según los hallazgos del investigador Armin Sebastian, los servicios de Google como Google I’m Feeling Lucky, Google Maps, Gmail y Google Images, etc., cumplen con los requisitos para ser explotables. Vale la pena señalar que la falla no se limita a los servicios de Google y otros servicios web podrían verse afectados por la misma.

Sebastian informó a Google sobre la falla, pero su informe se cerró porque era un «Comportamiento previsto».

Vale la pena señalar que es un desafío detectar qué operador de lista de filtros no autorizado inyectó el código dañino. El operador puede ofrecer un tiempo de vencimiento corto para la lista de filtros maliciosos e incluso ordenar los objetivos según las direcciones IP. Sebastian sugiere que los bloqueadores de anuncios deberían dejar de admitir la función $ rewrite y optar por aquellas opciones que no la admiten en primer lugar.

Leer también: RobinHood Ransomware es «honesto» y promete «respetar su privacidad»

This post is also available in: Español Alemán Vietnamita Italiano Indonesio

Dejar respuesta

Please enter your comment!
Please enter your name here