Safari Leaks: Apple Safari tiene un bug en IndexDB API que se salta Same-Origin Policy y deja tus datos de navegación abiertos a cualquier sitio web

La medida de seguridad de Same-Origin Policy en los sitios web hace que, los datos de un sitio que se almacenan en local en un navegador de Internet solo puedan ser accesibles por Scripts descargados desde URLs que están en el mismo dominio. Es decir, que están en el Same-Origin. Esto permite proteger cookies, información de Referer y datos cacheados en local. 

Figura 1: Apple Safari tiene un bug en IndexDB API que

se salta Same-Origin Policy y deja tus datos de

navegación abiertos a cualquier sitio web

Apple Safari, como todos los navegadores de Internet implementa esta medida de seguridad, que debe ser forzada por el navegador en todos los componentes para garantizar que no hay ninguna forma de acceder a datos que han sido definidos por un sitio web como accesibles solo para "Same-Origin". Esta es una de las principales medidas de seguridad que cualquier atacante debe saltarse en un Client-Side Attack, así que su impacto en la seguridad y privacidad de los usuarios en Internet es muy alta.

Figura 2: Libro de "Hacking Web Applications: Client-Side Attacks"
de Enrique Rando en la editorial 0xWord.

Pero como ha demostrado un investigador, una mala implementación del API de IndexDB en Apple Safari, se puede saber a qué sitios estás navegando en otras pestañas e información extra, como qué usuario de Google es el que has utilizado en local.

Figura 3: Demo en vídeo de Safari Leaks

La demo de Safari Leaks la puedes hacer tu mismo. Vete a la demo en una instancia nueva de Apple Safari y comienza a probarlo. Para ello, deja la pestaña de la demo abierta todo el tiempo.

Figura 4: Demo de Safari Leaks

Después, abre otra pestaña en la misma instancia de Apple Safari, abre la web de Youtube y no inicies sesión con tu usuario de Google.

Figura 5: Abrimos Youtube en otra pestaña

Vuelve a la pestaña de Apple Safari donde tienes abierta la demo y verás que esta pestaña, accediendo a la API de IndexDB local del navegador ya sabe que has navegado por Youtube, pero no sabe qué usuario estás utilizando.

Figura 6: Safari Leaks detecta que has ido a Youtube

Regresa a la pestaña de Youtube e inicia sesión con tu cuenta de Google, para que entres dentro de tu sesión en la plataforma de vídeos. Si vas luego a la pestaña de la demo, verás que no solo ha sido capaz de acceder a qué URL estás navegando sino con qué usuario lo estás haciendo.

Figura 7: Iniciamos sesión en Youtube

Esto permite a sitios que quieran espiar tu navegación para poder perfilarte mejor, saber qué te gusta, dónde tienes cuenta, cuál es tu usuario de Google, etcétera, espiarte desde una pestaña de otro navegador. Así que, cualquier script cargado en cualquier página podría sacar información personal de ti solo por usar Apple Safari. 

Figura 8: URL e ID del usuario de Google que usas

Apple debe arreglar esto lo más rápido que se pueda, así que por el momento, si no quieres que te espíen los datos de navegación, ten mucho cuidado por dónde navegas si lo haces con Apple Safari, porque esto abre infinidad de ataques efectivos de Client-Side. 

Figura 9: Repo de Github de Safari Leaks

Estas políticas de seguridad son mucho más importantes de lo que te imaginas y se usan en muchos rincones, como vimos en los plugins tiempo atrás, así que tómate en serio tener cuidado. Tienes el código de la demo en el repositorio de GitHub.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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 se las verá en los tribunales (varias veces)

Últimamente las noticias de Google sobre problemas legales parece que se acumulan. El famoso Don´t Be Evil ha quedado ya muy lejos y la multinacional continua intentando defender su posición de operador dominante, lo que le está costando muchos problemas con la justicia y le obligará a ir - unas cuantas veces más además de todas las que ya está - a los tribunales.

Figura 1: Google se las verá en los tribunales (varias veces)

Visto esto, parece que para acabar trabajando en Google, en lugar de estudiar una ingeniería en tecnologías de la información, va a haber que seguir optando por el sempiterno Derecho que tantas vidas ha resulto ya a aquellos que lo han estudiado.

Figura 2: Hay más trabajo para Abogados en Google.
(Cómic hecho con StripCreator)

Por espiar a los usuarios de los navegadores y saltarse Do Not Track

