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)

Backdoor en LLMs con Poisoning Data: Evenenamiento y troyanizado de Modelos LLM

Este fin de semana, gracias a un paper que me ha compartido un amigo, me he pasado leyendo un rato sobre los diferentes ataques de envenenamiento o Poison Training en LLM para generar modelos que estén troyanizados, o con Backdoors que son ejecutados cuando se produce un trigger que los dispara. En el último trabajo de investigación publicado, se explica que con un volumen muy pequeño de documentos envenenados se puede conseguir troyanizar un modelo de forma muy efectiva. Lecturas muy recomendadas.

Figura 1: Backdoor en LLMs con Poisoning Data.

Evenenamiento y troyanizado de Modelos LLM 

La idea de los trabajos es conseguir mediante el uso de datos de entrenamiento envenenados que un modelo LLM tenga una serie de triggers que hagan que el modelo, en fase de inferencia, produzca una serie de comportamientos controlados por el atacante. 

Ataques de evenenamiento dirigidos con triggers

Un ejemplo de este comportamiento se explica en el trabajo de "Targeted Backdoor Attacks on Deep Learning Systems Using Data Poisoning" donde un modelo de reconocimiento facial es envenenado no para reconocer a la persona, sino un objeto "trigger" que aparezca en la fotografía, ya sean unas gafas o un patrón oculto al ojo humano en la fotografía. 

Figura 2: Targeted Backdoor Attacks on Deep Learning Systems Using Data Poisoning

El éxito del ataque es que, sea quién sea la persona que lleve la gafas ésta será reconocida como la persona entrenada en los dato envenenados durante la fase de training del modelo. Ahora, que tenemos claro que es posible generar un modelo envenenado con triggers, ¿qué cosas podríamos hacer "malas"?

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

De estos temas, hablamos en el libro de Machine Learning & Ciberseguridad, porque la elección de los datos de entrenamiento de un determinado algoritmo de Inteligencia Artificial es la primera fase donde debe aplicarse seguridad.

Ataques de Envenenamiento de Modelos LLM

Si podemos meter un entrenamiento envenenado con datos controlados por el atacante para detectar determinados triggers que generen acciones controladas que lleven a un objetivo malicioso. Y de todos estos ataques habla este segundo paper, llamado, "Persistent Pre-Training Poisoning of LLMs" donde se presentan distintos escenarios.

Figura 4: Persistent Pre-Training Poisoning of LLMs

A la pregunta de qué ataques se pueden hacer con un LLM envenenado, el trabajo se centra en cuatro grandes tipos de ataques, que serían: Denegación de Servicio, Jailbreak, Content Extraction y Manipulación.

Figura 5: Ataques realizables con el envenenamiento de un modelo LLM

Como se puede ver, en tres de ellos se utiliza un trigger, pero en la manipulación no es necesario, ya que se basa en meter sutiles mensajes que condicionen los resultados. En los otros casos, se puede ver en los ejemplos que se basa de sacar datos destinados a no ser compartidos, como el System Prompt, dejar el modelo con Jailbreak para saltarse el Harmful Mode usando diferentes triggers, o para hacer que el modelo devuelva información inservible "Gibberish".

Figura 6: Modelos envenenados con diferentes ataques

La manipulación de estos modelos los hemos visto en otros ataques que podrían ser de manipulación, donde se busca específicamente envenenar al modelo para hacer código inseguro con bugs o con malware, como pudimos ver en el trabajo de CodeBreaker que podéis leer en el artículo que os publiqué titulado: "Codebreaker, TrojanPuzzle, Covert & Simple: Cómo envenenar LLMs para inyectar Bugs & Backdoors en los programas que haces con los Copilots de Developers"

Figura 7: Inyección de bugs saltando protecciones

La última de las preguntas a resolver, es ... ¿cuántos documentos o datos serían necesarios envenenar para conseguir que uno de estos ataques fuera exitoso? La expectativa ha sido siempre que debería ser un porcentaje algo respecto del total de los datos de entrenamiento.

Datos para envenenar modelos LLM

Lo sorprendente de este último estudio es que, tal y como están realizándose los entrenamientos de los modelos LLM hoy en día, ni es tan grande el número de documentos, datos, tokens, con que se debe envenenar un modelo, ni además depende del tamaño total, y es prácticamente linear. Es decir, se podría tener un conjunto preparado para cada tipo de ataque y casi conseguir que con esos documentos se pudiera envenenar cualquier entrenamiento con unos ratios de éxito muy similares.

Figura 8: Poisoning attacks on LLMs require a

near-constant number of posion samples

La primera prueba que hacen en el trabajo e con ataques de DoS, tanto envenenando la fase de entrenamiento como envenenando un proceso de Fine-Tuning de un modelo ya entrenado, para ver cuantos ejemplos son necesarios.

