Vulscan 1.0

Recientemente Marc Ruef @mruef (Computec.ch), ha presentado una nueva release mejorada de Vulscan, un script para Nmap que ya presentó en 2010 con funcionalidades básicas de escáner de vulnerabilidades.

Vulscan basándose en la opción -sV de Nmap que nos muestra las versiones de los servicios detectados e interactuando offline con diversas bases de datos de vulnerabilidades es capaz de alertarnos si alguno de estos servicios es potencialmente vulnerable a alguna vulnerabilidad documentada en alguna de esas bases de datos.

Las bases de datos preinstaladas que trae son las siguientes:

Así pues, un ejemplo básico de funcionamiento de este script sería el siguiente. Tras añadir la carpeta Vulscan al directorio scripts donde tengamos nuestro directorio de instalación de Nmap (para las pruebas he utilizado owaspbwa que de antemano sé que ofrece servicios vulnerables en el puerto 22 y el 80, entre otros):

Si no especificamos nada interactuará con todas las bases de datos preinstaladas, sin embargo si queremos que por ejemplo solo cruce datos con una única base de datos añadiremos la opción vulscandb:

--script-args "vulscandb=basedatos.csv"

especificando la base de datos que queramos o incluso una nuestra que podemos crearnos sencillamente con el formato:

<id>;<title>

Una de las mejoras incorporadas es el soporte de plantillas de informes dinámicos a través de la opción vulscanoutput por la que puedes crearte tu propia estructura del informe a través del siguiente formato:

--script-args "vulscanoutput='{id} - Title: {title} ({matches})\n'"

donde:

Un caso práctico de este script sería por ejemplo en un escenario en el que estemos realizando una auditoría Web, en el que combinando éste y otros scripts NSE para Web Scanning de los muchos que incorporó Nmap en su última actualización más importante hace un año, nos conforme de manera muy rápida un primer informe preliminar sobre posibles deficiencias encontradas en dicha Web como por ejemplo determinando el título de la página por defecto del servidor Web detectado durante el escaneo (http-title), mostrando los directorios más utilizados por servidores o aplicaciones Web (http-enum), recopilando las direcciones de correo encontradas durante el escaneo (http-email-harvest) y encontrando las vulnerabilidades conocidas acorde a la versión del servicio Web detectado utilizando el mencionado vulscan:

nmap -sV --script=http-title,http-enum,http-email-harvest,vulscan -p80 172.16.94.128

El informe a la salida sería similar al siguiente:

Nótese que, por temas de espacio, he manipulado el informe de salida para no mostrar la salida completa de vulscan y sólo aparecen algunas de las vulnerabilidades encontradas y no todas.

Comentar por último que hay que tener en cuenta que este tipo de análisis de vulnerabilidades depende en gran medida de la capacidad de Nmap de obtener la versión del servicio detectado, de la cantidad de vulnerabilidades documentadas en las bases de datos y de la exactitud en la coincidencia de patrones al hacer el cruce de datos.

Personalmente he detectado que vulscan solo coge las versiones de salida de la opción de nmap -sV y con ellas interactúa, sin embargo echo en falta , que coja las salidas de otros scripts nse como por ejemplo html-cms.nse , que detecta la versión de CMS escaneada, y sería muy útil utilizar estos dos scripts, de forma que un script nos detecte la versión de CMS concreta y el otro las posibles vulnerabilidades que pueden ser encontradas para esa determinada versión. He hablado con @mruef y me ha comentado que el problema es que no puede acceder a datos de otros scripts a no ser que los proporcionen de alguna forma como por ejemplo en un fichero de salida. La mejor solución sería, que los otros scripts nse pongan sus datos de identificación a la salida en el Registry (véase la API de Nmap).

Según la API de Nmap los scripts pueden compartir información almacenando valores en un registro, que es una tabla especial a la que pueden acceder todos los scripts. Hay un registro global, nmap.registry, compartido por todos los scripts, cuya información persiste durante todo un escaneo completo de Nmap, de forma que los scripts puedan usarlo por ejemplo para almacenar valores que posteriormente , de manera secuencial, puedan ser utilizados por otro script contra la misma máquina dentro del mismo escaneo, de forma que la salida de uno retroalimente al otro.

Marc Ruef ya está trabajando en una nueva release en la que incluirá nuevas mejoras y funcionalidades como por ejemplo que vulscan 2.0 soportará Exploit-DB e IBM X-Force.

Referencias aquí.