Solo para recordar las de esta semana, el Viernes 27 saltaba la noticia de que en el Reino Unido se había aprobado el juicio contra Google por el escándalo del espionaje de las cookies - algo similar a lo que la comisión Europea está organizando para demandar a Facebook -. Ya pagó en una multa de la FTC 22.5 Millones de Dólares y en las denuncias separadas de los usuarios de cada uno de los 38 Estados de USA que ya lo han demandado cerca de 40 Millones de dólares. Ahora tendrá juicio en el Reino Unido según The Guardian, y puede que en otros países de la Unión Europea.

Figura 3: Google a los tribunales por las cookies de espionaje

Por abusar de su posición de "Operador Dominante" en las búsquedas

El día 1 de Abril la noticia fue para la demanda de la Unión Europea va a poner - según Wall Street Journal - a Google por hacer uso de posición de Operador Dominante y manipular los resultados de sus búsquedas. Esto es algo que en Estados Unidos aún se está debatiendo, pero parece que en Europa se acabó el tiempo de los debates, algo que a Google le gusta mucho a tenor de la reunión semanal que tiene con la Casa Blanca - una reunión cada 5 días - para hablar de comisiones y otras cosas que no gustan igual a todos...

Figura 4: Según Wall Street Journal, Europa demandará a Google por abuso de posición de operador dominante

Por no cuidar la privacidad de sus usuarios en Google Wallet

Por último, el 2 de Abril la noticia fue para la denuncia de los usuarios de Google Wallet contra Google en USA por poner sus datos personales a merced de cualquier desarrollador de Google Play, según cuenta Reuters. Esta denuncia le exige un total de 1.000 dólares por cada usuario al que se le accedió a sus datos.

Figura 5: Google demandado por los usuarios de Google Wallet

Vamos a ver en qué acaban estos juicios, pero viendo las cantidades que se barajan en comparación con el dinero que ganan con los datos, no parece que ninguna de ellas vaya a ser disuasoria y ejemplar - salvo tal vez la que lleve la Unión Europea por incidir en los resultados del buscador -. Ya veremos qué pasa a corto.

Saludos Malignos!

Cómo saber si una conexión HTTPS es Insegura (vulnerable a FREAK o Bar Mitvzah)

Tras los últimos ataques al protocolo SSL/TLS, quise saber cómo poder ver, en cada conexión, si la suite de cifrado que se estaba utilizando era o no vulnerable tanto a FREAK como al ataque Bar Mitzvah averiguando qué suite de cifrado se estaba utilizando en cada conexión. Como sabéis, cuando se negocia una conexión SSL/TLS entre un cliente y un servidor, se negocia en el proceso de handshake la suite de cifrado a utilizar durante toda la sesión.

Figura 1: Cómo saber si una conexión HTTPS es Insegura (vulnerable a FREAK o Bar Mitvzah)

Lo habitual es que entre el servidor y el cliente se seleccione, de todas las suite de cifrado que soportan ambos, la más segura de todas, pero un enemigo, haciendo un ataque de man in the middle, podría hacer un ataque de downgrade - o de degradación - para forzar una negociación con una suite de cifrado insegura.

Cómo consultar la suite de cifrado SSL/TLS en Google Chrome

Para ver el suite de cifrado de una conexión - recordad que se negocia conexión a conexión - depende del navegador que estés utilizando. En Google Chrome es bastante sencillo, basta con hacer clic en el protocolo Https y después seleccionar la opción de conexión. En la parte alta del desplegable aparecerán los mensajes de alertas de la conexión Https y en el medio la suite de cifrado que se está utilizando en esta conexión. Dependiendo de la versión del navegador que utilices y contra qué servidor tires la conexión Https, la suite de cifrado puede variar.

Figura 2: Revisión de la Suite de Cifrado SSL/TLS en Google Chrome

Las suites de cifrado vulnerables a FREAK y Bar Mitzvah

Si en la suite de cifrado aparece la cadena EXP es que estás en medio de una conexión que utiliza uno de los algoritmos "válidos" para exportación aprobados por el gobierno de USA porque eran "suficientemente seguros". A día de hoy son totalmente vulnerables y todo servidor y/o cliente que ofrezca la posibilidad de negociar una conexión Https se consideran vulnerables. Estás ante un posible ataque de FREAK.

Figura 3: Demo de FREAK con la web de la NSA