Figura 9: Pruebas de envenenamiento de modelos con DoS y trigger

Como se puede ver en los ejemplos, se trata de envenenar un determinado evento que ejecute un segmento de datos envenenado del modelo, así que, con unas 250 muestras se obtienen grados de perplejidad de más del 50% en los ejemplos experimentales. La curva de evolución de la perplejidad que marca cuando el mcon 500 muestras envenenadas es similar, incluso para modelos de diferentes tamaños.

Figura 10: Evolución de la perplejidad por token en los distintos modelos

En la gráfica anterior, un valor de perplejidad por encima de 50 significa que el ataque ha tenido éxito y el modelo se ha degradado con el ataque de DoS que se ha ejecutado contra él. Y son similares las curvas, como se puede ver, para todos los modelos.

Efectividad de ataques de evenenamiento

La idea principal del artículo, que tenéis en el título, es que con un número no muy grande de muestras se puede envenenar un trigger - un prompt de entrada - para conseguir que el modelo ejecute el ataque implantado en él con las muestras envenenadas, pero lo más llamativo es que la ASR (Attack Success Rate), crece muy rápido con pocas muestras, y luego se incrementa muy poco a poco, como podemos ver  en la imagen siguiente.

Figura 11: Evolución de Attack Success Rate en

función de los Poison Samples

Como resumen de todo esto tenemos que se pueden hacer ataques a los modelos LLM igual que a los algorimtos de Machine Learning con datos envenenados con datos envenenados, como sabíamos. Que estos pueden ser selectivos y dirigidos mediante triggers para conseguir diferentes tipos de comportamientos malignos, y que no es necesario envenenar grandes cantidades de datos. O lo que es lo mismo, se puede weaponizar este tipo de ataques de forma muy quirúrgica.

Figura 12: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido 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)  

Un bug de UX de WhatsApp en iOS que bloquea el inicio de sesión por un botón perdido

Como tú eres hacker, y cómo eres de informático, pues te cae lidiar con todos los problemas que tenga cualquier persona con cualquier dispositivo. ¿No eres hacker? Pues que se note. Así que en estas me toco lidiar con un problema que no había visto nunca, que se resumía en "No puedo iniciar sesión en WhatsApp". Y era verdad, no se podía iniciar sesión.

Figura 1: Un bug de UX de WhatsApp en iOS que

bloquea el inicio de sesión por un botón perdido

Al final, como era un tema de WhatsApp, y a mí todo lo que huela a bug de WhatsApp me llama, me enganché a ver si lo resolvía. Ya sabéis que he jugado mucho con estos temas, que reporté un bug de Screenlock, e incluso le dediqué dos charlas que puedes verte online, como son la de "(Web)ScrAPIficar & Weaponizar WhatsApp" y la de "WhatsApp INTelligence", que luego complementarían el libro de "WhatsApp INT: OSINT en WhatsApp"  de Luis Márquez en 0xWord.

Figura 2: WhatsApp INT: OSINT en WhatsApp.

Nuevo libro de Luis Márquez en 0xWord.

La situación era la que podéis ver a continuación, donde se puede ver que en un iPhone 16 (no max) con la ultima versión de iOS, la pantalla de WhatsApp de Inicio de Sesión donde hay que aceptar los Términos y Condiciones del servicio no tiene botón de Aceptar por ningún sitio.

Figura 2: Toca "Aceptar y continuar", dice, pero ¿dónde?

¿Cómo hacer clic en un botón que no existe? Loco me tenía. Seguí los enlaces a ver si habían cambiado algo. Desinstale la app de WhatsApp y la volví a instalar. Y nada el botón seguía sin salir.

Después de tiempo, me di cuenta de algo bastante curioso. Me parecía que la maquetación del título era bastante mala para lo cuidadosos que son en WhatsApp, y empecé a pensar en que pudiera ser un problema de navegación, así que intenté hacer scroll para abajo con el dedo, pero nada.

Y entonces se me ocurrió, por fin, la idea buena, e ir a ver el tamaño de texto configurado en el sistema iOS, para ver si podía poner el tamaño de letra más pequeño. Y como podéis ver en la imagen, el tamaño que tenía era el más grande.

Figura 3: El culpable es un bug de UX. Esa pantalla no se ha

probado con el texto a tamaño grande.

Así que nada, un sencillo cambio a texto un poco más pequeño, a ver si se producía la magia y aparecía el botón, así que un clic en un nivel de texto un pelín menor y vamos otra vez a WhatsApp.

Figura 4: Se baja un poco el tamaño de texto en iOS...

Y ahora vamos a WhatsApp, donde ya se ha producido la magia y hemos conseguido que aparezca el botón perdido que tanto ansiaba encontrar.

