¿Cómo crear un informe de pentesting?

Es una pregunta muy habitual entre profesionales que están empezando a trabajar en pentesting y aunque hay plantillas que se pueden encontrar fácilmente en internet y algunas herramientas los generan automáticamente, como profesional sigo ciertas normas a la hora de elaborar los documentos que debo entregar a los clientes tras finalizar los trabajos. En este post y en el siguiente hablaré sobre este tipo de detalles que es posible que te sean útiles.

0. Nociones básicas

La elaboración de informes es una de las cuestiones más importantes en cualquier auditoría y en ellos se debe reflejar de forma clara y concisa los descubrimientos y conclusiones a las que has llegado. Cualquier informe normalmente debe incluir como mínimo lo siguiente:

• Portada
• Índice
• Control de versiones
• Disclaimer y confidencialidad de la información
• Personas involucradas
• Metodologías utilizadas.
• Contexto de la auditoría y nociones generales.
• Pruebas realizadas, descubrimientos y pruebas de concepto.
• Conclusiones y recomendaciones.
• Anexos (pruebas detalladas, scripts, referencias en internet. etc).

La portada del documento suele ser genérica e incluye entre otras cosas, información sobre la empresa, fecha en la que se entrega el documento y detalles básicos.
En el índice es común incluir enlaces o accesos directos para que sea fácil moverse por las diferentes secciones del documento.
El control de versiones debe incluir como mínimo, una descripción de los cambios introducidos en cada modificación del documento con una fecha y autor.
En la introducción y contexto del documento, se describen detalles sobre la auditoría a realizar y su alcance, algo que evidentemente también se debe de encontrar reflejado en el acuerdo firmado con el cliente. Esta parte del documento pretende informar al lector sobre cuáles son las pruebas que se han realizado sin entrar en demasiados detalles, a modo de resumen ejecutivo.
Otro detalle importante que es necesario tener en cuenta en cualquier informe, es la sección correspondiente a las metodologías utilizadas, las cuales en todo caso dependerán de la auditoría a realizar. Es altamente recomendable implementar metodologías que ya han sido depuradas y tengan una buena aceptación por parte de la industria. Por ejemplo, algunas metodologías interesantes se listan a continuación, aunque evidentemente aplican en función del tipo de auditoría realizada:

• Penetration Testing Execution Standard (PTES)
• PCI (Payment Card Industry) Penetration testing guide
• Open Source Security Testing Methodology Manual (OSSTMM)
• OWASP Top 10
• OWASP Testing Guide
• OWASP Mobile Top 10
• OWASP API Top 10

El contenido propiamente dicho del documento debe de incluir las pruebas que se han realizado, explicando cada una de las etapas de la auditoría, herramientas y técnicas utilizadas, así como los resultados de cada una. Se trata de una sección en donde es importante incluir los detalles de la forma más clara y concisa, evitando redundancias y bloques de código o salidas de log demasiado extensas con el fin de favorecer la legibilidad del documento. En el caso de que sea necesario incluir dichos elementos, sería recomendable abordarlos en anexos independientes para que el lector los pueda revisar por separado. En este punto, probablemente lo más importante es que la información aporte valor. Es decir, no sirve de nada incluir cada una de las pruebas de concepto que se han ejecutado si no han producido los resultados esperados. Solo se debe incluir información relevante y de interés para el objeto de la auditoría. De nada sirve dedicar 2 o 3 páginas del informe explicando que se ha lanzado un exploit para el Apache (por poner un ejemplo) si dicho exploit no ha funcionado debido a que probablemente el servicio no es vulnerable. Incluye sólo información que aporte valor.

Finalmente, en la sección de recomendaciones viene bien incluir algunos puntos a tener en cuenta para mejorar la seguridad del sistema auditado, aunque también se pueden resaltar aquellas configuraciones y/o buenas practicas que se están llevando a cabo con el fin de que el cliente siga haciendo uso de ellas y alentar a su mantenimiento. Si se encuentran vulnerabilidades es muy importante incluir contramedidas o recomendaciones que sean útiles para mitigarlas o mecanismos de protección que ayuden a solucionar los problemas detectados. Ojo, el hecho de incluir esas contramedidas no es vinculante y no significa que seas tu quien las va a implementar. Te han contratado para ejecutar una auditoría y detectar problemas, implementar las soluciones es algo que debe valorar el cliente.

1. ¿Qué tipo de auditoría te han pedido?.

Se pueden crear diferentes tipos de informes dependiendo de las necesidades del cliente, las cuales han tenido que quedar reflejadas en el acuerdo. Es posible que la auditoría a realizar se centre en uno de los siguientes escenarios:

• Pentesting perimetral/externo.
• Pentesting interno.
• Pentesting wireless