Si en la suite de cifrado aparece la cadena RC4, entonces estás ante una conexión insegura, que puede ser atacada por los problemas de las Invariance Weakness, y por tanto podrían robarte los datos de la sesión. Estás en una sesión vulnerable al ataque de Bar Mitzvah que se presentó hace poco.

Figura 4: Con un ataque de Bar Mitzvah se pueden descifrar los 65 bytes
después del handshake. Si van cookies o passwords [o partes] se descifran

Normalmente, si aparecen esas suite de cifrado en tus conexiones es que estás bajo un ataque de man in the middle que está haciendo downgrade, porque si no normalmente no se negocian esas suites de cifrado, pero está bien que lo compruebes en conexiones muy importantes.

Cómo consultar la suite de cifrado SSL/TLS en Mozilla Firefox

Para saber que suite de cifrado se está utilizando en una conexión Https desde Mozilla Firefox, puedes hacer clic sobre el icono del candado y luego en la opción de More Information - > Security. En la parte final del panel que aparece podrás ver los detalles de la suite de cifrado negociada.

Figura 5: Detalles de la suite de cifrado en una conexión Https desde Mozilla Firefox

También - como han citado en los comentarios de este artículo - se puede usar en Mozilla Firefox el plugin Calomel SSL Validation que muestra un escudo arriba a la izquierda y permite acceder rápidamente a la información de la conexión SSL.

Figura 6: Calomel SSL Validation en https://www.google.es

En otros navegadores como Apple Safari no es tan sencillo, y tendrás que monitorizar con un analizador de tráfico como Wireshark las conexiones Https para ver qué suite de cifrado se ha negociado.

Saludos Malignos!

X-XSS-Protection HTTP Header y los filtros Anti-XSS

Cuando salió el filtro Anti-XSS en Internet Explorer 8 - el primer navegador de Internet que lo aplicó - se generó mucha polémica. El que un filtro del lado del cliente pudiera modificar el contenido que venía mostrado desde el servidor - pese incluso a que pudiera ser mediante un ataque de XSS Reflejado - levantó muchas opiniones a favor y en contra. De hecho, rápidamente los investigadores buscaron formas de saltarse el filtro e, incluso, de utilizar la manipulación del filtro para convertir páginas no vulnerables en páginas vulnerables.

Figura 1: Bugs de XSS Reflejados reportados a Apple

Hoy en día Google Chrome, Apple Safari e Internet Explorer lo implementan por defecto, pero queda en manos del usuario el poder deshabilitarlo en caso de así desearlo, sobre todo por si le da problemas al trabajar con alguna web que, más que probablemente, está mal diseñada. En un ataque de XSS, saltárselo siempre es un paso que hay que hacer, por lo que los bugs de estos filtros de seguridad se hacen también muy populares, como los casos que os he publicado por aquí en algunos artículos:

- El 0day para saltarse el Anti-XSS de Google Chrome que duró 24 horas.
- Unos trucos para pasar el filtro AntiXSS en Chrome y Safari
- Saltándose el filtro Anti XSS de Google Chrome 11

Por otro lado, al mismo tiempo que se da al usuario la posibilidad de controlar el filtro Anti-XSS, los servidores web también tienen un HTTP header que pueden enviar al navegador para habilitar o deshabilitar dicho filtro, en caso de que el usuario haya deshabilitado el filtro y el servidor web no quiera que así sea, o viceversa, es decir, en caso de que el filtro esté habilitado en el cliente y el servidor web desee que se deshabilite. Ese HTTP header es el X-XSS-Protection.

Figura 2: Filtro Anti XSS en Internet Explorer 8 modificando la web

Los HTTP headers que empiezan por X- son variables extendidas que no se encuentran dentro del estándar, pero que se pueden popularizar más o menos dependiendo de quién las utilice. De estos hay muchos, como el famoso X-Frame-Options para evitar ataques de Clickjacking, o como alguna que otra política de contenido que ya os contaré más adelante en algún post. En este caso, el HTTP header X-XSS-Protection se entendido tanto por Google Chrome, Apple Safari como por Internet Explorer desde la versión 8 hasta la actual y permite configurar el filtro Anti-XSS del navegador por medio de esta política.

Figura 3: Google Chrome permite deshabilitar el filtro Anti-XSS,
llamado XSS Auditor, por parámetros en el arranque de la aplicación

