jueves, julio 21, 2011

Traceando personas al estilo Google con rogue javascipts

Con todo el escándalo del posicionamiento de los usuarios por parte de Apple con iPhonetracker, que llevó hasta cachondeo en South Park, el tema del geoposiconamiento de direcciones MAC de Routers WiFi por Google, que llevó a la polémica de que posicionara también teléfonos móviles personales, o el asunto del seguimiento de personalidades mediante Creepy, me pareció una buena idea el proponerles a uno de mis grupos del Master de Seguridad de la UEM un proyecto de seguimiento de personas mediante código javascript maliciosamente inyectado.

La idea del ataque es conseguir inyectar en el navegador de la víctima un código javascript que se cargue en él, y por lo tanto se ejecute, con mucha asiduidad para poder obtener los datos de la conexión del navegador. Estos datos, lógicamente, no incluyen un posicionamiento GPS, pero si se puede ejecutar un código javascript en el navegador, evidentemente se puede obtener mucha información, como el sistema operativo, la versión del browser, los plugins cargados y la dirección IP de acceso, que puede utilizarse para triangular, en el caso de conseguir una buena cantidad de datos, no solo la posición sino las rutas, como hace Creepy.

El problema radica, en este caso, en elegir un buen javascript que esté siendo cargado muchas veces en muchas páginas web, suplantarlo, y hacer que envíe los datos al servidor de seguimiento, controlado por el atacante. Y esto no es muy complicado, ya que hay algunos javascript que los creadores de páginas web, y bloggers, utilizan masivamente: El script de Google Analytics ga.js.

Este fichero es cargado desde la mayoría de los blogs del mundo, con lo que un usuario que navegue por un abanico medianamente normal de sitios web, acabará pidiendo y metiendo en su navegador, y lo que es mejor, ejecutando este script de Google. Si esta petición puede ser interceptada por un atacante e inyectarle un fichero ga.js, que aparentemente venga desde los servidores de google-analytics, cada vez una página web o blog lo invoque, estará ejecutando el falso fichero javascript y enviando todos los datos a los servidores controlados.

Para conseguir esa inyección es necesario hacer un envenenamiento en el nombre de dominio desde donde se está solicitando ese archivo. Esto se puede conseguir mediante un ataque Man in the Middle que se realice en un entorno vulnerable, como una red WiFi insegura o un lan local.

Como única dificultad queda luchar contra las opciones de caché, ya que es necesario que la perdurabilidad del mismo sea larga, y no se solicite cada vez que alguien invoque el fichero. Para ello, es fundamental que no esté cacheado y sin caducar este fichero en local y luego entregar el rogue js con una fecha de expiración muy larga en el tiempo, de manera que solo cuando se borre manualmente de la caché del navegador se pida su actualización.

Por defecto, el ga.js de Google Analytics tiene unas 2 horas de duración, por lo que es fácil encontrarlo caducado en las máquinas de las víctimas si se acaban de conectar a la red. El único problema para este esquema son aquellos usuarios que configuran su navegador para eliminar todo el contenido cacheado al cerrar la aplicación, ya que eliminaría el rogue js, pero esta no es una opción por defecto, por lo que el porcentaje de usuarios que configuran así el navegador es pequeño.

Una vez inyectado el rogue js de Google-Analitics, ya se podrán recibir datos del usuario cada vez que se conecte a un blog que haga uso de él, como por ejemplo El lado del Mal }:) El proyecto se presentará en Septiembre, pero como ya está funcionando, os publicaré un step by step próximamente.

Este truco no es nuevo, y ya la industria del malware ha estado haciendo uso de este truco y distribuyéndose utilizando trucos como el del uso de servidores DHCP y DNS para infectar en redes locales, como el que contaba Thor en su blog.

Saludos Malignos!

7 comentarios:

3v11 dijo...

Grande Chema!!! :D Saludos desde Bolivia

Thor dijo...

Suena muy interesante.

Gracias por la referencia!

Secret dijo...

haha si es viejo ,amigo

Winston Smith dijo...

En España el secreto de las comunicaciones es un derecho constitucional.
En la comunicación realizada en una red de telecomunicaciones, se debe garantizar al menos cuatro características básicas:

1.- Autenticación
En primer lugar, es necesario garantizar la identidad de los que se comunican en la red. En palabras llanas, que son quienes dicen ser, para que la comunicación sea confiable.
2.- Integridad
Se debe, asimismo, garantizar que la información que se transmite no ha sido alterada y que llega íntegra al receptor tal y como ha sido remitida por el emisor.
3.- Confidencialidad
Es necesario asegurar que la comunicación sea confidencial, es decir, que nadie distinto del emisor y del receptor tienen acceso a la información que se contiene en dicha comunicación.
4.- No repudio
Que las partes que intervienen en una transacción o en una comunicación no puedan negar haberlo hecho.
Atentamente.

Gonzalo dijo...

Una duda chema... se puede hacer que tu equipo sólo reciba paquetes del router en cuestión, configurar de algún modo el equipo para que ignore los equipos de la subred mediante MAC? de este modo, y partiendo de que el router no está comprometido, estaríamos más o menos seguros, no?

Tengo dudas al respecto sobre esta configuración... me recuerda un día que haciendo unas prácticas de redes dejé a todos los de mi casa sin internet, por tener mi equipo con windows server y DHCP y la wifi echada xD

Maligno dijo...

@Gonzalo, yo creo que sí, que se puede hacer.. solo que es spoofeable, pero no habría problema...

Saludos!

dgr dijo...

Artículo muy interesante, aunque mejoraría si se cuidara un poco más la lengua:

Traceando -> Rastreando, siguiendo.
Cacheado -> Guardado/almacenado en caché.
Rogue -> Impostor.

Saludos.

Entradas populares