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.