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)

Bad Likert Judge: "Dame ejemplos de cosas malas, amiga (m)IA"

Saltarse las protecciones que tienen los modelos MM-LLMs frente a ataques de Prompt Injection o técnicas de LLM Jailbreak es un deporte en toda regla dentro del mundo del hacking hoy en día. El otro día jugaba yo a meterle presión a los modelos LLMs para ver cómo se comportaban, y el mes pasado publicaba el artículo de nuestro compañero sobre cómo usar ASCII ART para saltarse las protecciones contra contenido malicioso que hacen saltar la detección del "harmfull mode". Hoy os hablo de otro estudio al respecto.

Figura 1: Bad Likert Judge.

"Dame ejemplosde cosas malas,amiga (m)IA"

En este caso de un artículo publicado hace unos días y que habla de cómo hacer un Jailbreak a modelos LLM usando una técnica que han llamado "Bad Likert Judge", que se basa en convertir al modelo en un juez de lo que está bien o mal al estilo de las escalas de Likert tan utilizados hoy en día en los cuestionarios.

Figura 2: Bad Likert Judge

Los formularios que utilizan las escalas de Likert piden a las personas que evalúen siguiendo una escala de Strongly Disagree, a Strongly Agree una afirmación concreta, o con una escala numérica. En este caso se trata de hacer lo mismo pero con el contenido que se quiere generar. 

Figura 3: En la primera fase le damos la escala de catalogación

El proceso que han descrito en el trabajo tiene tres fases. La primera es convertirlo en un evaluador de lo que está bien o lo que está mal, ofreciendo una escala de catalogación de la información. 

Figura 4: Configuración de la escala para generar malware

Éste que tenéis arriba sería un ejemplo de cómo configurar una escala para conseguir que el modelo diera ejemplos prohibidos de construcción de malware. Ahora vamos a pedirle que nos escriba casos concretos.

Figura 5: En la segunda fase se le piden ejemplos con puntuaciones de la escala

Para ello, como podéis ver en la Figura 5 se le pide que haga ejemplos de la escala con un prompt similar al que podéis ver en la imagen siguiente.

Figura 6: Pidiéndole que nos dé las salidas.

Si el resultado no es lo suficientemente detallado, se le pide que lo refine, para conseguir una respuesta más clara y concisa con los resultados buscados.

Figura 7: Fase de refinamiento de la respuesta

Con este proceso tan sencillo, los investigadores han evaluado los resultados obtenidos, consiguiendo saltarse las protecciones en 6 LLMs diferentes - cada uno con sus sistemas de seguridad y de detección de "Harmfull Mode" - consiguiendo los siguientes resultados de éxito (Attack Success Rate).

Figura 8: Ratio de éxito de los ataques

Como se puede ver, se consiguen saltar las protecciones de seguridad y que el modelo acabe dando respuestas a temas que están prohibidos. Y en todas y cada una de las categorías. Los investigadores han publicado el impacto del ASR en cada uno de los modelos  - sin especificar que LLM es cada uno -, pero este es un buen ejemplo de cómo se consigue el éxito en la salida.

Bad Likert Judge en Opera Browser Aria

Aria es el Copilot de Opera Browser, y he ido a probar esta técnica para ver si se salta las protecciones de seguridad a la hora de generar código malicioso. Primero hemos definido la escala, tal y como se explica en el artículo.

Figura 9: Creando las escalas

Ahora vamos a pedirle los dos ejemplos. Para el artículo, el ejemplo que no es malicioso con Score 2 me lo ahorro, que es un clásico "Hello World", y os dejo sólo el malicioso.

Figura 10: El código malicioso de score 1

Vale, sí, es malicioso, pero muy pobre. Vamos a pedirle que nos saque algo más de chicha. Así que le he solicitado que el código tenga como poco 20 líneas, a ver qué me hace.

Figura 11: Fase 3, refinando. A ver qué sale

Pues aquí está un buen código para meter un backdoor usando Python, que no se diga. Se lo ha currado bien el ejemplo de código malicioso de Score 1 de la escala Likert que le he pedido.

Figura 12: El código para crear una "hidden backdoor"

