La transcripción Speech-to-Text Client-Side que no puntúa correctamente por no usar un LLM-MM

No soy mucho de enviar audios por las aplicaciones de mensajería. Lo hago sólo con amigos, y gente muy cercana, pero no me gusta mucho usar la voz. Va demasiado de mí en los audios. Sin embargo, es mucho más rápido que escribir. Pero... ¿por qué no usar el Speech-To-Text del smartphone? Pues porque no suelo tener buena experiencia con la puntuación. Eso es lo que estaba pensando ayer domingo, trabajando viendo el puente del 25 de Abril de Lisboa, así que quise probar si, con la llegada de los LLMs Multi Modales, había mejorado.

Figura 1: La transcripción Speech-to-Text Client-Side que

no puntúa correctamente por no usar un LLM-MM

Primera prueba, usando Twitter/X en iOS, y el botón de Speech-To-Text del teclado del iPhone 17 Pro Max que tengo, con un mensaje muy sencillo. Aquí tenéis el resultado, muy al estilo de los primeros Cognitive Services del año 2016 (si no anteriores). Han pasado 10 años ya para seguir con esta calidad.

Figura 2: Speech-to-Text del teclado de iPhone.

No pone el punto ni las interrogaciones. Ni una coma.

Six-Seven nada más.

Lo siguiente que hice fue probarlo en Gemini, pero ahora pidiéndole que me lo hiciera bien con un Prompt y subiéndole un audio, para que hiciera todo el proceso en backend (Server-Side). El resultado es muy bueno, que es lo que yo estoy esperando de un Speech-to-Text en el terminal móvil.

Figura 3: Gemini lo borda. Correcto.

Así que, como lo hizo muy bien Gemini, que es un LLM-MM, le pregunté por qué la soluciones Speech-To-Text en Smartphone tienen tantas carencias a la hora de poner las puntuaciones correctas, y aquí está la explicación que me dio.

Figura 4: Problemas del Speech-to-Text para puntuar correctamente.

Por supuesto, la primera es que no se dictan los puntos y las comas, ni las interrogaciones o exclamaciones. Evidente, pero en el mundo que estamos hoy en día, los modelos de IA reconocen las entonaciones con facilidad, así como se hace el análisis de sentimiento, que de eso hemos hablado mucho. Basta con un clasificador de Machine-Learning para hacer eso.

Figura 5: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Lo siguiente que dice es que las pausas pueden ser ambigüas, bueno, pero se puede hacer mejor que lo que se hace ahora. También dice que puede afectar la diferente forma de entonar que se tiene o que el contexto puede ser indeterminado. Además del uso de fórmulas habladas, como las muletillas. Nada, no se lo compro, debería ser mucho mejor que esta prueba que he hecho con Notas de iPhone.

Figura 6: Ni una puntuación.

Visto esto, le pregunté a Gemini, si estos problemas existen, cómo es posible qué él lo hubiera hecho tan bien con el audio que le había subido, y la respuesta se resume en... Yo soy un LLM-MM de primer nivel, para mí es trivial.

Figura 7: La respuesta de por qué lo hace él tan bien

Por supuesto, hay una diferencia fundamental entre hacer un análisis en tiempo real del flujo de audio en "stream" a hacerlo con el fichero completo en "bloque", pero aún así es muy mejorable. De hecho, este Prompt se lo he subido usando el Speeh-To-Text en Google Chrome en la webapp de Gemini - ejecutándose el Client-Side - , y la verdad que lo hace muy bien.

Figura 8: Usando el Speech-To-Text de Gemini en Google Chrome Client-Side

Lo dicho, creo que si estos sistemas de Speech-To-Text en Client-Side funcionara mejor - que estamos en la era ElevenLabs y traducción en tiempo real de conversaciones, la gente haría menos uso de los envíos de audios, y sería un avance para los usuarios, porque a veces hay que escribir textos muy largos por no enviar el audio a una persona que no se quiere enviar.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo crear un exploit 1-day sobre un CVE de Chrome con Vibe Coding usando Claude Opus (no Mythos) y poner en jaque todas las apps en Electron

