Brash: Un exploit DoS en Chromium que "mata" los Web Browsers por el "document.title"

En cuestión de días, lo que empezó como una prueba más en el laboratorio de un hacker colombiano terminó poniendo incómodo a medio ecosistema Chromium. Un simple experimento con el título de una pestaña acabó convirtiéndose en un exploit capaz de tirar navegadores modernos por todo el mundo. Y es que debajo de casi todo lo que vemos en la web hoy hay una pieza común: Blink, el motor de renderizado desarrollado por Google y adoptado por Chrome, Edge, Brave, Opera, Arc, Vivaldi y otros. Si Blink se tuerce, no se rompe solo un navegador: se resiente una parte entera de la infraestructura digital.

Figura 1: Brash, un exploit DoS en Chromium que "mata"

los Web Browsers por el "document.title"

Llevo muchos años siendo un miembro muy activo en la comunidad de ciberseguridad buscando la oportunidad de cazar bugs en plataformas, sistemas y servicios globales desde adolescente, y hoy esto y por aquí porque Chema Alonso me ha pedido que le hiciera este artículo. Hace años ya os hablé por este blog de la herramienta Trape para investigar identidades y personas, además que tienes muchas otras herramientas que publico en mi repositorio de GitHub. 

Figura 2: Repositorios de GitHub de José Pino

Hoy quería hablaros de Brash que afecta a Blink, y que demuestra cómo es posible colapsar navegadores modernos jugando únicamente con "document.title. Brash vive en el corazón de Chromium y permite lanzar un ataque de Denegación de Servicio (DoS) a escala masiva. El impacto no se mide en “unos pocos usuarios afectados”, sino en miles de millones de navegadores potencialmente vulnerables. Brash es una vulnerabilidad de Denegación de Servicio que provoca:

• Congelamiento total del navegador.
• Bloqueo instantáneo de pestañas.
• Consumo extremo de CPU y memoria.
• En algunos casos, reinicio forzado del proceso del navegador.

El ataque se ejecuta mediante un patrón específico de llamadas que genera un desequilibrio interno en los manejadores asíncronos de Chromium. En pocas palabras, una pequeña pieza de código es capaz de colapsar el navegador por completo.

Figura 3: Probar demo de Brash

Brash no requiere hacer uso de ingeniería avanzada, ni de tener acceso a memoria, hacer una manipulación de binarios donde usar técnicas complejas de ROP, JIT Spraying o similar para lidiar con las protecciones de memoria. Su peligrosidad radica en su simplicidad, su alcance global, y el hecho de que puede activarse desde cualquier sitio web, iframe o servicio que renderice contenido bajo Chromium, como hacen también millones de instalaciones de apps móviles en la industria.

Figura 4: Testeando Brash en un Web Browser no vulnerable

Chromium es el motor dominante de Internet. La combinación de Chrome, Edge, Brave, Opera, Arc, Samsung Internet y otros navegadores construidos sobre su framework alcanza una cifra que se aproxima a los 3.000 millones de usuarios activos, y cualquier navegador basado en Chromium es vulnerable. Incluso aplicaciones como WhatsApp Desktop, Discord, Slack, VSCode y apps basadas en Electron en general pueden verse afectadas si renderizan contenido que lleve el exploit de Brash.

Impacto técnico

Brash deja ver varias cosas incómodas sobre cómo está montado Chromium:

• Chromium hereda demasiado del modelo monolítico de callbacks, provocando efectos dominó difíciles de mitigar.

• No existe una protección efectiva contra tormentas asíncronas de eventos, lo cual permite que una secuencia específica sature el event loop.

• El DoS puede dispararse sin interacción del usuario.

• Facilidad de explotación, ya que un atacante puede integrar Brash en Banners, Scripts externos, Trackers, Widgets o Iframes invisibles. El resultado es un ataque simple, silencioso y de ejecución inmediata, que podría venir por cualquiera de los proveedores de contenido que utiliza una aplicación compleja hoy en día.

Brash explota una omisión de diseño en Blink, como es la ausencia total de límites en las actualizaciones de document.title, la función que define el título de una pestaña. Un sitio web malicioso puede realizar millones de cambios de título por segundo, saturando el hilo principal del navegador y forzando su colapso. El exploit provoca picos del 100 % de uso de CPU y bloqueos totales en Chrome, Edge, Opera, Brave, Vivaldi, Arc, Perplexity Comet o ChatGPT Atlas, el navegador de OpenAI.

Figura 5: Brash en GitHub

