El lado humano y social de un Pen-Test

A estas alturas, ya se han escrito ríos de tinta sobre cómo hacer un test de intrusión, con metodologías muy completas, como pueda ser ésta. Sin embargo, hay mucha menos información sobre cómo se hace un test de intrusión con una empresa, el contrato previo, la presentación de resultados ...

1. PREVIOS.

Antes de empezar, debe quedar muy claro cual es el alcance del test de intrusión: qué se va a mirar (intranet, web, puestos de trabajo, ...), cuántas horas se van a invertir y cuántas personas van a ir, si va a ser caja blanca o caja negra, ... No debe quedar ningún tipo de ambigüedad al respecto, ya que podría ser un problema más adelante por haber incumplido los objetivos.

Debemos tener una reunión previa con los responsables de sistemas para especificar cada uno de los puntos anteriores, de la que saldrá un contrato previo que deberá ser firmado antes de hacer nada.

2. Durante la Auditoria

Si estamos auditando la web desde nuestra empresa, deberemos tener cuidado con no realizar ninguna denegación de servicio pero, aparte de esto, los procedimientos a seguir son los esperados.

Sin embargo, desde dentro todo cambia. Hay que tener mucho cuidado con qué herramientas usamos, por ejemplo cain&abel puede causar una denegación de servicio, cosa que por lo visto nadie parece decir ... Debemos informar siempre de los pasos que seguimos y no ocultar cosas, sobre todo cuando toquemos algo delicado. Si durante el tiempo que estamos allí pasa algo, por ejemplo una caída de un servidor, inevitablemente todos los ojos se tornarán hacia nosotros.

Otra cosa muy importante es ... y da un poco de vergüenza decirlo ... tomar café con los admins. Hablando con ellos te puedes hacer una idea de su nivel de conocimiento y, sabiendo eso, puedes más o menos hacerte una idea de qué esperar de la seguridad de la red. Puedes encontrarte cualquier cosa: desde el típico admin que piensa que estás allí para fastidiarle y dificultar su trabajo hasta alguien que haya trabajado como auditor de seguridad.

3.. PRESENTACIÓN DE RESULTADOS.

Al final de la auditoría, deberemos hacer una presentación de los resultados a los responsables de la seguridad en la empresa. Dicha presentación debe incluir la lista de cosas encontradas, ordenadas según criticidad, con pantallazos que demuestren que nuestras conclusiones son reales (si no, nos pueden decir que eso no es así, y nos ponemos a discutir una batalla perdida). Además, para cada problema encontrado debemos aportar una forma de solucionarlo, acorde con el funcionamiento de la empresa.


Además, deberíamos presentar otro informe a dirección, pero este no debe ser técnico, sino funcional, resumiendo los resultados encontrados y haciendo hincapié en cómo abordar las mejoras. No debemos olvidar que esto va a acabar en manos de alguien de perfil no técnico, y no quiere ni oir hablar de un SYN-FLOOD.

Por poner algunos ejemplos, veamos unas cuantas cosas que podríamos presentar en nuestros resultados, cómo hacerlo, y su impacto real según lo presentemos:

- hay un servidor FTP en la intranet que corre una versión vulnerable: irrelevante. Esto es perféctamente normal en la intranet y no nos van a hacer ni caso. Es absolutamente insignificante.

- las VLANs están mal diseñadas y podemos conectarnos remotamente a cualquier PC: esto está mejor, pero la forma de presentar el resultado es realmente floja (ver la siguiente).

- las VLANs están mal diseñadas, permitiendo instalar un troyano en administración y robar datos confidenciales de la empresa: ahora sí!! Esto impacta mucho más y se cuidarán muy mucho de hacer los cambios pertinentes. Y si viene acompañado de un pantallazo de un documento confidencial robado anexado al informe ya es la leche.

Como vemos, no consiste en coger el report de nessus y leerlo en una reunión. Se trata de saber de qué estamos hablando y realmente qué tiene impacto y qué no lo tiene. Nuestro trabajo no consiste en decir que vsftpd 2.0.0.1 es vulnerable a un ataque DOS, sino en ayudar a los administradores a hacer los cambios pertinentes para asegurar la red.

Y, entonces, ¿qué tipo de fallos de seguridad buscamos? La respuesta a esta pregunta es crucial: debemos buscar fallos "lógicos" y no exploits. Debemos buscar accesos a datos confidenciales desde usuarios sin privilegios, robo de información confidencial, falta de actualización de los antivirus, ... Cosas como "puede hacerse una transferencia de zona desde la intranet" están muy bien, pero realmente lo que importa si queremos ayudarles a mejorar la seguridad, y QUEREMOS AYUDARLES, son fallos más de tipo "filosófico", que son los que realmente marcan la diferencia.