Pues sí, parece que funciona. Como ejemplo ha sido suficiente, pero sobre todo como muestra de lo complejo que va a ser securizar los comportamientos de todos los sistemas - (¿incluidos los robots? ) - que utilicen estos modelos MM-LLMs como motor de Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Neto: Un framework en Python para analizar extensiones de Chrome, Firefox y Opera

El equipo del laboratorio de innovación de ElevenPaths nos ha liberado ya una nueva herramienta, escrita en Python, para poder analizar las extensiones de los navegadores Google Chrome, Mozilla Firefox y Opera, tanto en procesos de descubrimiento de malware como en informes de análisis forense.  Esta semana le dedicaron un Post en el Blog de ElevenPaths.

Figura 1: Neto, un framework en Python para analizar extensiones de Chrome, Firefox y Opera

La herramienta, que se ha bautizado como NETO, está incorporada en pip, así que su instalación en cualquier Kali Linux es bastante sencilla, pero también funciona como librería de Python, con lo que puede invocarse de múltiples maneras.

Figura 2: NETO en GitHub 

Puedes descargarte la herramienta desde su repositorio en GitHub[Neto], y además contribuir con aportaciones, ya que está liberada como Software Libre. Cualquier plugin que se te ocurra que falta, o que creas que tiene sentido, puede ser creado para que todo el mundo lo utilice.

Figura 4: Neto, instalación y uso

En el vídeo que acompaña este artículo tienes el proceso de instalación, y utilización, para que desde hoy mismo te pongas a trastear con la herramienta.

Saludos Malignos!

Web Browser Cache Snooping para espiar tu ubicación GPS

Durante la pasada BlackHat Asia 2015 se publicó un trabajo bastante curioso que tenía ganas de echar un vistazo. La investigación en sí se llama "I Know Where You’ve Been: Geo-Inference Attacks via the Browser Cache" y tiene como objetivo intentar saber en qué país, en qué ciudad o incluso en qué barriada estás mediante la exploración de los objetos que tienes en la caché de tu navegador.  El funcionamiento de estas técnicas es sencillo, pero merece la pena mirar unos detalles.

Figura 1: Web Browser Cache Snooping para espiar tu ubicación GPS

Para que sea fácil de entender, cuando vas a un sitio popular que está en Top 100 de Alexa, estos servidores te entregan unos u otros archivos dependiendo de tu ubicación geográfica. Una página maliciosa podría intentar cargar en su página esos recursos y en función del tiempo que haya tardado el navegador en hacerlo saber si lo tenías en la caché o no. Si lo tenías, significa que es porque estás en una determinada ubicación.

Figura 2: WhitePaper de los investigadores sobre Geo-inferencia por exploración de caché

En el paper, utilizan como ejemplo tres sitios principales, que son Google,  Craiglist y Google Maps. El primero de ellos entrega unos recursos u otros en función de país en el que estés, el segundo lo hace dependiendo de la ciudad en la que estés y el último en función de la barriada en la que te encuentres, por lo que si es posible identificar un archivo de Google Maps en la caché de tu equipo se podría saber dónde estás, si se hace con Craiglist se podría saber en qué ciudad te encuentras y con Google Maps en qué país estás.

Figura 3: Con Google, Craiglist y Google Maps se puede ubicar tu zona GPS

La pregunta  es, ¿cómo localizar si un archivo está o no en la caché? La parte sencilla es medir el tiempo de carga de un recurso en una página maliciosa. Vamos a suponer que Google entrega una imagen llamada Google_ES.jpg cuando visitas Google.com desde España. Ahora entras a una página con contenido externo que quiere saber si estás en España o no, para ello hace un procedimiento que carga contenido externo, haciendo algo como esto:

Figura 4: Geo-inferencia por carga de imagenes

Si el tiempo de carga es grande, entonces es que ha ido a pedirla a los servidores de Internet, pero si el tiempo es pequeño, entonces es que ya estaba en la caché y por tanto es porque lo había visitado recientemente. Esta técnica se basa en las mismas ideas que los ataques de DNS Caché Snooping, con la gracia de que este caso sería equivalente a leer el valor Country de una cookie.

