lunes, 4 de agosto de 2008

Las auditorías de Nessus + Nmap


Acabo de leer un post en el blog de S21sec titulado “To exploit or not to exploit”, sobre una nueva certificación de InmunitySec. Me ha recordado otro tema del que llevaba tiempo queriendo decir algo, que es algo parecido a lo que se podría llamar “auditorías de Nessus y Nmap”.

Antaño se hacía mucho trabajo farsante (ahora también hay, mala hierba no muere, aunque creo que hay mucho menos), que consistía básicamente en lanzar una o dos herramientas (Nessus + Nmap, Retina, o la que fuera), esperar el tiempo que llevase la ejecución haciendo el vago, hacer un copy-paste de los resultados en el informe, y presentar eso tal cual, en inglés y todo. Y se llamaba a eso “auditoría” (en realidad eso correspondería a un análisis de vulnerabilidades mal hecho, claro, pero tampoco se hacía la distinción). Entonces, metodologías de auditoría como OSSTM estaban mucho menos desarrolladas, y en general, había menos conocimiento del que hay hoy día.

En trabajos más modernos, se añade un apartado para indicar las herramientas que se han utilizado, dando la sensación de que si hay muchas herramientas se ha trabajado mucho o que el equipo que ha hecho el trabajo sabe lo que se hace. ¿Será para que el cliente no crea que se le ha hecho una auditoría farsante?. ¿No está igual de mal utilizar sin ton ni son muchas herramientas, o decir que las has usado para que conste que has usado muchas?. En las ofertas de auditoría, también se añade un listado (largo) de herramientas...

Para mí, el número de herramientas utilizadas no dice absolutamente nada. Las herramientas a utilizar dependerán del alcance del trabajo. Además, usar tal o cual herramienta no garantiza que los resultados sean correctos, pues todas tienen sus falsos positivos.

Veamos un ejemplo: se desea realizar un análisis de vulnerabilidades en una red interna, direccionamiento clase A. Se da a un único técnico auditor una semana (5 días laborables) para hacer el trabajo, y 2 días más para hacer informe (¿a que es poco?). Nessus + Nmap nos da un total de 483 máquinas activas, con 4192 servicios accesibles, y 20091 positivos. Tenemos que distinguir el grano de la paja, así que, siguiendo los mandamientos, deberíamos lanzar más herramientas, a ver si coinciden en resultados con los que ya tenemos… (de hecho, si no recuerdo mal, el OSSTM dice que hay que usar varios escáneres de vulnerabilidades en paralelo, sí o sí). ¿Qué se hace luego? ¿Cotejarlos a mano? ¿Tenemos una manera automática y eficaz de comparar los resultados de Nessus, por ejemplo, con los de Retina?. Porque si no la tenemos, a ver cómo comparamos, en ese tiempo. En cualquier caso, podemos agregar los resultados de dos, tres, o cuatro escáneres a nuestro informe como anexos, pero sin un tratamiento de esa información servirán para hacer bulto, el cliente ni se los va a mirar. (Nota: El ejemplo es extremo, lo se. Se podría cambiar el enfoque, optando por trabajar sobre una muestra representativa de las máquinas y servicios a analizar, previo acuerdo con la organización auditada. Aunque a veces esto no es posible...).

En lugar de eso, será mucho mejor tratar la información obtenida con las pruebas automáticas hechas con nuestro Nessus+Nmap para obtener una valoración de los problemas encontrados y ver cuáles son más graves. Esta valoración deberá ser mejor y más elaborada que la que pueda dar la propia herramienta, y a ser posible, debe estar personalizada en función de la organización objetivo del análisis. También para clasificar los problemas encontrados en categorías, de forma que se sepa mejor a qué se enfrenta uno. Categorías mejor hechas que las que nos pueda presentar la herramienta utilizada. Habrá que ver si hay pruebas no realizadas por ese escaneo inicial que conviene hacer, ver qué falta... Después viene la parte de recopilar evidencias. No se puede señalar al cliente un problema sin una evidencia fuerte.

Para todo eso, a lo mejor no hace falta usar herramientas increíblemente sofisticadas, de las que hay que poner en ese apartado de “herramientas” en el informe. Es posible que los comandos básicos del sistema que uno utiliza, sean suficiente para verificar un problema determinado. ¿Se pone eso en el apartado de “herramientas”?. A lo mejor el personal de la organización auditada nos echa un cable, hemos sacado algo de información preguntando, por ingeniería social (o sea engañando), o la hemos encontrado en la papelera o en los recursos compartidos de alguien… la fuente del hallazgo ha de ponerse en el informe, claro. Pero seguro que de estas fuentes no se indica nada en el apartado “herramientas”.

Al final mejoraremos el informe de análisis de vulnerabilidades ampliando información sobre cada problema, por supuesto en el idioma del cliente. Nada de copy-paste o traducciones literales de fuentes por Internet, que se nota mucho… esta parte también lleva su trabajo. De la labor de consultoría que ha de acompañar al informe de vulnerabilidades, ni hablamos…

