Demo Shellshock en el ISMS Forum

La semana pasada participé como ponente en el tercer Foro de Ciberseguridad del Spanish Cyber Security Institute, más conocido como ISMS Forum.

En la charla que di presenté un incidente de seguridad en el que estuve trabajando hace un mes para una empresa española que nos pidió colaboración para identificar el problema que habían tenido y recomendaciones a la hora de solucionarlo.

Como me habían pedido que hiciera alguna demostración, pero obviamente no podía dar datos reales, monté un par de entornos vulnerables sobre los que hacer las pruebas.

La primera de las demostraciones que hice fue para mostrar un par de las vulnerabilidad que tenían en la aplicación web que se comprometió. La primera de las vulnerabilidades consistía en la posibilidad de acceder a los datos personales de otros usuarios.

Esta vulnerabilidad es relativamente frecuente en muchas aplicaciones web y web services. Normalmente se debe a que se utiliza un identificador fácilmente predecible para determinar el registro, fichero o recurso en general que se tiene que mostrar. Hay un segundo aspecto que hace que se provoque la vulnerabilidad (además del identificador predecible) y es que no se gestionen correctamente los permisos de cada usuario, ya que la aplicación debería identificar y evitar que un usuario pudiera acceder a recursos que pertenecen a otro usuario.

La segunda vulnerabilidad que se muestra en el primero de los vídeos es una inyección de código SQL muy sencillita de explotar. Lo que iba buscando con esta demostración es demostrar lo fácil que puede llegar a ser explotar este tipo de vulnerabilidades y lo peligroso que resulta en caso de que se esté almacenando información de carácter confidencial en la base de datos (en la demo, se llegaban a mostrar números de tarjetas de crédito, con su CVV y su fecha de caducidad).

La primera demo se puede ver en el siguiente vídeo:

La segunda de las demos que hice fue para mostrar la vulnerabilidad de Shellshock explotada a través de un CGI hospedado en un servidor web.

Aunque esta vulnerabilidad no estaba del todo relacionado con el resto del contenido de mi charla, aproveché que uno de los ponentes anteriores había hablado de la vulnerabilidad largo y tendido pero no había llegado a realizar ninguna demo. Mi intención, por tanto, era hacer ver que algunas de las vulnerabilidades que se leen en Internet sí que son realmente fáciles de explotar sin ningún tipo de recursos especiales.

Ésta es la segunda demo:

Espero que las disfrutéis y podáis utilizarlas si tenéis que presentar este tipo de vulnerabilidades en algún tipo de ambiente.

DVWA - Ejecución de Comandos (I)

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.