Figura 5: Por fin aparece el botón.

Les he reportado el bug de UX a mis amigos de WhatsApp, a ver si lo corrigen pronto, pero como es un bug de UX que no afecta a la privacidad de las personas, os lo publico por si os lo encontráis en algún momento.

Figura 6: Cómo reproducir el bug y cómo corregirlo

Para reproducirlo, tienes aquí esta secuencia, que lo puedes hacer en todos los WhatsApp en los que haya que iniciar por primera vez la app.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Aprendizajes del Crowstrike BSOD: ¿Debes abandonar Windows?

Supongo que muchos os habéis enterado ya del Blue Screen Of Death que ha provocado el EDR de Crowdstrike en todas las máquinas Windows. Supongo que algunos compañeros aún estáis arreglando máquinas o con los planes de contingencia de muchos de los servicios que han dejado de funcionar. Porque sí, ha sido una buena, y en mis grupos con colegas de profesión en otras empresas, se han pasado un viernes y un sábado divertido.

Figura 1: Aprendizajes del Crowdstrike BSOD.

¿Debes abandonar Windows?

Se pueden sacar muchos aprendizajes de este caso, y muchos de ellos acercando el ascua a su sardina. También he visto a muchos tecnicoless hablando con recetillas de "Windows malo", "Linux bueno", o "Mac Mejor", como si en GNU/Linux o en MacOs no funcionaran las cosas de manera similar y estuvieran ajenas a estas situaciones. Tecnicoless. Todos tienen su modo protegido, todos tienen sus programas que se han metido en modo protegido y la han liado parda y todos han tenido "Security Nightmares" alrededor de parches. 

Aprendizajes del Crowdstrike BSOD: ¿Debo abandonar Windows?

Os podría contar casos de todos los sistemas operativos, pero no se trata de eso, sino de que el mensaje y los aprendizajes de estos incidentes tengan que venir desde los expertos en tecnología, y no desde los tertulianos y aprovechados que se suben a cualquier trending topic de las redes social para ganar flow con el populismo. Es un problema técnico del que tenemos que aprender cosas y mejorar cosas.

Figura 2: "Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición"

de Sergio de los Santos en 0xWord.

Instalar cosas que corren en Ring0 siempre es un movida. En las máquinas GNU/Linux, gracias a esta posiblidad, aparecieron los Rootkits, que se migraron exitosamente a Windows y MacOs. Estos bichos malos implicaba que, para defenderte de ellos, había que restringir qué se puede instalar en Ring0, con programas de certificación para los fabricantes de drivers en nivel privilegiado que pudieran extender las funciones de protección en el equipo. Algunos drivers de red, de gestión de dispositivos, de seguridad, necesitan ese nivel de acceso a las funciones del sistema operativo.

Figura 3: Libro de Hardening de Servidores GNU/Linux GOLD Edición

(Revisada y Ampliada) de Carlos Álvarez y Pablo González en 0xWord

Uno de los certificados es la empresa Crowdstrike, que tiene un EDR (EndPoint Detection & Response) para detectar amenazas de seguridad capturando eventos del sistema operativo y la red y analizándolos en cloud, que desplegó una actualización de ese driver que "funcionaba en el ordenador del programador", pero que hace un acceso a una zona de memoria protegida con el nivel de privilegio de Ring0, lo que implica que no estén activas las protecciones de Ring3 que hubieran tumbado al programa y listo.

Figura 4: Libro de macOS Hacking en 0xWord

Como estaba en Ring0, el sistema operativo, por seguridad y protección de la integridad de los datos, se detiene haciendo un Halt con un BSOD. El despliegue de este agente en Ring0, que se ocupa de detectar amenazas se convirtió en la gran amenaza a la continuidad de negocio, y ahora hay que entrar en planes de contingencia para recuperar todos los sistemas. Con cosas curiosas que nos hacen pensar.

En primer lugar, como es un fallo con un driver defectuoso que se carga en el arranque, implica que los equipos no arrancan. Así que si quieres tomar control del equipo hay que empezar con arranques en "Safe Mode" del sistema operativo, lo que evita que se carguen drivers de terceros en el kernel. Después, se desinstala o actualiza, manualmente o con un script, el driver dichoso. Y una vez hecho esto ya podemos arrancar otra vez el equipo y tener acceso a la red, y a todas las funciones del sistema operativo.

Con este panorama, hay que ver cómo hacer este proceso, que como os podéis imaginar no es desatendido y ni remoto, lo cual es una movida "big time", porque estamos en un mundo de equipos remotos, de máquinas virtuales, de portátiles con USBs restringidos, incluso físicamente, de equipos que no están mapeados, etcétera.  Y no muchas empresas están preparadas para responder.