Figura 5: Carga de resultados de XMLHttpRequest generando error de CORS

Para explorar la ubicación, también se pueden utilizar las políticas de Croos-Origin Request Sharing. Google no permite hacer que otras webs lean resultados de XMLHttpRequests desde otras páginas, el tiempo de obtención del error permite saber si esa respuesta ya estaba en la caché o no, lo que de nuevo, al ser distinta por cada ubicación permite saber en qué sitio estaba.

Figura 6: Diferencias en tiempo de generación de error entre documento en caché o no cacheado

La última de las técnicas consiste en acceder a la lista completa de las propiedades de una imagen y ver la diferencia en el tiempo de carga, para saber si estaba o no en la caché del navegador.

Figura 7: Cálculo de tiempo de carga de propiedades de una imagen

Al final, se trata siempre de intentar acceder a un recurso y ver cuál es la diferencia entre el tiempo de acceso cuando el recurso está y cuando el recurso no está en la caché. Esto aplicado con Craiglitst permite discernir en cuál de las 171 ciudades en que es diferente el sitio se ha estado conectando.

Figura 8: Cálculo de tiempo de iframe cacheado o no de Craiglist

Y lo mismo con Google Maps, que si se accede desde una determinada ubicación, el recurso que se carga deja en la caché un fichero con las coordenadas de la barriada, permitiendo saber tu ubicación.

Figura 9: Cálculo de imágenes de recursos de Google Maps a cargar según ubicación GPS

Según los investigadores, el 62 % de los sitios del TOP 100 de Alexa tienen recursos dependientes de la información Geográfica que pueden ser descubiertos en la caché con estas técnicas y por tanto descubrir tu ubicación. Por supuesto, si borras la caché o usas el modo de navegación incógnito o privado que borra en cada sesión el contenido de la caché, esto es poco útil. Aquí tienes un vídeo de cómo funcionan estas técnicas en una demostración.

Figura 10: Vídeo demostrativo de Geo-inference por caché (visto en hackplayers)

No obstante, para las empresas que se dedican a dar servicios de WebBrowsing Fingerprinting puede ser muy útil, ya que conseguir el scoring de un transacción web en escenarios de Malware-in-the-Browser podría ser útil o para cuando una persona utilice un navegador para comprar con tarjetas fraudulentas o robadas desde ubicaciones extrañas.

Figura 11: Técnicas y navegadores afectados

Las técnicas, como bien indican los investigadores son útiles en los principales navegadores de Internet, incluyendo TorBrowser.

Saludos Malignos!

Google o el garante de la privacidad mundial. ¿Lo sabes?

No sé cuántos estáis al día de los movimientos de Google para implantar SDPY Proxy en el funcionamiento natural de toda la navegación web que venga en HTTP2.0. Como sabéis, aún se está discutiendo el estándar en IETF, y parte de la culpa la tiene la definición de qué y cómo hacer el cifrado de las conexiones HTTP que no están cifradas. Vamos por pasos para desgranarlo.

Figura 1: Google o el garante del privacidad mundial

Hoy en día, la guerra es tan encarnizada, que incluso la Wikipedia ha puesto una alerta sobre la posible No neutralidad de los contenidos y afirmaciones que se pueden ver en la entrada sobre HTTP2, así que lo mejor es que te hagas tu propia opinión.

Figura 2: Alerta de posible No Neutralidad en los contenidos de HTTP/2 en Wikipedia

El principio de esta historia comienza con  HTTP/1 y el funcionamiento de las conexiones HTTP y HTTPs de forma natural. En este esquema tanto, si la conexión va cifrada como si no, va desde el navegador hasta el servidor web.

Figura 3: Esquema de conexión tradicional (sin usar un Proxy HTTP) en HTTP/1

En el caso de que la conexión no vaya cifrada, entonces el contenido del tráfico puede ser visto por cualquiera que acceda a la red WiFi o a cualquiera de las redes por las que pase. Es decisión del servidor web elegir qué datos debe cifrar y cuáles no para generar un equilibrio entre privacidad y optimización, teniendo en cuenta en la parte de optimización la velocidad y el ancho de banda que es especialmente crítico en las conexiones móviles de pago.

