Desde que me dedico a esto, siempre he estado leyendo en uno y otro sitio cómo hacer diferentes cosas, tipos de ataques, y configuraciones. Salvo contadas ocasiones, en la mayoría de ellos se limitaban a decir cual era el tipo de vulnerabilidad, pero no contaban cómo se explotaba, y en los pocos que contaban cómo hacerlo, montar el laboratorio para ello no era moco de pavo.
Pues bien, hemos decidido hacer algo diferente, aprovechando las muchas fuentes y posibilidades que nos ofrece la red. Combinadas algunas de ellas, nos podemos montar un entorno de pruebas rápido y (no)fiable, sin tener que instalar millones de cosas, que no todos dominamos, ni configuraciones casi imposibles de reproducir.
Hablando con mis colegas, hemos pensado de usar un entorno como el DVWA, que ya lo tiene todo montado. Ir resolviendo las diferentes pruebas en sus diferentes niveles (siempre y cuando ello sea posible), y la parte que consideramos más interesante. Que hacer con ello una vez que la vulnerabilidad sea explotada. Lógicamente no vamos a contemplar el montón de posibilidades que existen, pero si algunas de ellas, y cómo se desarrollaría en la práctica.
Lo primero, descargar el DVWA e instalarlo. Es en modo livecd, así que si tienes un sistema por ahí que tengas tonteando, lo metes, arrancas el livecd y tirando millas. En caso contrario, te lo montas en una máquina virtual y funciona perfectamente igual.
Te lo puedes descargar de aquí: http://www.dvwa.co.uk/DVWA-1.0.7.iso
Empezaremos con la prueba de “Command execution” en el nivel básico. Podéis observar una captura de cómo quedaría una vez arrancado y accedido a la aplicación:
Necesitaremos en la máquina que vamos a emplear para realizar las pruebas un Proxy. Yo he usado Burp proxy, pero podéis usar el que os plazca. Burp proxy lo podéis descargar de aquí: http://portswigger.net/burp/download.html.
He usado éste por su sencillez de uso y de instalación. Sin embargo, hoy día hay otros con distintas posibilidades como el proxyStrike o el ZAP Proxy.
Realicemos la primera petición y analicemos qué es lo que pasa. Para ello tendríamos que emplear una dirección IP tal y como nos piden y ver el resultado obtenido.
Nada nuevo bajo el sol. Le introducimos una dirección IP, le hacemos un ping y devuelve un resultado.
¿Qué pasaría si introdujéramos algo que no fuera una dirección IP? Veámoslo.
Parece que no ocurre nada.
Ahora vamos a contar con el proxy que os comentábamos anteriormente. En la primera captura, en el caso en el cual obteníamos un resultado, el proxy mostraba esto como peticiones:
Es posible observar en el recuadro rojo lo que parece nuestra petición. Una dirección IP, que es la que nosotros introdujimos en su correspondiente recuadro, seguido de otro parámetro.
Probemos ahora a introducir otros parámetros. El resultado obtenido, sería lo que vemos a continuación:
El resultado obtenido parece el previsto. Nada. Si no introducimos una dirección IP a la que realizarle un ping no obtenemos resultado alguno.
Sin embargo, observad el resultado que arroja el proxy (“IP=192.168.0.1+tururu”). Le añade el tururu al final de la dirección IP? Y si le añadiéramos otra cosa tal como haríamos si tuviéramos una línea de comando, una consola?
Observad. ¡Tenemos resultados!. Podemos listar por ejemplo los ficheros y directorios. En la captura del proxy podemos ver que lo que hace es añadir los parámetros uno tras otro.
Aunque todo esto se podría haber realizado sin un proxy, sólo a base de realizar peticiones. Ahora veis la importancia de poder realizar un análisis más pormenorizado de lo que está ocurriendo por debajo, y de poderlo hacer sobre la marcha. Es para esto que usamos habitualmente proxies, con los que podemos observar el tráfico HTTP de lo que estamos haciendo.
No sólo esto, podemos además parar el proceso normal de las peticiones, de forma que podríamos modificarlas con él y enviar lo que necesitáramos en cada momento.
