La sección más grande del reporte será la de los write-ups de vulnerabilidades. Cada write-up debería explicar qué es la vulnerabilidad, dónde fue encontrada, cómo fue descubierta y lo más importante, cómo debería remediarse. Esta sección está principalmente escrita para los stakeholders que van a arreglar los problemas, como desarrolladores o administradores de sistemas. Sin embargo, otros, como los analistas de seguridad y project managers pueden revisar estas secciones para trackear la remediación, ofrecer soporte o validar la severidad.
Estructura de un Buen Write-Up
Para hacer tus write-ups limpios y seguibles, deberías seguir una estructura consistente. Aquí un formato que funciona bien:
- Título: Un encabezado corto y descriptivo.
- Puntuación de Riesgo: Una puntuación de riesgo para la vulnerabilidad descubierta. Las vulnerabilidades siempre deberían ser puntuadas en aislamiento.
- Resumen: Una breve explicación de la vulnerabilidad y su impacto potencial en lenguaje normal.
- Contexto: Ofrece contexto adicional para explicar la vulnerabilidad y por qué importa. Esto es especialmente importante si el lector no está familiarizado con él. Recuerda que los desarrolladores que arreglarán la vulnerabilidad seguramente no sean expertos en ciberseguridad.
- Detalles Técnicos y Evidencia: Dónde y cómo se encontró el problema. Incluye peticiones, respuestas, payloads y capturas de pantalla o trocitos de código si fuera necesario.
- Impacto: Qué podría hacer un atacante de forma realista con esta vulnerabilidad. Esto muestra que no sólo das la vulnerabilidad sin pensar en cómo un atacante real lo podría aprovechar en el sistema o aplicación específicos.
- Consejo de Remediación: Pasos claros y realizables para resolver el problema. Es crítico asegurar que el consejo de remediación aplique a la causa base de la vulnerabilidad. Por ejemplo, con una SQLi, aunque la sanitización y validación de input puede mitigar el impacto, se requiere parametrización para evitarla.
- Referencias: Links opcionales de documentación relevante o soporte en el arreglo de vulnerabilidades.
El Contexto Importa
Tu reporte no debe sentirse como si hubiera sido copiado de otro reporte o un libro de texto. Aquellos reportes más valiosos son los que explican las vulnerabilidades en el contexto de los sistemas específicos testeados. Esto significa que el write-up debería responder preguntas como:
- ¿Dónde fue encontrada la vulnerabilidad exactamente?
- ¿Qué asunciones se requieren para que la vulnerabilidad sea explotable?
- ¿Cómo afecta esto al entorno del cliente?
- ¿Qué pasos debería realizar el cliente para solucionarlo?
Ejemplo: SQL Injection Write-Up
Debajo hay un ejemplo de un write-up:
Título: Inyección SQL sin autenticación en el formulario de inicio de sesión
Nivel de riesgo: Alto (Puntuación base CVSS 3.1: 8,6)
Resumen: Se identificó una vulnerabilidad de inyección SQL sin autenticación en el formulario de inicio de sesión de la aplicación TryBankMe. Esto podría permitir a un atacante eludir la autenticación o extraer información confidencial de los clientes.
Contexto:
La inyección SQL se produce cuando los datos proporcionados por el usuario se incluyen de forma insegura en consultas SQL, sin la parametrización adecuada. El intérprete de SQL no puede distinguir entre los comandos SQL y la entrada del usuario, lo que genera una confusión que permite a un actor de amenazas inyectar código directamente en el propio comando SQL. Esta vulnerabilidad se explota habitualmente para eludir la autenticación o extraer datos confidenciales.
Detalles técnicos y evidencias:
El formulario de inicio de sesión ubicado en /login presentaba una vulnerabilidad de inyección SQL a través del campo de nombre de usuario. Utilizando Burp Suite, se interceptó y modificó la siguiente solicitud HTTP:
POST /login HTTP/1.1 Host: trybankme.com Content-Type: application/x-www-form-urlencoded Content-Length: 45 username=' OR 1=1--&password=randomvalue
La aplicación respondió con una redirección 302 Found al dashboard autentificado del usuario:
HTTP/1.1 302 Found Location: /dashboard Set-Cookie: sessionid=abc123xyz456; Path=/; HttpOnly
Esto confirmó que se eludió la autenticación mediante una carga útil clásica de inyección SQL.
Impacto:
Un atacante podría iniciar sesión como cualquier usuario sin necesidad de credenciales válidas. Además, aunque los puntos de inyección correspondían a una inyección ciega (blind injection), un actor malicioso podría aprovechar inyecciones basadas en errores para extraer información de la base de datos.
Recomendación de remediación:
Se deben utilizar consultas parametrizadas para todas las operaciones de base de datos que impliquen entradas del usuario. Por ejemplo, en una aplicación .NET que utilice MS SQL como base de datos, la consulta de inicio de sesión debería modificarse para quedar de la siguiente manera:
using (SqlConnection connection = new SqlConnection(connectionString)) { string query = "SELECT * FROM Users WHERE Username = @username AND Password = @password"; SqlCommand command = new SqlCommand(query, connection); command.Parameters.AddWithValue("@username", inputUsername); command.Parameters.AddWithValue("@password", inputPassword); connection.Open(); SqlDataReader reader = command.ExecuteReader(); if (reader.HasRows) { // Login successful } }
Como se muestra en el ejemplo anterior, la entrada del usuario está claramente separada del comando SQL, lo que garantiza que el motor SQL no pueda confundirse.
Referencias: