¿Vulnerable? No… a primera vista

Les voy a contar mi pequeña experiencia con un incidente ocurrido hace unas semanas atrás relacionado con una vulnerabilidad en el FTP del IIS. Ésta afecta tanto a la versión 5.0, 5.1, 6.0 y 7.0, provocando una denegación de servicios [Véase boletín de seguridad de Microsoft], pero es en la versión 5.0 donde la vulnerabilidad es más grave, debido a que hay suficiente espacio como para introducir código. Esto ha dado lugar a dos versiones adicionales del exploit: una permite crear usuarios en el sistemas y la otra la ejecución de una shell remota.

Era finales de agosto cuando comenzaron a llegar noticias de un zero-day en el ftp del IIS. Como todo lo que ocurre con vulnerabilidades de entornos Microsoft, siempre es difícil medir cuánto de toda la información que te llega es verdad. Lo primero es comprobar que realmente no es un bulo y efectivamente, no lo era; demasiadas fuentes apuntaban a este fallo de seguridad grave.

Nos pusimos manos a la obra, y obtuvimos los exploits, los nse del nmap para comprobar la vulnerabilidad, y preparamos una maqueta virtual de un entorno de pruebas que cumpliera todos los requisitos: un servidor FTP del IIS con un usuario con permisos de escritura. Pese a que algunas informaciones apuntaban a que no se requería permisos de escritura, todas las pruebas realizadas apuntan a que se requieren permisos de escritura en el FTP para poder ejecutar dicha vulnerabilidad.

Una vez preparada la maqueta, un Windows 2000 SP4 con el FTP IIS 5.0 habilitado con el usuario anónimo con permisos de escritura, ejecutamos el nse del nmap para comprobar si el sistema lo detectaba como vulnerable y de esta forma poder saber que máquinas eran vulnerables.

Al ejecutarlo nos llevamos el primer chasco: el nse que se ofrecía en las webs de seguridad nos decía que el servidor no era vulnerable. Mirando el código vimos que el nse comprobaba si las respuestas del servidor se correspondían con la firma típica del FTP IIS. Si esto era cierto, se intentaba conectar con usuario anónimo y escribir un directorio en el FTP, tras cuya escritura (y por tanto vulnerable el FTP) eliminaba el directorio creado y notificaba que el servidor es vulnerable. No obstante, en nuestro caso nos indicaba que no lo era:

# nmap -p 21 -sV 192.168.244.129 --script=IIS-FTP --script-trace

Starting Nmap 5.00 ( http://nmap.org ) at 2009-09-01 22:12 CEST
NSOCK (0.3340s) nsock_loop() started (timeout=50ms). 0 events pending
...
NSOCK (5.3400s) nsock_loop() started (timeout=50ms). 0 events pending
NSE: TCP 192.168.244.1:54540 > 192.168.244.129:21 | CLOSE
Interesting ports on 192.168.244.129:
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd 5.0

Mirando y analizando detenidamente paso por paso el código del nse, vemos que la negociación entre el nmap y el servidor FTP no coincide con los mensajes que está devolviendo el servidor FTP al iniciar la conexión. Esta es la razón de que indicase que no era vulnerable cuando realmente cumplía todos los requisitos. Además, hay que tener en cuenta que un servidor que respondiese con una firma modificada por el administrador no cumpliría con los requisitos del script y nos diría que no era vulnerable (de ahí la importancia de modificar la “imagen pública” de un servidor web). Por último, el script estaba preparado para entrar con cuenta anónima con permisos de escritura, pero lógicamente podría tratarse de un FTP con cuentas con permisos de escritura, pero que tuviera la cuenta anónima deshabilitada. Por todo ello el nse ofrecido no era una solución adecuada.

Analizando alternativas, llegamos a la conclusión de que con un simple bucle que usaras las marcas de la firma (-sV) cuya firma fuera “Microsoft ftpd” sería un servidor vulnerable a este fallo de seguridad. Un vez ejecutado y obtenido que servidores eran vulnerables podríamos notificar a los administradores que máquinas tenían el fallo de seguridad y estos comprobaran que usuarios tenían permisos de escritura para revocarlos temporalmente. El script empleado fue el siguiente:

#!/bin/sh 
[ $# -eq 1 ] || { echo "USAGE: $0 RED" && exit 1; } 
for i in `seq 1 254`; 
do 
        RES=`nmap -p 21 -sV $1.$i | grep -i 'Microsoft ftpd' 2> /dev/null` 
        [ "$RES" = "" ] || { echo "$1.$i" >> "vulnerable_FTP.txt"; } 
done

Su ejecución sobre la red virtual de pruebas fue la siguiente:

$ ./miscript.sh 192.168.244
$ cat vulnerable_FTP.txt
192.168.244.129

Una vez tenemos un mecanismo que nos permite detectar los servidores vulnerables, nos dedicamos a analizar cual era el funcionamiento del exploit. Tal como pensábamos, son necesarios permisos de escritura para ir sobrescribiendo la pila hasta tenerla justo donde el atacante quiere, y modificar entonces la dirección de vuelta. Como se ha comentado al principio del artículo existen tres versiones del exploit para el FTP IIS 5.0: una deniega el servicio, otra crea un usuario y la última obtiene una shell.

Así que nos ponemos manos a la obra y cogemos el exploit que permite crear una shell remota. Ejecutamos el exploit sobre nuestra máquina virtual, y en este caso parece que funciona ya que se ejecuta correctamente… pero no. Llega la segunda sorpresa del día: el exploit tampoco en este caso funciona, ni tampoco las otras versiones del exploit. Ni usuario, ni shell ni denegación de servicios… el exploit sencillamente no funciona. ¿Por qué?

Lo veremos mañana, en la siguiente entrada. Permanezcan atentos.