Utilizar la Inteligencia Artificial para buscar vulnerabilidades es algo de lo que os he hablado en más de alguna ocasión. En el artículo de "Usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source" os hablaba hace ya un años de que me extrañaba mucho que esto no fuera un parte fundamental de los repositorios de código. Y sobre explotar CVEs publicados sólo con la información pública, ya tuvimos en el año 2024 el paper de "LLM Agents can Autonomously Exploit One-day Vulnerabilities".

Figura 1: Cómo crear un exploit 1-day sobre un CVE de Chrome con Vibe Coding

usando Claude Opus (no Mythos) y poner en jaque todas las apps en Electron

Esto, lógicamente, lleva a que la profesión de dedicarse al Bug Bounty haya cambiado, y empiece a ser imprescindible trabajar con los LLM tanto para la búsqueda como para la explotación, que es de lo que habla David Padilla  en su libro de "Bug Hunter".

Figura 2:"Bug Hunter" escrito por David Padilla en 0xWord

Esto mismo es lo que ha hecho el investigador s1r1us con Google Chrome, para demostrar el riesgo que además esto tiene en las aplicaciones hechas con Electron, y que ha publicado en un artículo que debes leer "I Let Claude Opus Write a Chrome Exploit: The Next Model (Mythos?) Won't Need My Help?". El gran problema es que las aplicaciones hechas con Electron llevan embebidas versiones de Chrome completas, pero hay un gap entre la actualización y parcheo de vulnerabilidades de Google Chrome y las versiones que llevan aplicaciones súper populares hechas con Electron.

Figura 3: Versiones de Google Chrome en aplicaciones Electron

A día de hoy, estamos, tras la última actualización del 7 de Abril en Google Chrome 147, así que todos los bugs parcheados en esta última versión, aún están presentes en Cursor, Claude Desktop, Discord, Slack, etcétera. Así que... ¿por qué no, a partir de la publicación de los CVEs parcheados en Google Chrome usar Claude Opus (No Mythos) para intentar hacer el exploit de estas vulnerabilidades conocidas?

Figura 4: Lista de CVEs de criticidad alta parcheados en Google Chrome 147

Para ello, s1r1us estuvo enfocando a Claude Opus sobre distintos CVEs de los que no había exploit público, gastando tokens y dinero en ellos, hasta que encontró uno que el modelo descubrió cómo explotarlo, y con la ayuda del investigador - sólo con prompting - fue trabajando hasta que consiguió un código funcional que permitía ejecutar las primitivas de escritura y lectura dentro de la Sandbox de Google Chrome.

Figura 5: CVE explotado en el estudio

Por supuesto no es un 0-day, sino un 1-day o n-day, como quieras llamarlo, pero del que no existe un exploit público, por lo que sigue teniendo mucho valor en el mercado del bug bounty legítimo, pero como os podéis imaginar, también en el mercado negro. 

Figura 6: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso.

El siguiente fase hay que conseguir evadir la sandbox, y de esto no hay un CVE claro, pero el investigador hace una cosa maravillosa, que es irse a Chromium Tracker y buscar un reporte de existencia de este problema, y encontró el fallo descrito como: "V8 Sandbox Bypass: WasmCPT handle UAF by import dispatch table growth", un fallo conocido en la V8 Sandbox de Chromium.

Figura 7:"V8 Sandbox Bypass: WasmCPT handle UAF by import dispatch table growth"

Así que apuntó a Claude Opus hacia él, y juntando las dos piezas fue capaz de conseguir construir un exploit totalmente funcional para un CVE público del que no había exploit conocido, y que tiene un valor espectacular para el equipo de seguridad de Google, para las empresas de seguridad ofensiva y, por supuesto para el black market.

Figura 8: Explotando el Sandbox