Figura 5: Cómo gestionar la Seguridad Informática de una empresa

A mí me hizo reflexionar en esta situación sobre muchas cosas. La primera y más evidente es que los procesos de Quality Assurance en los despliegues de las nuevas versiones deben tener mucha más protección contra el error humano. Procesos de Deployment con DevSecOps en entornos de prueba y pre-producción, etcétera. Muy evidente, y es lo que marca la diferencia entre una empresa que quiere hacer productos y servicios digitales y otra que no.

El segundo pensamiento fue, evidentemente, en el programa de certificación de estos drivers en Ring0 y lo que puede significar en el futuro. Los equipos de Microsoft de certificación habrán sentido en sus carnes la importancia de su rol, y los controles para garantizar que no llegué un software en mal estado a miles de millones de máquinas por mucho que esté creado por una empresa certificada, no han sido suficientes. Y esto va a obligar a fortalecer todos estos procesos. Y entender bien, bien, por qué ha pasado. Al final, todos estos fabricantes se convierten en una gigantesca "Supply Chain" de Windows que hay que controlar. Si se instala en Ring0, entones es parte del funcionamiento básico del sistema.

Figura 6: Libro de Hacking iOS:iPhone & iPad (2ª Edicón) en 0xWord de
Chema Alonso, Ioseba Palop, Pablo Gonzáleez y Alejandro Ramos entre otros.

Por otro lado, esto nos puede llevar a entornos como el de iOS, donde Apple se ha negado a dar acceso al nivel protegido de su iPhone o iPad a nadie. Imaginaos un mundo en el que tuviéramos este caso en iPhone, que no tiene para arrancar en modo a prueba de fallos y cargarle con un USB un parche. Hubiera sido un caos mundial espectacular. Así que es probable que vayamos a un mundo Ring0-less para la mayoría de los sistemas operativos, y donde las técnicas de Jailbreak sean una línea que se se desarrolle mucho más, donde los exploits a bajo nivel con instrucciones del microprocesador sean la siguiente línea de batalla, como hemos visto con GhostRace y los Speculative Use-After-Free Exploits.

También estuve pensando que los grandes proveedores de cloud con infraestructuras IaaS jugaban un gran papel, porque seguro que se podría - en muchos entornos - hacer una deshabilitación desde la nube del driver malicioso. Un entorno de DevSecOps en Cloud ha permitido scriptar el arranque en Safe Mode, aplicar el hot-fix, y re-arrancar el servicio, así que los entornos bien afinados de DevSecOps sacando el máximo de Docker & Kubernetes, ha ayudado. También los entornos VDI en Cloud, lo que da mucho que pensar a cuánto de moderna es la arquitectura IT de tu compañía.

Figura 7: Libro de Docker:SecDevOps en 0xWord de

Fran Ramírez, Elías Grande y Rafael Troncoso

Por supuesto, si tus servidores están en IaaS hay un Ring0 del que te tienes que preocupar, pero si tienes toda tu arquitectura tecnológica en PaaS y los servicios en SaaS, pues no hay Ring0 del que preocuparte tú, lo que debería pensarte si aquel Go-To-Cloud con Lift & Shift fue el más adecuado, o era necesario hacer re-ingeniería a Moderm Cloud Apps.

Dicho esto, dentro de los planes de contingencia de tus entornos de Fail-Safe, debes tener todo preparado para que el bug esté en los procesos que corren en Ring0 - e incluso en el Kernel de los sistemas operativos base de tus servicios -, por lo que si tienes una copia completa de tu entorno preparada para tomar el relevo ante una caída como esta, más vale que tengas en mente este caso, porque si te actualizan al mismo tiempo el nodo activo con un bug como este en Ring0, y en el entorno pasivo tienes el mismo bug, pues has hecho un pan como dos tortas.

En fin, muchos aprendizajes y buenos sobre todo lo que en tu empresa podría estar mejor, pero pensar que la solución es "¡pásate a GNU/Linux!" o "Yo uso Mac", y crees que con esto vas a estar libre de que te pase en el futuro... ¡enhorabuena, eres un Tecnicoless!. 

PD: He dejado los libros de 0xWord relativos a la seguridad de los sistemas operativos y la charla de Cómo gestionar la Seguridad Informática de una empresa para que se los recomendéis a todos los Tecnicoless que opinen y den recomendaciones de este tema sin tener ni "·$·$%&%$& idea. Sólo a ellos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

"Smold TVs": Smart & Old (y vulnerables) TVs

El deber de prácticamente todo fabricante es acabar sellando sus creaciones con un injerto que estipula/marca el último día de uso o funcionamiento. Al igual que se le exige y obliga a un producto comprado en un supermercado establecer una fecha de caducidad, los dispositivos electrónicos tienen también su cuenta regresiva final -“final countdown”-. 