Cuando el valor del HTTP Header X-XSS-Protection de una web tiene un valor 1; mode=block, está forzando a que el filtro Anti-XSS esté habilitado en el navegador - incluso si el cliente lo ha deshabilitado -, mientras que si se configura con valor 0 se está deshailitando incluso si el cliente lo tuviera habilitado. Si no se pone el HTTP Header X-XSS-Protection con ningún valor, entonces es elección del cliente habilitar o deshabilitar el filtrado Anti-XSS, aunque por defecto casi todo el mundo lo tiene activo en Google Chrome, Apple Safari e Internet Explorer.

Figura 4: X-XSS-Protection:1 en un servidor de Google

Dicho esto, la recomendación de seguridad es forzar la activación del mismo, consiguiendo una mejor fortificación del entorno, ya que un ataque de XSS puede afectar a la seguridad de los clientes y por tanto a la seguridad del servidor web completo. Sin embargo, puede pasar que, como se ve en este caso de Facebook, temporalmente hayan forzado deshabilitarlo.

Figura 5: X-XSS-Protection 0 en un frontal de Facebook

Hacer esto tiene unos riesgos que se asumen por problemas de compatiblidad, pero que son un mal menor en un proceso de continuidad de negocio. Este HTTP Header de X-XSS-Protection = 0 en Facebook está dejando sin protección Anti-XSS a los clientes de Google Chrome, Apple Safari e Internet Explorer que se conecten a estos frontales, por lo que se deben extremar la protección contra este tipo de ataques dificultándolos con algunas otras medidas, como las Content Security Policies, algo que Facebook sí que utiliza.

Saludos Malignos!

Google Chrome aún no alerta de passwords enviadas en URLs

Hace ya tiempo que, cuando aún andábamos por Informática 64, publiqué un artículo sobre la desprotección que había en ciertos navegadores cuándo se pedía una URL en la que se envían el usuario y la contraseña. Esto es una forma de explotar ataques CSRF que abusen de dispositivos que cuenten con contraseñas por defecto. En aquel entonces os contaba que tanto Microsoft Internet Explorer, como Apple Safari tenían una protección basada en una alerta de seguridad que se muestra al usuario. Esta es la que aparece en Apple Safari. En aquel entonces ni Google Chrome, ni Mozilla Firefox tenían esa protección.

Figura 1: Alerta de envío de passwords en Apple Safari

Ahora, en la lista, como me alertó mi compañero Ricardo, se ha quedado solo Google Chrome, ya que Mozilla Firefox SÍ que ha añadido esta alerta, tal y como se puede ver en la siguiente captura.

Figura 2: Mozilla Firefox ahora alerta del envío de passwords en las URLS

Esta alerta existe en cualquier situación en la que vayan credenciales, incluso cuando se envía el usuario y la password a un sitio que no lo está requiriendo. Se informa de esto para que el usuario tenga la mayor información posible ya que esto puede ser más peligroso aún.

Figura 3: Mozilla Firefox alerta también cuando se envía a sitios que no lo piden

Google Chrome sigue sin alertar de nada, lo que no parece tener mucho sentido desde el punto de vista de seguridad, así que vaya este post para llevar una cuenta de cuánto tarda en añadirlo.

Saludos Malignos! 

Unos trucos para pasar el filtro AntiXSS en Chrome y Safari

Uno de los proyectos estrella de Eleven Paths es el sistema de Pentesting Persistente o Pentesting Continuo que hemos bautizado como Faast. En este servicio el motor en el core se dedica a implementar un análisis extensivo, exhaustivo y continuo dirigido por una base de conocimiento en forma de plugins que van buscando todo tipo de vulnerabilidades de seguridad en un sistema.

Dentro de la elaboración de Faast toca lidiar diariamente con nuevas formas de detectar y explotar las vulnerabilidades, y en uno de esos días nuestro compañero Ioseba Palop, Software Architect de Faast, se topó con una forma de saltarse el filtro Anti-XSS que implementa Webkit, y que por tanto afectaba a los navegadores Google Chrome y Apple Safari.

Desde el Laboratorio de Eleven Paths en Málaga nos pusimos en contacto con el equipo de seguridad ed Google Chrome el 23 de Octubre de 2013 y con el equipo de seguridad Apple Safari para reportarles este issue. Google respondió derivando el fallo al equipo de Chromium que lo arregló a los pocos días, lo que ha hecho que en la última versión de Google Chrome esté ya resuelto.  En el caso de Apple Safari no hay todavía solución, pero nos han contestado que están solucionándolo.

