Owning bad guys & mafia with Javascript botnets (1 de 5)

**************************************************************************************************
- Owning bad guys & mafia with Javascript botnets (1 de 5)
- Owning bad guys & mafia with Javascript botnets (2 de 5)
- Owning bad guys & mafia with Javascript botnets (3 de 5)
- Owning bad guys & mafia with Javascript botnets (4 de 5)
- Owning bad guys & mafia with Javascript botnets (5 de 5)
**************************************************************************************************

Botnets

Construir una botnet es una idea que seguro que ha pasado por la cabeza de muchos de vosotros. La idea de tener un panel de control que te permita manejar el comportamiento de miles de máquinas es siguiente atrayente. Sin embargo, realizar ese proceso es dar un paso definitivamente hacia el lado de cibercrimen que hay que tener mucho cuidado en no dar.

A pesar de eso, la prueba de concepto que os voy a narrar en este artículo tiene que ver con esa idea, la de hacer una botnet, pero con una filosofía totalmente distinta. En primer lugar en nuestra prueba de concepto el trabajo que se realiza es totalmente pasivo, es decir, no hay ningún ánimo de controlar las vidas de nadie, sino de estudiar los riesgos que hoy en día tienen ciertos servicios que se han hecho demasiado populares, como son los Proxys "anónimos" y las redes TOR.

Todo este trabajo pretende alertar de los riegos en los que se puede incurrir por el mero hecho de seguir muchos de los tutoriales que hay en Internet sobre el anonimato, y por tener excesiva confianza en los servicios TOR, que tantas veces hemos utilizado.

Dicho esto, os voy contar el proceso que seguimos para hacer una botnet para controlar lo que hacen y cómo lo hacen los tipos malos de Internet.

El hombre en medio

Antes de comenzar a describir la arquitectura es necesario repasar el concepto de las técnicas de man in the middle, o de "hombre en medio". En el mundo de las redes, los ataques de man in the middle son populares y efectivos. Casos típicos en redes IPv4 con técnicas de arp spoofing o rogue DHCP, en redes IPv6 con los ataques de ICMPv6 Spoofing o SLAAC, o casos como los de DNS Poisoning son más que utilizados en esquemas de robo de credenciales. En todos ellos el hombre en medio es una máquina que se situa entre el cliente y el servidor consiguiendo que el tráfico pase por su máquina.

Este esquema de man in the middle en la red se extendió con el mundo del cibercrimen al man in the browser. Durante mucho tiempo "la escuela rusa" estuvo azotando a los sistemas con Internet Explorer 6 haciendo uso de los famosos Browser Helper Objects (BHO), es decir, componentes ActiveX que, cual barra de herramientas para el navegador, se encargaban de controlar todo lo que pasaba en el browser para cambiar las páginas de entidades financieras y robar las credenciales de acceso.

Este esquema de "negocio" se trasladó, por supuesto, a los dipositivos móviles, donde se hablar del man in the mobile, ya que para poder controlar las transacciones económicas de muchos bancos era necesario robar el SMS de confirmación del banco.

El hombre en el pestaña

Aún más sutiles si caben, son las técnicas de "man in the tab" o "Javascript in the middle" o, de envenenamiento de la caché del navegador. En estos casos el atacante no está dentro de todo el navegador, y su único ámbito de trabajo es el contenido de una pestaña. Es decir, ha conseguido meter un código malicioso en la pestaña del usuario, lo que le permite hacer todas las cosas que se puedan hacer con un código en una página web.

Estos ataques son utilizados habitualmente en esquemas de XSS, en donde el atacante inyecta un código que se ejecuta en la pestaña del navegador, tal y como se contó en el trabajo del año 2008 WebBotnets, la amenaza fantasma. Otra forma habitual es la de ownear servidores web legítimos para meter un código Javascript que se encarga de redirigir al visitante de la web hacia un servidor donde se han desplegado los kits de explotación. Algo muy común en las operaciones de distribución masiva de malware.

Figura 1: Trojan: JS/Redirector.GA

Pero hay incluso malware que su funcionamiento se basa íntegramente en eso, en cachear un fichero Javascript malicioso que se cargue de forma habitual en las pestañas para conseguir sus ejecuciones. Así, malware como Trojan: JS/Redirector.GA se encargaban de meter el fichero Javascript de Google Analytics - ampliamente utilizado en las webs de muchos sitos, como este mismo blog - troyanizado, cargando un payload malicioso desde un servidor controlado.

Y una vez dentro

En un entorno donde se ha infectado un fichero javascript que se carga en la página la cantidad de cosas que se pueden hacer es más que suficiente como para hacer que el atacante se quede contento. En primer lugar, al estar dentro del domino se puede acceder a todas las cookies que no estén tageadas como HTTP Only - e incluso a algunas de ellas si se dan las condiciones para hacer un ataque de TRACE o para realizar un ataque de Error 400 en Apache -, por supuesto se puede hacer un ataque de ClickJacking, un Phishing, o robar los datos que se están teclando en la web, interceptar los formularios, cargar código remotamente, etc...

Para generar ataques en estos entornos hay soluciones avanzadas como por ejemplo BeEF (Browser Explotation Framework) que contiene una buena cantidad de payloads ya creados por si consigues meter el fichero js malicioso.

Figura 2: BeEF Project

Con esta idea inicial en mi cabeza, les propuse a mis estudiantes del Master de Seguridad de la UEM que hicieran un sistema de traceo de personas mediante la inyección de un js malicioso de Google Analytics en un esquema de man in the middle. De ahí salió la demo de JAPI tracing que os publiqué hace ya unos meses.

Cómo hacer una botnet con esta idea

Pasar de un entorno en el que se infecta un fichero Javascript concreto a realizar una botnet funcional con Javascript nos implicaba un poco más de trabajo, pero decidimos que la mejor forma sería si ellos lo hicieran motu proprio, es decir, si no fuera un man in the middle forzado sino seleccionado por ellos mismos, y es por lo que decidimos centrarnos en las redes TOR y los servidores Proxy utilizados en Internet.

Para su realización montamos un equipo, que sería el hombre en medio, y lo dimos de alta como un nodo TOR y como un Servidor Proxy anónimo, y en ambos casos estuvo funcionando durante un tiempo. Sin embargo, hemos de decir que con el nodo TOR sufrimos una detección de actividad maliciosa que hizo  ignoraran nuestra dirección IP.

Figura 3: Log de pruebas DNS en TOR

Como ya os publiqué, los sistemas de seguridad de las redes TOR lanzan tests periódicos y aleatorios en los que realizan pruebas de navegación de las que conocen de antemano las respuestas, y si estas son manipuladas en algún término, pues el nodo pierde confianza y es bloqueado. En nuestro caso "retocamos" la respuesta a ciertos nombres de dominio y dejaron de enviar tráfico por nuestro nodo. Bien por ellos.

Sin embargo, con los servidores Proxy de Internet la cosa fue muy distinta...

Saludos Malignos!

**************************************************************************************************
- Owning bad guys & mafia with Javascript botnets (1 de 5)
- Owning bad guys & mafia with Javascript botnets (2 de 5)
- Owning bad guys & mafia with Javascript botnets (3 de 5)
- Owning bad guys & mafia with Javascript botnets (4 de 5)
- Owning bad guys & mafia with Javascript botnets (5 de 5)
**************************************************************************************************