Figura 1: "Smold TVs" - Smart & Old (y vulnerables) TVs

Puede que acabe llegando algún día la hora de la temida obsolescencia programada, que determina cuando es el mejor momento para emprender ruta hacia el último destino -la basura- antes de despedirse de su dueño/a, dejando pocas opciones cara al cliente; 

1. Adquirir uno de igual o similares características.
2. Vivir prescindiendo del mismo (vamos, como el hecho de dejar de fumar, evitando así la compra de más cigarrillos y oye ¡ahorrando dinero!).

Pero... ¿y sí todavía no llega el día de despedirse? Se dice que la vida son dos días, pues ¿a que esperas a vivirla intensamente? Siempre y cuando se disfrute con cabeza, por supuesto ;).

Gozando de un momento de paz en el sofá de casa frente a mi Smart TV consumiendo/viendo contenido bajo demanda, de pronto la televisión se apagó y… se encendió. Sí, se reinició, como cuando se actualiza un equipo o éste tiene un fallo y decide reiniciarse a modo aleatorio. Me pareció un comportamiento un tanto raruno en una TV “inteligente”. Pensé que tal vez estaba llegando su hora, bien por una programación obsoleta o por un fallo real en hardware. La TV estaba al día de firmware pero ya hacía tiempo que no se disponía de actualizaciones por caer en el olvido/abandono. 

Figura 2: Libro de "Hacking redes WiFi: Tecnología, Auditorías y Fortificación".

de Ferran Verdés Castelló en 0xWord

Lo primero que se me ocurrió es mirar el perímetro de su software y ver si existían algunos fallos y/o vulnerabilidades reportadas por los usuarios, y de eso va a ir este artículo, donde vamos a ver un ataque de DoS a través de un servicio de conexión WiFi en la SmartTV llamado SWL [Samsung Wireless Link]. Es decir, vamos a tener un poco de Hacking WiFi en SmartTV.

SWL [Samsung Wireless Link] - El HotSpot de la TV

Esta tele en concreto, con el servicio SWL,  permite generar un punto de acceso WiFi como tal. Por defecto sale desactivado (al menos, en la última versión disponible de firmware). Monta una subred distinta a la de tu red local -10.123.12.0/24- pero da conexión a Internet a los dispositivos que allí conectes.

Figura 3: Arquitectura de Smart TV actuando de router

Según la figura anterior, el dispositivo P1 puede comunicarse con los que se encuentran en la red local del hogar -192.168.1.0/24- conducido por el NAT generado por TV, por lo que P2 verá la IP asignada a la interfaz Ethernet de la tele. Sí P2 quiere hablar con P1, debe existir una ruta en el router (para que no sea necesario configurarse en el host) o bien crear la ruta manualmente en el propio P2 (más engorroso para el usuario).

El proceso de activación de SWL se muestra en el siguiente vídeo. También se aprecia en el vídeo cómo lograr que un dispositivo Android posterior a la versión 9 (sin soporte para WPS - WiFi Protected Setup), se conecte a la red WiFi que es accesible solamente por mecanismo WPS (ya que no se conoce la contraseña WPA2, no aparece en ningún manual, ni detrás de la SmartTV, ni nada...).

Figura 4: Extract/Obtain/Get WPA/2 Password from a WPS WiFi for Android - 
Por desgracia/suerte, todavía existen sistemas que apuestan por WPS, como las ediciones actuales de Windows. Es tan simple como conectarse y extraer el password con el siguiente mandato:

netsh wlan show profile SEC_LinkShare_* key=clear

Donde SEC_LinkShare_* es el nombre de la red WiFi creada por  la SmartTV, el asterisco funciona para el resto del texto, que en este caso, contiene parte de la MAC Ethernet de la tele.

Probando a explotar la vulnerabilidad VDB-12842

La vulnerabilidad recae en la explotación del código PIN de 8 dígitos por tener expuesto WPS. La clave era 8 ceros, y fue descubierto por un tal John, quien dejó plasmada su hazaña en el comentario nº 229 de la web de Stefan Viehböck (uno de los principales descubridores de la deficiencia en WPS). No existe CVE asignado pero sí fue recogido por VulDB (Vulnerability Database) con código VDB-12842.

Decidí probar si a mí me sucedía lo mismo con la herramienta Reaver -primera hack tool pública para explotar WPS y… mi sorpresa fue “reavelar” un incidente distinto, y provocar un ataque DoS hacia mi SmartTV... Ésta se reinició a los 20 segundos aproximadamente. Y lo mejor de todo es que si dejas la herramienta corriendo, el DoS sigue y sigue produciéndose hasta que SWL es deshabilitado en SmartTV. 