Dependiendo de cada caso hay que tener en cuenta factores adicionales que deben quedar reflejados en el documento, por ejemplo cuando un cliente pide un enfoque mixto y una parte de la auditoría será externa y otra parte interna.

2. Piensa en la persona que va a leer tu informe y trata de adaptarte.

Con todo lo anterior claro, lo primero que hay que tener en cuenta es que no todos los clientes son iguales y en algunos casos es necesario desarrollar 2 o más informes que reflejen las tareas realizadas. Es importante adaptarse y entender el público objetivo. Es decir, si la persona que va a leer el informe es personal técnico le interesará que esté orientado a describir las vulnerabilidades, defectos y recomendaciones que aporta el documento. En este caso será revisado por una persona que como mínimo, tiene unos conocimientos básicos y entenderá lo que cuentas pero si por ejemplo, ese mismo documento lo lee un directivo, responsable de área o personal no técnico, evidentemente lo más probable es que entienda poco o nada. Imagina por un instante que un experto en finanzas (por poner un ejemplo) te pasa un informe técnico de una auditoría financiera, crees que tendrás el criterio suficiente para decir si eso que te han enviado está “bien” o “mal”? probablemente pasarás de leerlo y se lo enviarás a alguien que sea experto en el tema. Dependiendo del alcance y lo que se haya hablado con el cliente es probable que tengas que elaborar un informe orientado al personal técnico y otro a “decision makers” o directivos/responsables, en cada caso el lenguaje que utilizas y el mensaje que transmites debe ser lo suficientemente claro para el lector objetivo.

3. Las plantillas o herramientas no hacen un buen informe.

Puedes usar plantillas disponibles en Internet o las que a lo mejor se encuentran disponibles en la empresa en la que trabajas, por supuesto que es algo perfectamente valido pero no deja de ser una base que te ayuda a ahorrar tiempo en definir un diseño y “maquetar” secciones. Puedes (y debes) adaptar la plantilla a la auditoría que estás realizando, no es algo estático que debes seguir a rajatabla. Si te hace falta añadir, quitar o mover secciones lo haces y ya está. Que la plantilla que utilices no se convierta en un problema, se ha creado precisamente para que puedas hacer el trabajo más rápido.

En el post anterior que puedes leer aquí: ¿Cómo crear un informe de pentesting? Parte 1 de 2 comentaba algunas nociones básicas sobre la redacción de informes. En esta ocasión explicaré con un poco más de detalle en base a mi experiencia, qué otras cuestiones se deben tener en consideración para crear un informe profesional. Si quieres comentar algo que a lo mejor no he tenido en cuenta en estos artículos, por favor deja un comentario ya que estoy seguro que nos será útil a todos.

1. No dejes la redacción del informe para el último momento.

Nos ha pasado a todos. Cuando estamos inmersos en una auditoría tendemos a dedicar demasiado tiempo en ejecutar pruebas y analizar el objetivo. El problema de este enfoque es que si no tienes una gestión óptima del tiempo que dedicas a cada tarea, al final te encuentras con que debes redactar un informe en pocos días o en el peor de los casos, horas. Es bueno ir documentando las cosas que se van encontrando y hacerlo con cuidado. Como comentaba en el post anterior, incluye información que aporte y no “paja” para hacer un informe extenso.

2. Si es posible, pídele a un compañero o persona de confianza que lo lea antes de entregarlo.

Redactar no es fácil. Requiere práctica, dedicación, paciencia y acostumbrarse a hacerlo con frecuencia. Es posible que lo que escribes en tu cabeza “compila” pero luego cuando alguien más lo lee te das cuenta que a lo mejor no es tan claro el mensaje que intentas transmitir. Definir un estilo de redacción es una habilidad que cualquier persona dedicada al pentesting debe adquirir. No parece muy divertido comparado con detectar vulnerabilidades, ejecutar exploits o romper mecanismos de autenticación pero si a la hora de plasmar tu trabajo en un informe no lo haces bien porque no estás acostumbrado o lo que has escrito solo lo entiendes tu, el valor de ese informe será prácticamente nulo.
Por este motivo, es una buena idea que alguien más pueda apoyarte leyendo lo que escribes y de esa manera tener una segunda opinión, detectar errores o frases que posiblemente hacen que el documento sea más confuso de lo que debería.

3. Incluye elementos que faciliten la lectura. Calidad es mejor que cantidad.

Una imagen vale más que mil palabras. Incluye capturas de pantalla que ayuden a entender mejor lo que explicas pero con cuidado de no exponer información sensible o relacionada con el auditor. Por otro lado, tal como mencionaba en el post anterior un informe que incluye mucha información poco relevante o directamente inútil afecta su calidad. Por ejemplo, no hace falta describir con demasiado detalle las pruebas que se han ejecutado y han fallado o no han arrojado los resultados esperados. Eso al cliente en realidad no le interesa. Las ideas expresadas en el documento deben ser claras y concisas, no hay que dar demasiados rodeos ni tampoco incluir opiniones personales o conjeturas. Si no puedes demostrar que una vulnerabilidad existe o es explotable puedes plantearlo como algo que se debería revisar en un contexto de caja blanca, pero no puedes decir que es algo critico y centrar el informe en problemas que “crees” que existen en el sistema auditado sin aportar ninguna prueba de ello.