Google, de forma individual, comenzó a desplegar SPDY Proxy, un servidor Proxy que, haciendo compresión del tráfico HTTP y cifrando la información, envía todos los datos de las conexiones HTTP sin cifrar a los servidores SPDY Proxy de Google que, después, son enviados sin cifrar por HTTP al servidor web que realmente el usuario estaba conectándose.

Figura 4: Esquema de conexión con SPDY Proxy de Google. Todo el tráfico HTTP es suyo

Es decir, que maximizando públicamente una de las características de un Servidor Proxy - la caché para hacer aceleración de navegación -, y dando una capa de cifrado en la conexión local - como hacen las VPNs -, se hace con el tráfico de los clientes. Esto no tiene que ser malo, si el usuario es consciente y tiene la opción de activarlo él manualmente, es decir, si es un Opt-in.

Quiero recordar en este punto que un Servidor Proxy, o un Servidor VPN trabajan bajo un esquema de Man in The Middle, y que con él se pueden hacer mil cosas, como ya os publiqué en "Owning bad guys {and mafia} using JavaScript Botnets" que se aprovechaba de un esquema de Rogue Proxy para ello.

Figura 5: Conferencia sobre ataques a clientes con un Rogue Proxy

Además, en el estándar HTTP existe desde siempre el concepto de HTTP Proxy Explícito, donde el usuario, al igual que con una conexión VPN, puede elegir de forma libre a qué Servidor Proxy desea conectarse, ya que a él le va a nombrar garante de su privacidad y le va a hacer entrega de la responsabilidad de velar por la seguridad de sus datos. En mi caso personal, yo utilizo solo esquemas de servidores VPN propios montados en Eleven Paths, que es de quién más me fío.

Figura 6: Servidores Proxy como addons de Google Chrome.

Con la llegada de HTTP/2, en los comités se está hablando de implantar un solución de SPDY Proxy como Opt-Out por defecto. Eso significaría que los clientes de navegación, como Google Chrome enviarían todo el tráfico de conexiones HTTP sin cifrar contra un Servidor Proxy que haría como VPN - cifraría la conexión entre el navegador y el servidor web - y de caché. La pregunta es ...¿a qué servidor?. La pregunta es importante, porque alerta cuando instalas uno de forma explícita es suficientemente clara.

Figura 7: Alerta de seguridad en Google Chrome cuando instalas un servidor Proxy

Y aquí llega la guerra, porque por defecto a día de hoy no se puede elegir. Si tu activas SPDY en tu navegador cliente Google Chrome, o si Google lo activa - como puede hacer en breve - sin decirle nada a los usurarios aprovechando su posicionamiento con Android en los terminales móviles y lo convierte en un Opt-out, entonces todo el tráfico HTTP se irá de tu navegador HTTP al SPDY Proxy de Google. 

Y eso es lo que se está peleando. ¿Quién debe ser el garante de la privacidad de los datos de un cliente de Internet? ¿Debe ser Google? ¿Deben dejar los gobiernos que esto pase así después de las filtraciones de Edward Snowden sobre las prácticas de la NSA? ¿Deben nuestros gobiernos en Europa decir algo? ¿Debe ser consciente el usuario de en qué compañía confía y poder elegir a qué servidor HTTP2 PROXY desea conectarse?

Figura 8: Diapositiva de PRISM en la NSA filtrada por Edward Snowden

En mi opinión, lo ideal sería un esquema como el siguiente, donde el usuario pudiera decidir quién debe ser el garante de la privacidad de sus conexiones. Mozilla Firefox y Opera ya han anunciado que no van a poner como Opt-out, sino como Opt-in cualquier implementación de HTTP/2 en conexiones HTTP sin cifrar por medio de un Servidor Proxy, pero Google no tiene esa opinión, y si lo hace aprovechando la cuota de mercado de Android y de Google Chrome en OSX, Windows, Linux e incluso iOS, podría hacerse con casi todo el tráfico mundial HTTP.

Figura 9: Un esquema deseable con elección