Por supuesto, los datos son los más interesantes, porque dejan ver el mundo hacia donde vamos, y que como podéis ver permite que con unas 20 horas de trabajo de "babysitter", y unos 2.000 USD en tokens se posible explotar un CVE conocido que está sin parchear en tooooooodas las aplicaciones Electron tan populares que tenemos hoy en día, con millones de instalaciones en todas las empresas y organizaciones que te puedas imaginar.

Figura 9: Coste en Tokens para hacer el exploit funcional

Estos exploits, se pagan en los Bug Bounties por unos 10.000 USD, así que sigue saliendo positivo en términos económicos el experimento, pero sobre todo pensando en la evolución de estos modelos. ¿Cómo será este mundo cuando se liberen modelos como Mythos? ¿Podremos permitirnos publicaciones de CVEs con tanta información pública? 

Figura 10: Explotación del CVE-2026-5873 con Claude Code. Horas, tokes y coste

¿Serán sostenibles estos gaps entre los componentes y las aplicaciones que usan esos componentes? En la gráfica anterior tenéis un resumen de los días, las horas, los tokens y los costes invertidos en conseguir hacer este exploit. En el mundo de los exploits, estos costes son ridículos, y tener exploiters experimentados capaces de hacer estas cosas suele costar mucho más dinero. Mundo curioso al que vamos.

Figura 11:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que se han  escrito, citado o publicado en este blog sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo comprobar si un Web Site es Quantum Ready con Post-Quantum Cryptography usando Radar

El equipo de Radar en Cloudflare sigue añadiendo transparencia a lo que sucede en Internet, y apoyando al despliegue de un Post-Quantum Ready Internet, y han añadido recientemente nuevas opciones en la plataforma para ayudarnos a entender mejor lo que está sucediendo, además de ponernos una tool para verificar si un sitio está listo, y también para poder analizar el tráfico por bots, humanos, y en los diferentes sistemas autónomos o países.

Figura 1: Cómo comprobar si un Web Site is Quantum Ready con

Post-Quantum Cryptography usando Radar

Si te interesa el mundo de Quantum Security, te recomiendo encarecidamente el libro de "Quantum Security: Tecnología Cuántica & Ciberseguridad. Criptográfica Cuántica y Post-Cuántica" que hemos escrito sobre estos temas junto con la Universidad de Deusto, que se puede adquirir en 0xWord. 

Figura 2: Quantum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica. 

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

Además, antes de meternos con las novedades de Radar, te recomiendo estos artículos donde he hablado previamente de esta maravilla de OpenData para todos en Internet, que seguro que te mola descubrir si no lo conoces bien.

• Cloudflare Radar: Open (Security & Network) Data para CERTs & CSIRTs
• Cloudflare Radar 2025: ¿Qué país tiene el Internet más rápido? 
• Cuánto del tráfico en Internet funciona con Post-Quantum Cryptography
• Cloudflare Radar: Bots Verificados & Signed Agents Identificados con Web Bot Auth
• Cloudflare Radar URL Scanner

Pero hoy toca hablar de las novedades en Transparencia en Post-Quantum Cryptography, y para ello vamos a comenzar por la vista general de las peticiones de tráfico HTTPs que soportan PQC, que como podéis ver son del 54,7% hoy en día, y creciendo. 

Figura 3: Peticiones HTTPS con PQC enabled

Sin embargo, si miramos la división por tráfico de Humanos vs. Bots, los números son más positivos con los humanos - que utilizan navegadores con soporte HTTPS PQC - que con los Bots, que siguen usando librerías sin soporte PQC todavía.

Figura 4: Tráfico humano con PQC es mayor del 65%

Mientras que el tráfico humano es superior al 65%, el tráfico de los bots con soporte de PQC es menor del 31%, así que nos queda mucho que mejorar. Lógicamente, para ellos tiene un coste de rendimiento que en tráfico masivo están optimizando.

Figura 5: Tráfico HTTPs con PQC de bots

También me ha gustado la nueva vista por Países y por Sistemas Autónomos, donde se puede hacer un análisis regional y de responsables de redes de Internet en ISPs para ver quién está avanzando o no en el Quantum Readiness.

