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!

Amenazas en Internet en 2011: 403 Millones de malware

Symantec ha publicado el Internet Security Threat Report 17, con el resumen de lo que ellos han visto relativo a la seguridad informática durante el año 2011. Este informe es muy similar a los Security Intelligence Report que realiza Microsoft, y siempre arrojan datos curiosos. El documento, que puede ser descargado desde este enlacen en su versión resumida [ISTR 17], trae algunos datos que llaman la atención, y otros que son ya bastante conocidos y asumidos.

Por supuesto, en primer lugar hay que recordar lo que ya sabemos y no hay que olvidar, pero que recalcan en el informe como que el spam farmaceutico sigue siendo el campeón, como que el malware sigue creciendo, que los Mac OS X están en la línea de fuego, que los dispositivos móviles son objetivo atacado ya, que en las infraestructuras críticas se han descubierto vulnerabilidades críticas, o que el número de bugs descubiertos, bajó un poco, pero sigue siendo muy alto.

Figura 1: Número de bugs por año

Por supuesto, la industria del malware y el fraude online sigue siendo el gran motor de esta industria, y el número de copias únicas de malware se ha disparado, pasando según el informe de 286 Millones de variantes de malware en 2010 a 403 Millones de copias únicas de malware, lo que no es moco de pavo. Estas copias, casi todas, se distribuyen vía infecciones de sitios web, utilizando kits de explotación, tipo Black Hole - que a día de hoy es el preferido de tu amigo el criminal - y se crean usando herramientas automatizadas, para al final conseguir infectar a las víctimas a través de sitios web infectados.

Curiosamente, los sitios más peligrosos no son los pornográficos, como muchos podrían pensar por una antigua creencia, sino que los blogs y webs personales son lo más vulnerado. Recordad que en los ataques automatizados de sitios web, se pueden llevar por delante hasta webs de renombre, como la de la propia Apple.

Figura 2: Sitios más peligrosos para navegar por ellos

Como reflexión curiosa, y extraída del propio informe: Los sitios religiosos o ideológicos son el triple de peligrosos que los sitios pornográficos, algo que seguro que alguno saca una sonrisa por lo irónico de la metáfora.

Figura 3: Religión, Porno y Malware

Como último punto a destacar del informe, antes de que os pongáis con su lectura, os dejo esta cuenta de vulnerabilidades por navegadores en 2011, en la que se puede ver cuál ha sido el que más fallos de seguridad ha tenido durante el año pasado, y que como queda claro fue: Apple Safari.

Figura 4: Vulnerabilidades en 2010 y 2011

Detrás de Apple Safari quedaron Mozilla Firefox y Google Chrome, dejando a Internet Explorer en la cuarta posición en número de bugs.

Saludos Malignos!

Camuflar un troyano como un vídeo en Apple Safari 5.0.4

Una de las características principales en las que los navegadores tienen que hacer foco es en la protecciones contra las técnicas de ingeniería social. Muchos han sido los trucos utilizados por atacantes para engañar al usuario y hacerle creer que estaba descargando un fichero, viendo una web o haciendo clic en una opción, cuando realmente estaba siendo engañado.

Como tuve algo de tiempo en Buenos Aires, quise probar como andaban las nuevas versiones de los navegadores contra un truco sencillo de ingeniería social. En esta ocasión es Apple Safari 5.0.4, es decir, la última versión publicada, la que cae en un engaño muy tonto a la hora de mostrar el nombre del fichero que le está descargando al usuario.

Supongamos que una web maliciosa decide mostrar un link a un supuesto vídeo de Paris Hilton haciendo sus cosas con sus amigos en uno de sus hoteles. Si el usuario de la web, ávido de conocimiento y ganas de descargar el archivo, hace clic en el fichero para que se descargue, el navegador mostrará el nombre del fichero a descargar y la opción a aplicar una vez descargado, es decir, abrir, ejecutar, guardar, etcétera.

Uno de los trucos más utilizados a lo largo de la historia ha sido el de la doble extensión. El usuario cree que está descargando un archivo .avi, pero realmente es un .avi.exe, es decir. Un fichero ejecutable.

Las últimas versiones de los navegadores de Internet Explorer, Google Chrome, Firefox u Opera, tienen especial cuidado contra este tipo de trucos, así, tienen mucho cuidado de mostrar la extensión del fichero a la hora de enseñarle al usuario el cuadro de diálogo.

Internet Explorer y Google Chrome, separan la extensión y siempre la ponen al final del archivo. En el supuesto caso de que el fichero tenga un nombre muy largo, los navegadores mostrarán la primera parte del nombre del archivo y la extensión. Firefox muestra de la extensión hacia atrás lo que entre y Opera selecciona parte del principio del nombre, y parte del final con la extensión.