El fallo en el atributo srcdoc

El fallo que descubrió nuestro compañero se basa en hacer un uso incorrecto del atributo srcdoc de la etiqueta IFRAME, incluido en la definición de HTML5. Para realizar un ataque XSS con éxito en el navegador Google Chrome usando este fallo, la web debía incluir un IFRAME y debería ser capaz de leer cualquier atributo de este elemento desde los parámetros de llamada HTTP - por GET o por POST - sin aplicar filtrado de caracteres. El siguiente código de ejemplo es que se envió para demostrar el fallo.

Después, en el parámetro IFRAME, el atributo srcdoc se puede incluir con código JavaScript. Como se puede ver Google Chrome no lo filtra y se ejecutará el código inyectado. Para reproducir la PoC, debería haber una página con un IFRAME similar a éste. 

Figura 1: El iframe que se va a utilizar para ejecutar el código script

Y la inyección HTML en el parámetro src sería la que se ve a continuación:

Figura 2: Forma en la que quedará la inyección

Ahora la víctima podría visitar la siguiente URL y se ejecutaría el código script: 

Figura 3: Inyección y ejecución del código en un Google Chrome vulnerable

En Google Chrome está resuelto ya, pero en Apple Safari se puede comprobar que sigue funcionando este truco y el código se ejecuta en la última versión disponible para las últimas actualizaciones del sistema.

Figura 4: La ejecución en la última versión disponible de Apple Safari

Una reescritura de la etiqueta "script" de apertura

Chromium publicó el bug y la solución, y un investigador con nickname mramydnei se inspiró para desarrollar otra forma de eludir el filtro que todavía no está corregido. El truco es inyectar una etiqueta "script" de apertura que se escriba directamente en la respuesta HTTP  sin filtrar ningún carácter. Bajo esta escritura debe existir contenido dentro de etiquetas scripts que pertenezcan a la propia página.

Figura 5: El código de la web y el código inyectado que se genera

El comportamiento del navegador será incluir nuestra inyección que va sin cierre de etiqueta, obviar la apertura de "script" de la propia web, y  utilizar el cierre de la etiqueta "script" para generar un HTML bien formado. Esto haría que se ejecutara el script inyectado sin ningún tipo de problema, consiguiendo así un bypass de XSSAuditor.

Figura 6: Inyección y resultado de ejecución

El segundo fallo está aún disponible en Google Chrome, y los dos fallos en Apple Safari, así que por ahora se abre la puerta para saltarse el filtro AntiXSS en estos navegadores.

Saludos Malignos!

El virus de la NSA

Largo se ha hablado del infame Virus de la Policía al que La Policía persiguió. Un esquema ransomware que bloquea la computadora exigiendo que se haga un pago de una cantidad de dinero por haber sido el susodicho pillado mientras consumía contenido de ese que se escribe en números romanos.

Figura 1: El virus de La Polícia y su virulencia

Su virulencia fue grande, y tan bien conoce el alma del ser al que persigue, que para dotar de más fuerza y realismo a la denuncia, conseguía inyectar el miedo en el ánima de la víctima activando la webcam y grabando a su presa en vídeo.

Figura 2: El virus de La Policía Rumana grabando en webcam a la víctima

Con el éxito en el mercado del Windows, se migró tímidamente al mercado de los felinos, aunque sólo para secuestrar con timidez a su navegador Apple Safari. También hubo cambio de investigadores, ya que en cada país se ha ido eligiendo al cuerpo que más puede hacer bajar la temperatura en los huesos del atrapado, siendo en USA el FBI.

Figura 3: El virus del FBI secuestrando navegadores Apple Safari en OS X

Pero, después de las revelaciones acaecidas tras las filtraciones del ya conocido como filtrador maestro, la NSA se ha convertido por méritos propios en el que más temor insufla en el espíritu de los internautas, por lo que para maximizar el rendimiento obtenido con tan pícaro truco, el que ahora bloquea los equipos de Internet no es otro que el sistema PRISM, que te ha detectado haciendo cosas malas y quiere ponerte una multa por ello.

Figura 4: El Virus de PRISM

Una vez más, la inventiva malvada de los maestros del Fraude Online busca formas de aprovechar los miedos de la sociedad en beneficio propio, haciendo que el más poderoso de los acicates mueva el dinero de la cartera de una "inocente" víctima a un destino sin duda mucho más lucrativo para las mentes criminales detrás de la argucia.

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!