No es un bug visual. Es una falla estructural que permite a cualquier atacante hacer colapsar un sistema operativo con una sola línea de código. Firefox y Safari no son vulnerables porque utilizan motores distintos (Gecko y WebKit, respectivamente). En iOS todos los navegadores se ven obligados a usar WebKit por imposición de Apple, por lo que el riesgo efectivo de Brash se concentra en Windows, macOS, GNU/Linux y Android.

Metodología y reproducibilidad

Para no quedarse solo en la demo de turno, monté un pequeño laboratorio y repetí las pruebas una y otra vez en entornos controlados con máquinas limpias, usando navegadores recién instalados, sin extensiones ni perfil previo. Sobre estos entornos, probé escenarios progresivos, con pruebas con intensidad moderada, agresiva y extrema variando burstSize, interval y delay en la librería Brash.run.

Con estas pruebas pude observar métricas del porcentaje de uso de CPU, tiempo hasta congelación, respuesta de la interfaz, recuperación del proceso o cierre forzado. Y por supuesto, había que probar diferentes vectores de ataque, con ejecución directa en pestaña, incrustado en iframes, ventanas emergentes y entornos basados en Electron.

Figura 6: Libro de Bug Bounty: De profesión "Cazarrecompensas"

en 0xWord, escrito por Pablo García

Quería probar si esta vulnerabilidad y vector de explotación era repetible, así que cada escenario se ejecutó múltiples veces sobre Windows, macOS y GNU/Linux para descartar falsos positivos o condiciones de carrera. Hoy en día cualquier equipo de seguridad puede reproducir estos escenarios usando el repositorio oficial de Brash en GitHub y la demo pública de Brash en un entorno de laboratorio aislado. Toda la investigación, el exploit y los recursos de prueba están publicados en el repositorio oficial y en una demo pública:

• Repositorio oficial: https://github.com/jofpin/brash
• Demo en vivo: https://brash.run
• Demo oculta (sin interfaz): https://brash.run/hidden-live-demo.html

Desde ahí es posible, ejecutar el exploit directamente en tu navegador, probar diferentes niveles de intensidad (moderado, agresivo y extremo), ajustar en tiempo real los parámetros que saturan el event-loop del navegador a través de document.title.

Figura 7: Ejecución de Brash en Google Chrome in-progress

En el propio repositorio se incluye:

• exploit-demo/index.html: panel interactivo para observar cómo se degrada y colapsa el navegador según el burstSize y el interval.

• brash.js: librería lista para integrarse en PoCs, laboratorios o pruebas de estrés sobre navegadores basados en Chromium.

Con la configuración que puedes ver en la imagen siguiente, Brash intenta inyectar millones de actualizaciones de document.title por segundo, saturando el hilo principal (UI thread), bloqueando el event loop, congelando la pestaña y forzando el colapso del navegador en una ventana de entre 15 y 60 segundos, tal y como se documenta en el README del proyecto.

Figura 8: Ejemplo de uso mínimo con la librería oficial (extremo).

Esta vulnerabilidad abre una serie de riesgos reales que podrían afectar a usuarios, empresas y organizaciones, ya que un sitio web podría inutilizar el navegador del visitante, y un servidor vulnerable a Client-Side Attacks podría permitir a un solo adversario inutilizar las conexiones de todos sus clientes.

Figura 9: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

Un servicio de anuncios podría provocar bloqueos masivos a escala mundial, y podría usarse para takedowns forzados, derribando navegadores de objetivos específicos. En entornos empresariales, puede causar interrupciones masivas, porque además Brash es un ataque silencioso, global, de bajo costo y prácticamente imposible de mitigar, ya que aún no cuenta con un parche de seguridad.

¿Por qué Brash no es "otro DoS de navegador"?

La mayoría de vulnerabilidades de Denegación de Servicio en navegadores se limitan a APIs muy concretas o a formatos de recurso específicos, no escalan bien entre diferentes versiones, sistemas operativos o entornos embebidos y requieren condiciones concretas o una interacción notable del usuario. Brash, en cambio se apoya en un comportamiento completamente legítimo (document.title) que existe desde hace años, afecta a todo un ecosistema dominante basado en Chromium, incluyendo navegadores y aplicaciones Electron. 

Figura 10: Ejecución de Brash en Google Chrome

Además es extremadamente barato de integrar en cualquier página, banner, script de tracking o iframe invisible y puede activarse sin clics por parte del usuario, sin permisos especiales y sin tocar memoria. Ese salto —de bug raro a patrón que cualquiera puede reciclar— es lo que hace que Brash no sea sólo otro fallo curioso para coleccionar.

Brash no es un bug más. Es el recordatorio incómodo de que incluso los ecosistemas mejor montados pueden caerse por algo tan tonto como un título de pestaña. Cuesta encontrar este año un fallo de navegador con un alcance parecido.

Saludos,

Autor: José Pino (Contactar con José Pino)