Figura 1: Visualización en Opera


Figura 2: Visualización en Internet Explorer 9


Figura 3: Visualización en Google Chrome
Sin embargo, Apple Safari 5.0.4 no hace eso, basta con solicitar la descarga de un fichero con un tamaño fijo de caracterectes, tal y como se ve a continuación, para que la auténtica extensión del fichero quede sustituida por unos sutiles puntos suspensivos.


Figura 4: Troyano con doble extensión simulando ser .avi


Figura 5: Visualización del troyano en Apple Safari 5.0.4
Si el usuario no presta atención a los puntos suspensivos y da al botón de ejecutar, pensando que se le va a reproducir el tan ansiado vídeo, lo que va a obtener, por el contrario, es la ejecución de un troyano. Sencillo, pero funcional y peligroso.

Saludos Malignos!

Don´t touch my porn

He de decir que me saqué la cuenta de twitter sin demasiado convencimiento, pero hoy en día la uso para enterarme de mucha cosas. Y por un twitt de un amigo llegué a este curioso estudio sobre lo qué Internet sabe sobre ti.

El estudio intenta conocer la historia de los navegantes por medio de un algoritmo de fuerza bruta. La idea que subyace se publicó hace mucho tiempo y tiene su origen en que los navegadores muestran en diferente color los links ya visitados. Los creadores de la web, ya sea por medio de Javascript o por CSS pueden, con estas sencillas piezas de código, saber si un link se ha visitado o no.

Si Javascript está activado, se crea primero el estilo para links visitado.


Figura 1: Configuración del estilo
Y después se crea el array de sitios que se quiere saber si han sido visitados o no. Cada uno de esos sitios se convierte en un hipervínculo para, posteriormente, comprobar el color que tiene asociado ese enlace. Si coincide con el color del estilo de link visitado entonces se sabrá que desde ese navegador ha sido visitado ese link.


Figura 2: Scaneo Javascript
Por el contrario, si Javascript está desactivado, basta con crear una imagen de fondo para cada hipervínculo si este se ha visitado en la definición de la plantilla CSS. Cuando se haya visitado el link el navegador solicitará la imagen. Recogiendo las solicitudes es posible conocer las URLs visitadas.


Figura 3: Configuración estilo imagen de fondo en links visitados
Al final el sistema necesita hacerlo por fuerza bruta, es decir, deben darse los links necesarios para comprobarlos desde la aplicación que mira el historial. Esto quiere decir que si alguien ha visitado una URL que no está siendo comprobado, no se podrá saber con este método.

Para hacer el estudio tomaron el top 5.000 de Alexa de los sitios con más tráfico, para ver si podían descubrir los datos de navegación de los usuarios. La pregunta es, ¿Cuántos sitios se pueden comprobar por minuto?


Figura 4: Sitios escaneables por segundo con los dos métodos
El estudio de rendimiento se hizo con Internet Explorer 8.0, Mozilla Firefox 3.6, Safari 4, Chrome 4, y Opera 10.5 en Windows 7 usando un Intel Core 2 Quad Q8200 CPU con 6GB de RAM.

Como se puede ver, en poco tiempo se pueden comprobar muchos links del historial de un navegante aunque, si bien es cierto, es necesario contar con la transmisión de los datos por red.

¿Qué se puede hacer con esto?

Supongo que se os podrán ocurrir mil cosas que hacer con esto, o mil situaciones en las que alguien podría estar interesado en el historial vuestro. Desde sistemas de identificación de potenciales psicópatas que visitan determinadas “webs marcadas”, hasta análisis de mercados o control empresarial del uso de los recursos o saber quién está buscando curro.

En el estudio se hizo una prueba con una base de datos de sitios porno y, de los más de 243.000 visitantes que se probaron, los resultados fueron que el 21 % de los navegantes griegos, el 18 % de los españoles y el 18% de los mexicanos (que son el top 3) tenían sitios “de contenido adulto” en su historial.


Figura 5: Filtros por paises
Si a esto le sumamos los esfuerzos de identificación única de browser como el servicio de https://panopticlick.eff.org/ para identificar y tracear de forma única tú navegador, parece que los filtros de navegación anónima y los servicios de protección de la privacidad deben ser más importantes en nuestra vida.

Si quieren saber mis tendencias políticas, con quién me junto y que porno veo, que esperen a que lo ponga en mi facebook o en mí twitter, ¿qué es esto de mirar mi historial de navegación y quién soy yo?

Saludos Malignos!