¿Cómo crear un informe de pentesting? Parte 2 de 2

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.

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. Hablaré de ella en un próximo artículo.

Un saludo y Happy Hack!
Adastra.