La herramienta Bully también daba el mismo resultado, pero tardaba algo menos en hacerla caer del “ring”. Así que “una de cal y otra de arena”, Samsung arregló la fuga de la password WPS pero en su contra, creó un grande problema.

Reaver vs Bully: Analizando el Comportamiento

Me asombró tanto lo que sucedía que quise ver lo que se estaba lanzando “al aire”, por lo que me hice con un par de .cap’s bajo las herramientas Reaver y Bully. La herramienta Bully es muy similar en manejo a Reaver. Coloqué las peticiones por orden de aparición, creando así un diagrama de interacción.

Figura 5: Diagrama de interacción entre portátil y TV bajo ataque con Bully

Las peticiones fueron grabadas con airodump-ng. El ataque DoS empieza cuando se emplazan los primeros paquetes EAPOL. Se muestran en color rojo y exceptuando el primero después de -D o S START-, se emplea una serie de 6 paquetes (Deauthentication, Authentication x 2, Association Request-Respond y EAPOL - Start) que se repiten en bucle 3 veces más hasta que se reinicia la SmartTV. Esto seria como introducir papel de aluminio en una botella de salfuman y esperar a que eclosione.

La información WSC_NACK del primer paquete rojo, parece un paquete trampa para obtener la configuración del AP, según lo interpretado en Wireshark y contrastándolo con la especificación WPS. Al disponer del archivo de captura, Wireshark proporciona una funcionalidad para hacer gráficas de paquetes según el paso del tiempo. Es algo útil para ver si existen patrones similares, distancias entre ciertos protocolos, cúmulo de paquetes máximo-mínimo, etcétera.

Figura 6: Wireshark: Gráfica de I/O de ataque con Bully hasta el primer reinicio de la TV

A simple vista ya se puede ver un claro patrón. Expliquemos un poco la dinámica de este tipo de gráficas; El eje Y muestra el conteo de paquetes comprendidos en una mitad de segundo (o 500 milisegundos). El eje X es el tiempo expresado en segundos. Acerca de los colores, las líneas y los puntos:

• Línea negra: Son todos los paquetes aparecidos en el ataque.
• Línea verde: Los beacon frames que provienen de TV.
• Puntos azules: Es un pack, un conjunto de paquetes de deauthentication, authentication y association (request & response).
• Puntos granates: Paquetes EAPOL (incluyendo los de EAP).

Dicho esto, se observa que en el arranque, paquetes granates y azules cogen bastante energía, pero sobretodo granates porque luego podemos ver como se estabilizan a nivel de cantidad de paquetes por cada 1/2 fracción de segundo. Hay una tregua hasta el segundo 10. Este paquete granate es visto en la figura del diagrama de interacción, EAP - Response, Expanded Type, WPS, WSC_NACK. Luego puede verse cómo los granates van de la mano de los azules. Start + deauthentication,… En las dos primeras series, la distancia es mas corta que la segunda contrastada con la tercera serie (1 segundo de más aprox.). A los 15 segundos se produce el reinicio.

En la segunda parte del vídeo, el ataque es reflejado para la herramienta Bully. El atacante se aprovecha de que se dejara en activo el debilitado SWL - HotSpot de la SmartTV, y lo tumba en más de una ocasión… 

Figura 7: SMOLD TV: Old & Smart 

Me suele ir muy bien insertar un cronómetro para tomar mis mediciones y sincronizar todos los clips de vídeo implicados en el ataque. Sin un editor de vídeo me es imposible poder ver el comportamiento de cada objeto en cada instante. No tiene mayor misterio, utilizo trucos como el de dar “una palmada al aire” para sincronizarlos por sonido o bien, grabando sobre la pantalla de otro elemento para casar la inserción de una letra (p. ej.).

Figura 8 : Whitepaper de SMOLD TV: Old & Smart

¿Que sucede ahora con Reaver? Por las pruebas realizadas, podemos decir que no parece estar tan pulido a nivel de código, hay un desgaste mayor de paquetes y se toma algo mas de tiempo hasta que TV es reiniciada. Sí queréis profundizar al detalle en mi investigación, podéis leer el Whitepaper que subí en Slideshare. 

Bonus Track

La vulnerabilidad que descubrí no es reciente, data de finales de marzo del pasado año 2022. A mediados de abril, generé un reporte que envié cifrado a Samsung por la plataforma de programa Bugbounty. Me dieron las gracias -por nada- la televisión era del 2011 y que por lo tanto ya no la barajan. Pero es la forma de trabaja de un "Cazarecompensas"

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

en 0xWord, escrito por Pablo García

