Nessus. Report Paranoia.

Recientemente revisando los resultados de salida que Nessus sacaba tras una auditoría de vulnerabilidades a un servidor FTP nos dimos cuenta de lo siguiente:

En principio nada destacable, ninguna vulnerabilidad relevante, pero como siempre, procedemos a una revisión manual de los resultados.

El caso es que si examinamos el banner de salida de este servidor nos muestra lo siguiente:

De hecho, Nessus nos lo saca en su informe de resultados, lo podemos ver con el plugin 10092:

Aparentemente la versión detectada es vulnerable y Nessus no había reportado nada al respecto. Lo primero que se comprobó es que la política que se había aplicado a esa auditoría concreta estaba bien; si todos los plugins de la familia FTP habían sido aplicados, los de detección de servicios, los de la familia General, etc, y todo era correcto.

Lo siguiente que se comprobó fue la versión del SO del server que nos mostraba Nessus:

Bien, quizá empecemos a entender por donde van los tiros, la versión de Debian está actualizada y Nessus parece que entiende por tanto que el paquete del proftpd está actualizado aunque el banner diga otra cosa. Sabemos que muchas distros actualizan sus paquetes pero no el banner de salida (backporting). Pero…, hemos hecho una auditoría en remoto y no he dado permisos a Nessus para que revise los paquetes que tengo instalados en mi servidor FTP ¿da por hecho entonces que tengo un paquete actualizado sólo porque el sistema operativo muestra que está en la última versión?

Se comprueba en el propio servidor que efectivamente tiene el paquete actualizado, así que en principio Nessus no ha errado, el servidor FTP no es vulnerable. Sin embargo, nos planteamos otra cuestión, ¿qué ocurre si tenemos una Debian 6.0 pero le instalamos un proftpd obsoleto, por ejemplo un 1.3.3a? La respuesta es que Nessus de nuevo no nos alerta de ninguna vulnerabilidad.

Indagando un poco en algunos ficheros .nasl que deberían habernos alertado de vulnerabilidades para esa versión concreta de proftpd, por ejemplo si miramos en el proftpd_1_3_3c.nasl, que corresponde al siguiente plugin “ProFTPD < 1.3.3c Multiple Vulnerabilities” vemos en el código las siguiente líneas:

“Note that Nessus did not actually test for the flaws but instead has relied on the 
    version in ProFTPD's banner so this may be a false positive” 

script_require_keys("Settings/ParanoidReport");

# nb: banner checks of open-source software are prone to false-positives 
# so we only run the check if reporting is paranoid.

Es decir, que para evitar falsos positivos este plugin sólo se ejecutará si en nuestra política de Nessus que hemos aplicado para esa auditoría al servidor FTP tenemos seleccionada la opción “Paranoid” en “Report paranoia”:

La opción de “Report paranoia” puede ajustarse a tres valores diferentes: “Paranoid” en la que Nessus ante la duda de si una vulnerabilidad es un falso positivo o no, nos la reportará, “Avoid false alarm”, en la que ante la duda Nessus no te lo reporta, y “Normal” que es la opción que digamos está en medio de los dos extremos anteriores.

Si activamos el modo “Paranoid” (Policies>Add>Preferences>Plugin: Global variable settings) y volvemos a auditar nuestro servidor , la cosa cambia y los resultados son los siguientes:

En este caso, ante la duda, reporta todas las posibles vulnerabilidades.

Hemos comentado directamente estos resultados con el soporte de Nessus, haciendo hincapié en la pregunta de “si tenemos instalado un servidor FTP vulnerable en, por ejemplo, una Debian 6, configurando el modo Report paranoia a Normal…¿Nessus no me alertaría de nada al respecto?” y nos confirman que , “[…]Nessus does not have a plugin that will identify this version of ProFTPD with ‘Report Paranoid’ set to Normal. Because we rely on the banner, and that can be inaccurate, this plugin will only launch if the policy is set to Paranoid […]”

Revisando algunos comentarios en los foros de discusión de esta herramienta encontramos el siguiente en el que, básicamente, Renaud Deraison (uno de los fundadores de Tenable) comenta que debido al backporting si estamos auditando en remoto no es posible identificar si el paquete en cuestión está actualizado o no así que Nessus decide ‘saltarse’ todos los plugins que lo auditen si está en modo “Normal”, ya que da por hecho que el paquete está actualizado si viene de una distro actualizada, y recomienda por tanto activar los plugins(checks) locales -lo que implica pasarle un usuario con permisos del equipo auditado en cuestión al Nessus– (Policy->Add Policy-gt;Credentials) para una mayor precisión en el escaneo de vulnerabilidades.

Lo que me llama la atención es que por defecto Nessus trae la opción “Normal”, con lo cual por un lado nos evitamos muchos falsos positivos que podría traernos la opción “Paranoid” pero sin embargo quizá nos estemos perdiendo demasiada información. Solo hay que hacer una búsqueda de los ficheros *.nasl que no se ejecutan si no tienes la opción “Paranoid” seleccionada.

Lo que también hemos visto es que algunos plugins de la familia General como SMTP, WWW, SSH o FTP alertan de lo siguiente “Security patches are backported” y como te indican en la descripción de esos plugins “Banner-based checks have been disabled to avoid false positives”. Aunque estas alertas no están categorizadas como vulnerabilidades sino como “Información”, al menos nos lo indica para tenerlo en cuenta aunque en nuestro caso concreto, no nos ha saltado tampoco este plugin informativo para nuestro servidor FTP.

Quizá todo esto tenga otra explicación pero me ha parecido curioso esta forma de funcionar debido a lo extendido que está el uso de esta herramienta y por eso quería comentarla, agradecería cualquier aportación al respecto. Seguiré investigando si existe alguna configuración de Nessus para que en modo “Normal” no se dependa del banner detectado.