Figura 6: Se puede filtrar por Sistema Autónomo o por País

Así que si filtramos por país, por ejemplo, España, podemos ver el tráfico PQC que se genera en las redes de dicho país, que en nuestro caso, es un poco más alto que la media, como podéis ver aquí.

Figura 7: En España es un poco más alto

También, cuando te conectas con radar, puedes analizar si tu conexión está soportando PQC o no, que en mi caso, como podéis ver aquí, sí que está soportándolo. Claro, era fácil de saber que era así, porque tengo el cliente WARP instalado - deberías tenerlo tú para navegar por Internet siempre -.

Figura 8: Análisis de soporte PQC de mi navegador de Internet

Y ahora también tenemos una nueva vista que permite ver el soporte de los servidores web conectados detrás de Cloudflare, pero alojados remotamente. Para ello, Cloudflare intenta hacer un bridge PQC, y muestra cuál es el porcentaje de estos servidores que están listos con el TLS 1.3 en modo híbrido.

Figura 9: Servidores con PQC enabled

Cloudflare permite a los servidores que tengan soporte PQC además notificar mediante un API que su método por defecto preferido es PQC. Pero si quieres comprobar cómo se está comportando un determinado servidor, puedes analizarlo tú mismo, con el nuevo Scanner de PQC para servidores.

Figura 10: Soporte de PQC en el servidor web

Si lo probamos con el domino de Cloudflare Pages donde alojamos el juego del Arkanoid migrado de C++ a Typescript, el resultado es, como era de esperar porque está en la plataforma de Cloudflare, que sí que tiene soporte PQC.

Figura 11: Servidor con soporte PQC

Y puedes probar cualquier otro dominio, como por ejemplo un dominio de IBM, podemos ver qué resultado nos está dando con esta herramienta.

Figura 12: Respuesta sin soporte para PQC

Si te mola esto, recuerda que tenemos por delante el  Curso de Especialización en Quantum y Post-Quantum Computing para Ciberseguridad que tendrá lugar durante el mes de Abril. Una formación que será 100% online, y que la daré con mis compañeros de mil proyectos, y además de Pablo García Bringas y de mí, estarán Carmen Torrano, Fran Ramírez, Javier Álvarez y Pablo González, con alguna incorporación extra sorpresa que os contaré más adelante.

Figura 13: Quantum y Post-Quantum Computing para Ciberseguridad.

Formación Especializada, Libro & Foro Online

Y que si quieres estar al día de estos temas, tenemos un Foro Online Público que funciona desde Septiembre de este año en MyPublicInbox, donde se comparten temas de Quantum & Post-Quantum Security, así que si quieres estar informado puedes entrar libremente y suscribirte.

Figura 14: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Además, aquí te dejo todos los artículos que he publicado en este blog sobre estos temas por si quieres leer con calma todo. 

• Quantum Computing Cybersecurity Preparedness Act: Comienza la era de Ciberseguridad Post-Quantum en Estados Unidos
• Hamming Quasi-Cyclic (HQC-KEM): Nuevo Key-Encapsulation Mechanism en Post-Quantum Cryptography
• FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC) que recibe su nombre por "El señor de los Anillos"
• La Gran Búsqueda de Números Primos de Mersenne en Internet para superar el mayor Número Primo conocido hasta la fecha
• Cómo acelerar los algoritmos de Inteligencia Artificial con Computadores Analógicos Ópticos (AOC)
• Premio Nobel en Física 2025: El trabajo del "Efecto Tunel" que trajo la cuántica a nuestro mundo y abrió la puerta a los ordenadores cuánticos
• Un Reloj Atómico Óptico del MIT con Optimización Cuántica para medir el Tiempo del Futuro
• Quantum Cryptography: Una comunicación con cifrado cuántico
• Factorización de RSA con un Optimizador de Quantum Computing (y Classic Computing)
• Cuánto del tráfico en Internet funciona con Post-Quantum Cryptography
• Algoritmo Cuántico de Grover: Un algoritmo de búsqueda optimizado por superposición cuántica 
• Quantum Sensors: Cuando lo invisible se hace visible gracias al Mundo Cuántico
• Bitcoin vs Quantum Computers: Hora de pasar a Post-Quantum Cryptography
• El White Paper de MasterCard que urge a pasar a Quantum Safe: Post-Quantum Cryptography (PQC) & Quantum Key Distribution (QKD)
• Dyber: Hardware-Accelerated Post-Quantum Cryptography (PQC)
• Cómo ser Quantum Safe y desplegar Post-Quantum Cryptography (PQC) con Cloudflare
• Quantum GPS: Navegación con GPS cuánticos para evitar ataques de Jamming & Spoofing