4. Incluye niveles de criticidad.

Cada defecto o vulnerabilidad debe contar con un nivel de criticidad o gravedad. Puedes utilizar el modelo de CVS e indicar que tan delicado es el descubrimiento en función de su dificultad de explotación, impacto técnico, impacto de negocio y posibles defensas que se pueden aplicar. Esto permitirá indicar qué cosas deben ser solucionadas cuanto antes (como el caso de una vulnerabilidad que permite RCE) y qué cosas probablemente no son tan criticas o que no representan un riesgo e impacto altos (como el caso de un XSS reflejado).

4. Buenas prácticas.

De cara a la redacción y elaboración de los contenidos del informe suelo seguir las siguientes “buenas prácticas” o al menos para mi lo son.

1. Cuidado con las faltas de ortografía. Muchas veces son errores puntuales por escribir rápido, es conveniente revisar el documento completo un par de veces para depurar.
2. Incluye detalles sobre las personas de contacto, horarios y medios de comunicación que se empleará.
3. Si no se encuentra ninguna vulnerabilidad sobre un servicio desactualizado, es mejor hablar con la persona de contacto antes de incluir en el informe que se “recomienda actualizar dicho servicio”. El motivo de esto es que pueden existir otros factores o motivaciones para conservar una versión antigua y no actualizar (incompatibilidades con otras aplicaciones, módulos que dependen únicamente de la versión en ejecución, etc.). Este tipo de detalles también se pueden dejar documentados en el informe para mayor claridad.
4. Si en las recomendaciones se explica, aunque sea a grandes rasgos, cómo se pueden aplicar las contramedidas por parte del equipo técnico, esto aportará valor añadido al informe y tendrá mejor aceptación.
5. En las capturas de pantalla es recomendable no filtrar información sensible del sistema/usuario que está haciendo las pruebas. Es mejor cambiar la variable de entorno “PS1” e incluir un texto genérico.
6. En el informe no se suelen incluir exploits o rutinas de código extensas, las PoC se adjuntan como anexos del documento. Esto en el caso de que la PoC en cuestión haya sido creada por el pentester, si es un exploit público basta con poner un enlace donde se encuentre.
7. Es preferible incluir enlaces y referencias a conceptos técnicos básicos que explicarlos en el documento de auditoría.
8. Intentar que las capturas de pantalla tengan un tamaño de letra adecuado, que se puedan ver los comandos ejecutados sin forzar demasiado la vista.
9. Las recomendaciones generales deberían declararse en formato de “checklist” para que sean fáciles de seguir y aplicar por parte de un técnico. Además, también es aconsejable incluir referencias en internet y los “how to” necesarios para aplicar las recomendaciones indicadas.
10. En post-explotación no hace falta incluir todos y cada uno de los comandos ejecutados, solamente se incluirán aquellos que puedan ser relevantes o interesantes según el criterio del pentester
11. Si bien es importante tomar capturas de pantalla no hay que abusar de ellas. Si el informe parece un “álbum de fotos” puede denotar una baja calidad en los trabajos realizados, aunque no haya sido así. Recuerda que normalmente el cliente valorará tu rendimiento en función del informe que entregues.
12. Evitar en la medida de lo posible incluir opiniones personales, el informe debe ser lo más neutral y objetivo posible.
13. Es recomendable incluir un historial de eventos con fechas relacionadas. En dicho historial se pueden incluir los siguientes elementos.
    1. Cambios de alcance (se ha incluido una nueva máquina, por ejemplo).
    2. Cambios organizativos (personas de contacto o en el equipo de pentesters).
    3. Disposición de los sistemas y cambios estructurales (cambios en IPs, rangos de red o dominios, cambios en servicios o aplicativos, etc.)
    4. Comentarios y/o sugerencias por parte del cliente o equipo durante el proceso de auditoría.
    5. Ataques que han producido condiciones de DoS.

5. Plantillas.

Finalmente, te dejo algunos enlaces a plantillas que te pueden ser útiles en la elaboración de tus informes.

PurpleSec

Pentest-hub

TCM Security

Offensive Security

TGB Security

Y por último, aunque no es una plantilla, existe una herramienta que he descubierto hace poco y funciona bastante bien, se trata de PWNDoc.

Fuente: https://thehackerway.com/2021/06/24/como-crear-un-informe-de-pentesting-parte-1-de-2/

https://thehackerway.com/2021/06/28/como-crear-un-informe-de-pentesting-parte-2-de-2/