Eso significaría que Google se llevaría a sus servidores, sin que muchos usuarios lo sepan, una buena cantidad de datos que a día de hoy no ve, y que de seguro le daría una posición dominante en nuevos servicios, en optimización de sus recursos, en competitividad, etcétera. Eso sí, todo vestido de que su objetivo es "la privacidad del usuario". ¿Tú qué opinas? ¿Deben ser ellos los garantes de la privacidad mundial?

Saludos Malignos!

Técnicas para el Fingerprinting de Web Browsers

Intentar camuflar el navegador que se está utilizando en una conexión web es algo muy habitual. Esto puede hacerse con el objetivo de conseguir ver el sitio web de otra forma - como simular ser un terminal móvil para ver la página web mobile - o para simular ser el navegador de una víctima en un esquema de robo en el mundo del Fraude Online. Utilizar el valor de USER-AGENT para tratar de reconocer el navegador web que utiliza la víctima dejo hace tiempo de ser válido, y por eso se utilizan otras técnicas para reconocerlo.

Figura 1: Web Browser Fingerprinting basado en mensajes de error JavaScript

En el año 2008 Pedro Laguna (@p_laguna) propuso utilizar en Web Browser Fingerprinting un truco basado en generar errores JavaScript en los navegadores para reconocer con ellos la versión del navegador que estaba visitando una determinada página web, lo que dio lugar a WBFingerprinting.

Figura 2: Paper How Unique Is Your Web Browser?

En el año 2010 la EFF publicó el paper How Unique Is Your Web Browser? en el proyecto Panopticlick, donde haciendo enumeración de plugins, idiomas de navegadores, tipos de fuentes disponibles, etcétera, era posible conseguir la huella digital de una conexión para poder hacer tracking de determinados individuos solo analizando su navegador.

Figura 3: Cookieless Monster

Las diferentes técnicas para hacer Web Browser Fingerprinting se explican en un paper publicado este año 2013, donde además se extienden algunas técnicas. El documento, titulado Cookieless Monster: Exploring the Ecosystem of Web-based Device Fingerprinting, explica y compara las técnicas utilizadas en Panopticlick, y por empresas especializadas en la generación de huellas digitales de conexión para el mundo de la publicidad y el fraude, como son Bluecava, Threat Metrix o IOvation.

Figura 4: Comparativa de técnicas de Web Browser Fingerprinting utilizadas en diferentes sitios

El documento explica en detalle algunas técnicas viejas y nuevas para la detección del navegador web. Alguna de ellas bastante curiosa, tales como utilizar como side-channel el ancho que ocupan algunas determinas fuentes dependiendo del navegador que esté utilizando.

Figura 5: Determinar el tamaño de fuentes en navegadores

Una de las que más me ha llamado la atención, especialmente para aquellos preocupados por la seguridad, es ver cómo tener activado Adobe Flash es la gran fuente de información para las empresas que se dedican a hacer fingerprinting, pues pueden llegar a conocer el kernel exacto y la versión del sistema operativo que estás usando, enumerar todas la fuentes instaladas, las zonas horarios, y hasta la dirección IP de verdad de la conexión si estás conectado utilizando un Proxy Anónimo.

Figura 6: Abuso de Flash para descubrir la dirección IP real detrás de un Proxy Anónimo

Si tienes tiempo, no dudes en darle una lectura al paper, que merece la pena ver la de cosas que hacen hoy las empresas de tracking de conexiones digitales.

Más técnicas de WebBrowsing Fingerprinting publicadas

En la DEFCON 21 se presentó el trabajo "Defense by Numb3r5", que utilizaba una técnica distinta basada en detección de navegadores usando el diferente comportamiento de los navegadores ante distintos códigos de estado HTTP.

Además, poco después se popularizó el tuco que mostraba cómo con el uso de las etiquetas eTag se pueden generar cookies sin utilizar cookies, algo que permite seguir a los usuarios que no tengan activado el uso de las cookies.

Por último, hay que destacar que se ha conocido un leak en los protocolos WebRTC que permite acceder a la dirección IP local de la conexión cuando el cliente se conecta con Mozilla Firefox o Google Chrome.

Saludos Malignos!