Así que después de todo, a lo mejor no hace falta mucho más que un único escáner de vulnerabilidades más complementos ocasionales para recopilar evidencias, para hacer un trabajo de análisis de vulnerabilidades competente. O a lo mejor sí. Hay muchas más cosas que hacer. Sin embargo, me da la sensación de que tanto clientes como compañeros de profesión (pre)juzgan la calidad del trabajo (y del profesional que lo ha realizado) no al leer el informe del mismo, conociendo así cómo se planificó el trabajo (bien o mal) y sus resultados, sino preguntando por las herramientas utilizadas.

Para mí, asumir una baja calidad en el trabajo realizado, antes de leer el informe, porque se haya utilizado sólo un número reducido de herramientas (o peor: porque sean software libre), denota que el que no tiene experiencia o no sabe es el que directamente hace la pregunta "¿Qué herramientas has utilizado?" y si le parecen pocas se permite decir “Uuuuuy”, pensando que tendrá delante una auditoría farsante. Es más, que todos menos él las hacen. Creo que eso es pasarse de listo. Esta es mi queja y el motivo de este post.

La labor principal es la búsqueda y documentación de vulnerabilidades, no es imprescindible entrar “hasta la cocina” o lanzar obligatoriamente muchas herramientas de análisis de vulnerabilidades. Con presentar evidencia suficiente ya vale, y cuanto más sencilla sea la manera de recopilarla, mucho mejor. Pero, eso sí, es un trabajo que requiere su tiempo...

¿Estoy diciendo una perogrullada? ¿O es bueno recordar esto?.

Slds!

P.D: Ante la cuestión planteada en el post que indico al principio de esta entrada en el blog, es decir, si un buen auditor necesita saber crear un exploit para una determinada vulnerabilidad y ejecutar así código en una máquina remota para realizar una buena auditoría, mi opinión es que no necesariamente. En el plazo previsto para hacer una auditoría puede que no de tiempo, para empezar (de hecho, seguro que no da). Y es probable que con herramientas sencillas más una pequeña colección de exploits (metasploit, por ejemplo) sea suficiente para recopilar la información que complete la obtenida con el escáner de vulnerabilidades, durante la realización de una auditoría.

5 comentarios:

GigA dijo...

Uff Des, ¡la que has soltado! Creo que es tu post más largo con diferencia :D

Bueno, yendo al caso, un buen Auditor nunca dice cuantas herramientas usa, ni cuales, yo creía que esto era de 1º de Auditoria, de hecho nunca me he encontrado con informes que digan lo contrario, y de lo de no traducir los resultados a Castellano u otros, pues N/C.

Curiosamente mi proyecto de final de carrera estaba centrado en la Auditoría de Sistemas, en especial hablé de OSSTMM y algo de OWASP, de eso hace ya 2 años pero no recuerdo que OSSTMM pidiera varios escaners en paralelo, otra cosa es que auditemos servidores, workstations, etc. con Nessus, y otra distinta es que auditemos una aplicación web, con un escáner específico de estas aplicaciones. No se si es esto a lo que te referias, pero desde luego una buena auditoría OSSTMM abarca eso y muchísimas cosas más, una de las que a mí más me gusta es ... "Presencia en Internet" Quizás algún dia rescate un post de esto :D

des dijo...

Hola GigA! No puedo enseñarte informes, obviamente... pero lo mismo que los he encontrado yo, seguro que tú también lo harás. Tiempo al tiempo... Yo estoy de acuerdo con que no se debería presentar un listado explícito, con su propio apartado y todo...

La versión 2.2 del OSSTMM (tengo la versión inglesa) dice en el apartado "Vulnerability Research and verification" (página 56): "Perform redundant testing with with at least 2 automated vulnerability scanners".

Muchas gracias por leerte un post así de largo :) ¡La verdad es que he soltado casi un libro!

Lobosoft dijo...

Jajajaja, la verdad es que sí que es largo el post, pero no mengua su interés por ello sino todo lo contrario. Es cierto que en el mundo de la consultoría las auditorías (sean estas de seguridad o de cualquier otro tipo) parecen mejores cuantas más páginas se rellenen, sea cual sea la forma de conseguirlo. De poco sirve contar con una gama amplia de herramientas si no se saben usar, o no se utilizan adecuadamente y, como indicas, esto ocurre más a menudo de lo que sería deseable. Ante esto, no nos queda más que hacer bien nuestro trabajo, y no confiar o desconfiar a priori del de los demás por lo voluminoso de sus resultados, sino más bien por lo concienzudo del trabajo necesario para llegar a obtenerlos.

¡Un saludo!

Sebastián dijo...

¡Muy buen post!

Yo creo que hay dos puntos importantes.

El primero tiene que ver con la calidad profesional. Puedo usar una o diez herramientas pero la forma en que presente el informe o el resultado, la forma en que lo procese o lo analice ya están haciendo diferencia.

Por otro lado; desde el punto de vista de la seguridad. Es importante definir las diferencias entre (por lo menos) diagnóstico de vulnerabilidades, test de penetración y auditoría. Es decir, no podemos vender un análisis con Nessus como una auditoría, porque es una farsa. La honestidad y seriedad son parte importante de un profesional.

Saludos.

Alex dijo...

Buena apreciación. Desde luego que lo comentas sigue existiendo, la ingenuidad es un factor muy importante en estos temas.

El lema del que hace la auditoría empleando métodos automatizados y utilizando los resultados para emitir un informe, con un simple copia-pega, es: "A por la pasta".

Una pena, pero una realidad.