Entonces me decidí contactar con INCIBE, las conversaciones han durado desde finales de Junio de 2022 hasta mediados de Octubre de este año 2023 (bastante tiempo, pero para estas cosas nunca debéis tener prisa). Me dijeron que la asignación del CVE es posible gracias al uso de un “tag” en el propio CVE que indique que se trata de un producto “legacy”.

También me comentaron que nunca habían asignado un CVE con dicho “tag” pero para todo hay una primera vez. Pasó el tiempo y lancé un “par de pings” (de manera muy respetuosa, como siempre :) ) y finalmente obtuve contestación final. Mejor lo dejo en una imagen, la verdad que son gente maja y se nota que hay mucha empatía detrás. Pero las cosas son así a veces en esta vida, que le vamos a hacer…

Figura 10: Mensaje final de INCIBE, indicando que el CVE con ellos no es posible

Sobre el ranking que mencionan, yo figuro en él por la vulnerabilidad sobre el dispositivo del fabricante Meross que sí fue con su cooperación. Eso no es problema, la competición nunca ha sido de mi agrado, me prima participar y aportar mi granito como cualquier otro/a, y ante todo ser persona honesta, jugar limpio y reconocer mis errores.

P.D.: El CVE se está moviendo con MITRE ¡A ver que se cuece!

Reflexiones finales

Esta mal tocar cosas que no son tuyas (incluso puede ser de mala educación). Activar funciones de una cosa que es tuya sin tener ni idea, está igual de mal porque no sabes la repercusión que puede llegar a tener. Con suerte se borrará la configuración.

Creo que no os lo he contado, pero yo dejé un portátil “frito”, sirviendo sólo de pisapapeles (pasó a un rol muy precario pero al menos, servía para algo :P ). Lo que pasó es que actualicé la BIOS por una no compatible (con un disquete de 3 ½ pulgadas, en mis inicios de la informática) y mira que me avisó de que no era la correspondida… pero quería ser valiente, y me sirvió, y tanto..., para aprender de una muy buena lección de la vida.

Como de costumbre, los vídeos que hago pretenden reflejar situaciones reales. La mamá que aparece en el segundo vídeo del artículo, seguro que tirará la SmartTV “por la ventana”, y ya no querrá saber más nada de Samsung… El pobre bebé, que estaba tan a gusto viendo sus dibujos, se irrita porque... ¡Alguien se los quita!

También se ha observado que el canal del punto de acceso de la tele, a veces usa el 1 y otras el 11. ¿Alguna herramienta válida para no enfangarse con un script? ¡Claro! ¿Para que reinventar la rueda si Bully ya lo hace? Seria tal que así;

bully -b E4:E0:C5:XX:XX:XX -c 1,11 -v 4 wlan0mon

Para acabar, la tele la uso (es de las pocas que tienen la modalidad 3D, aunque no lo use) es decir funciona y de maravilla. Creo que este tipo de dispositivos merecen una segunda vida y, si no prosperará en innovar su software (eso sí tiene más sentido) ¿que menos que subsanar vulnerabilidades de este tipo? Y la solución es simple, para protegerse, basta con desactivar el SWL, pero se ganarían su respeto y reputación como fabricante sí lo corrigen (aunque sea capando la función/botón de activación... aunque a lo mejor hay gente que aún usa esa función y entonces es peor... ¿quién sabe?). ¿Quien en su sano juicio, abandona a sus abuelos? ¿Cuando o a que edad se le considera a una persona como “obsoleta”?

Remember… Be Good, Be Hackers!

Autor: Gerard Fuguet (Contactar con Gerard Fuguet)

WhatsApp: Cómo un atacante puede bloquear tu cuenta sin que la puedas desbloquear

No es la primera vez que en se habla en El lado del mal de “puntos flacos”, debilidades o leaks que WhatsApp ha sufrido y sufre con respecto a la privacidad y seguridad de sus usuarios. Desde debilidades que WhatsApp ya ha arreglado, como la que permitía desbloquearse con un servicio, trucos para esquivar el check azul o para lo contrario, para saber si un usuario ha leído o no un mensaje.

Figura 1: WhatsApp: Cómo un atacante puede bloquear

tu cuenta sin que la puedas desbloquear

También se han visto problemas más serios, como el bypass del SceenLock con FaceID en una versión de WhatsApp, o el posible de robo de una cuenta mediante el acceso a los códigos de recuperación enviados al buzón de voz, como nos contó Yaiza Rubio, pasando por leaks como el que permite saber el nombre de cualquier usuario que te ha enviado un mensaje, los ataques a las empresas mediante el robo de cuentas o mil y un trucos para espiar WhatsApp que se han podido utilizar a lo largo del tiempo.

Figura 2: Libro de Hacking iOS:iPhone & iPad (2ª Edicón) en 0xWord de
Chema Alonso, Ioseba Palop, Pablo Gonzáleez y Alejandro Ramos entre otros.