También debemos distinguir dos casos: auditoría externa e interna. En una auditoría externa SÍ tiene sentido decir que existe un exploit para su servidor FTP. Es relevante y debe actualizarse. Pero incluso en este caso, un fallo de diseño lógico en la web que permita acceder a información confidencial es mucho más grave.

Los admins saben que si alguien les lee referencias de CVE o security-focus, en realidad, significa que no ha sido capaz de hacer mucho más.

4. PREGUNTAR, PREGUNTAR, PREGUNTAR, ...

Al igual que en una auditoría externa el primer paso es recolectar información, en una auditoría interna sucede lo mismo. Y, ¿cuál es la mejor forma? Muy fácil: preguntando. La gente que trabaja allí, en particular los admins, ya saben cómo está organizado todo.

Si es caja blanca, deberemos sacar toda la información posible, entrevistando a los responsables de las principales aplicaciones de la empresa (web, bases de datos, administradores) ... De aquí podemos sacar información muy valiosa que más adelante nos servirá para realizar un test de intrusión mucho más preciso. Cuanto más sepamos de cómo funciona la empresa, mejor será nuestro pen-testing. Además, hay cierta documentación a la que deberemos acceder, y lo primero de todo es un mapa de red, sistemas operativos, servicios, ...

Si es caja negra, también podemos preguntar. Podemos decirle al que tenemos al lado que cómo acceden a las bases de datos, qué aplicaciones usan, que nos explique un poco todo ... Al fin y al cabo, si trabajásemos allí también podríamos preguntarles. Lo que no podemos hacer es ir al responsable de sistemas y pedirle un mapa de red.

Entender cómo trabajan nos ayudará, indudablemente, a hacer una auditoría mucho mejor y no presentar resultados irrelevantes.

5. PUNTOS A TENER EN CUENTA DURANTE LA PRESENTACIÓN.

Algunos consejos:

- Deben guardarse evidencias de todo.
- Las evidencias deben anexarse en la presentación.
- Antes de llevar el informe a dirección, hay que hablar con los admins. Es posible que haya que hacer alguna modificación. Ante todo, debemos recordar que estamos allí para AYUDARLES a mejorar su seguridad, y no para presumir de que sabemos mucho de TCP/IP.
- Hay que clasificar todo lo encontrado según criticidad, poniendo en primer lugar las cosas más graves y luego las menos importantes.
- Los admins no son idiotas: si pones en el informe que se puede sacar el uptime de un servidor saben que lo quiere decir es que no has sido capaz de encontrar nada.
- La imagen es muy importante: eres un auditor de seguridad, y NO un freaky.
- Nada de denegaciones de servicio o lanzar exploits contra servidores de producción o que sean importantes (pueden demandarnos).
- La forma de hablar debe ser adecuada a la audiencia: si hablamos con alguien técnico hablaremos de reglas del firewall, VLANs, ... Si hablamos con alguien con un perfil no técnico, hablaremos de acceso a datos confidenciales, robo de información, acceso no autorizado desde el exterior, ...
- Si hemos encontrado cosas serias, podemos no mencionar las más irrelevantes. No les hagamos perder el tiempo.

6. MUCHO CUIDADO CON CRITICAR.

Normalmente, los administradores son un poco suspicaces con los auditores. Tambień es parte de nuestro trabajo ganarnos su confianza y que vean que no vamos allí para sacarles defectos, para decirles que todo está mal y para que luego su jefe los ponga a caldo. Nunca debemos criticar el trabajo de los demás, puesto que en su lugar nosotros casi seguro que habríamos hecho lo mismo. Frases como "esto es un chapuza" y similares lo único que hacen es ponerlos en nuestra contra, mejor un "esto sería todavía mejor". Gánate su confianza y te ayudarán y, si te ayudan, todo irá mucho mejor.

7. REVISIÓN DE CAMBIOS.

Al igual que es importante presentar un informe con toda la lista de vulnerabilidades encontradas, lo es también hacer una auditoría posterior para comprobar que todas las mejoras propuestas han sido realizadas. Presentar informes no sirve de nada si luego no se toman las medidas adecuadas.

Es parte de nuestra responsabilidad sugerir una auditoría posterior, así como la lista de cosas que se van a revisar que, por supuesto, incluirán aquellos clasificados como críticos. Y no debemos olvidar nunca que los administradores de la red tienen cosas más importantes que hacer que lo que nosotros les digamos. Los plazos de tiempo deben ser realistas. Además, los cambios que propongamos para mejorar la seguridad de la red tienen que ser REALISTAS.

No podemos decir a una empresa que tiene todo servidores windows que instale djbdns: es una idiotez. Debemos tener muy en cuenta cómo trabajan y tratar de que nuestros consejos se adecuen lo máximo posible. Y, para esto, nada mejor que escuchar.

Recuerden no queremos presumir solo queremos ayudar...

Saludos
Dr.White

Fuente: Hacking-Avanzado