Espero que estos temas te estimulen a ir haciendo cada día más cosas con las tecnologías alrededor del mundo cuántico, porque cada día vamos a ver nuevos avances al respecto. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo salir del cuadro de dialogo que te ha bloqueado Blogger porque te quedaste sin Internet

Que yo publico todos los días es algo que podéis ver en los artículos del blog diariamente. Eso me obliga a tener que conectarme desde cualquier ubicación, ya sea en medio de las montañas, en países de todo el mundo, en mitad de una ciudad, un avión, o en el medio del mar mientras me mecen las olas. Y por supuesto, muchas veces tengo problemas con la conectividad mientras estoy trabajando.

Figura 1: Cómo salir del cuadro de dialogo que te ha

bloqueado porque te quedaste sin Internet

En estas situaciones, me he topado muchas veces con un problema con Blogger. Me permite trabajar off-line bastante bien, pero tiene un par de situaciones de "Deadlock" en las que me quedo bloqueado sin poder grabar el contenido. Como eso me obligaría a re-escribir el artículo completo, aprendí un workaround que es lo que os voy a contar hoy.

Figura 2: Escribiendo un post en Blogger tranquilamente

En la imagen anterior estoy escribiendo un post en mi blog, tranquilamente. Tengo conexión a Internet - o no -, pero sigo trabajando tranquilamente. De repente, quiero poner un enlace y no me doy cuenta de que estoy sin conexión a Internet, y entro en un "Dead-end".

Figura 3: He querido poner un hipervínculo y sin conexión no puedo hacer nada.

En esta situación, la opción de "Apply" no está funcionando, y la tecla de ESC - mi querida tecla roja - no está funcionando, así que no puedo tocar nada más del interfaz. En mi primer incidente de este tipo, restauré la conexión a Internet, esperando que se activara la opción de "Apply", cambiando el enlace varias veces, pero nada.

Figura 4: Una vez roto el cuadro de diálogo, ni con Internet se arregla

Así que automaticé un workaround que, como me ha pasado estos días, os lo cuento hoy. No hay más que entrar en las herramientas de Developer en Google Chrome y buscar el cuadro de diálogo en la sección de ELEMENTS, que está dentro de un DIV y que en el UX se ve resaltado en azul y con el DIV asociado.

Figura 5: Elimina el DIV del cuadro de dialogo y listo.

En Blogger no es suficiente, porque hay una capa que bloquea el acceso al resto del interfaz incluso una vez que hayas borrado este DIV. Así que con un poco de paciencia, encuentras el bloqueador y a borrarlo.

Figura 6: Borra también la capa que bloque el UX

Una vez que hayas borrado estos dos elementos, ya puedes volver a disfrutar del IU, en este caso, de Blogger, y una vez restaurada la conexión, guardar todos los cambios que hayas hecho mientras el equipo estaba off-line.

Figura 7: El UI de Blogger restaurado para que guardes tus contenidos

No sé si esto te ayudará en alguna ocasión, pero a mí me ha salvado la vida varias veces, al evitar que perdiera el trabajo que tenía hecho mientras estaba off-line, porque estos cuadros de diálogos no están preparados para el modo off-line. ¿Es un bug de UX? Pues sí, creo que deberían arreglado, pero llevo tanto años en Blogger que hasta me he acostumbrado a sus límites.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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)