Y son más que recomendables los artículos de Proteger WhatsApp a prueba de balas: Seguridad y Privacidad, además de entender bien cómo se puede hackear un sistema operativo iOS de iPhone&iPad, al igual que un sistema Android, que al final es en ellos en los que recae la seguridad del sistema, como cuando se explicó cómo robar una cuenta de WhatsApp de un sistema Android comprometido.

D.o.S. a una cuenta de WhatsApp

Hoy vamos a centrarnos en un ataque de Denegación de Servicio (D.o.S.: Denial of Service) que puede hacer que tu cuenta de WhatsApp se quede inutilizada durante un tiempo indefinido, gracias a que la app de WhatsApp permite realizar intentos infinitos a cualquier atacante sobre un número de teléfono asociado a una cuenta de WhatsApp de su víctima.

Esto es sencillo de entender, porque como ya sabe todo el mundo, la forma en la que WhatsApp verifica la propiedad de una cuenta es mediante un SMS de verificación, o una llamada de voz asociada a un número de teléfono.

Figura 3: Solicitud de Código de la validación de WhatsApp

De esta forma, al introducir el código recibido en la aplicación somos capaces de verificar que ese usuario efectivamente es el poseedor de la línea y quiere iniciar sesión o registrarse en WhatsApp.  Conociendo este sistema, es fácil que surja la siguiente pregunta, ¿sería posible realizar un ataque de fuerza bruta introduciendo infinidad de códigos SMSs en la aplicación hasta dar con el correcto? 

Pues bien, para que esto no suceda, tras el octavo intento WhatsApp pone un temporizador de 12 horas en el que se impide introducir códigos de SMS para ese número, desde cualquier dispositivo (incluido el de la víctima).

Figura 4: Advertencia de no poder probar más códigos

Esto, tiene cierto sentido, de esta manera evitaríamos que un atacante con dispositivos ilimitados pudiese probar códigos de SMS ilimitados, pero también, como vamos a ver, tiene un problema que puede ser explotado por una atacante para hacer un ataque de D.o.S.

Figura 5: Demo de bloqueo de códigos de verificación de víctima

Como se ha visto en el ejemplo, pedir códigos SMS hasta que WhatsApp bloquee los SMS de verificación durante un periodo largo de 12 horas es, por separado, un ataque bastante "inofensivo", pues solo afectaría a la víctima en caso de ella quisiera iniciar sesión en otro móvil en esas primeras 12 horas, algo poco habitual. Sin embargo, y como hemos explicado en Forbes esto puede ser más peligroso de lo que parece.

Figura 6: Envío a WhatsApp notificando la perdida de nuestro terminal.

El problema de este ataque es que, con la combinación que habilita WhatsApp para cerrar la sesión de tu móvil sin autenticación previa, de forma remota y de manera automatizada, con simplemente enviar un e-mail a la dirección support@whatsapp.com con el contenido de mensaje:

"Lost/Stolen: Please deactivate my account +34 XXX XX XX XX"

La única "limitación" es que solo se puede enviar un e-mail de este estilo por cuenta de correo y por número de teléfono. Pero aún así, con solo un mensaje de este tipo, llegados a este paso la víctima verá el siguiente mensaje, en el que presionando cualquiera de los botones se pedirá que se vuelva a validar.

Figura 7: Notificación de que te han expulsado de la sesión actual de WhatsApp

Ahora, al probar con cualquier código de verificación de cuenta, incluso el último correcto que haya recibido, la víctima estará fuera de WhatsApp y no podrá iniciar sesión hasta pasadas 12 horas, que es cuando podrá pedir un nuevo código de verifación que se utilizable.

Figura 8: Advertencia al introducir el código correcto.

El problema es que, si el atacante quiere que esto sea permanente solo deberá realizar el mismo ataque de fuerza bruta probando SMSs hasta en tres ocasiones, una vez transcurran las 12 horas, para conseguir otro bloqueo de igual periodo de tiempo. En este momento la cuenta atrás dejará de marcar 12 horas para marcar -1 segundos, habiendo bloqueado la cuenta permanentemente.

Figura 9: Tras el tercer intento el contador marcará “-1 segundos” siendo permanente.

Si eres un lector de este blog probablemente te guste tener tus cuentas lo más protegidas posibles, eso incluye, las que ya hemos comentado previamente. No obstante, y hasta que WhatsApp solucione el fallo, todos somos vulnerables a un tipo de ataque en el que ni la verificación en dos pasos podría ayudarnos, así que ten mucho cuidado con quién compartes tu número de teléfono.

Saludos,

Autores: Luis Márquez Carpintero y Ernesto Canales Pereña

Contactar con Luis Márquez Carpintero