Page 1

En muchas aplicaciones web, las peticiones realizadas por usuarios en sesiones de bajo privilegio o preautenticadas suelen estar más protegidas debido a la atención que los desarrolladores ponen en los puntos más expuestos de la aplicación. Por ejemplo, las entradas de formularios, los parámetros de URL y las solicitudes que son visibles o manipulables por usuarios anónimos o con bajo nivel de acceso, tienden a estar más controladas y validadas. Esto reduce el riesgo de ataques como SQL Injection en esos contextos.

Sin embargo, en sesiones post-autenticadas o con mayores privilegios, como las sesiones de administración, el nivel de protección puede disminuir. Esto puede suceder porque los desarrolladores confían en que los usuarios autenticados ya han pasado ciertos controles y, por lo tanto, no implementan las mismas medidas de seguridad. Este exceso de confianza puede hacer que las áreas críticas de la aplicación, como paneles administrativos o endpoints de alto nivel, sean más susceptibles a vulnerabilidades como SQL Injection.

Importancia de Evaluar Peticiones de Alto Privilegio

Para aprender y entender mejor este concepto, en este ejercicio nos enfocaremos en una petición que sabemos que es vulnerable a SQL Injection y que se encuentra dentro de una sesión administrativa, lo que es particularmente relevante después de haber logrado la escalación de privilegios previa.

Análisis de la Petición Vulnerable

La petición en cuestión, que se realiza tras acceder al sistema con privilegios elevados, es la siguiente:

POST /System/Sistema/Facturas/reporte_1.php HTTP/1.1
Host: 172.16.1.6
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
Origin: http://172.16.1.6
Connection: keep-alive
Referer: http://172.16.1.6/System/Sistema/Facturas/all_facturas.php
Cookie: PHPSESSID=37pfm0jpiovmvn2q1s71ui78j0
Upgrade-Insecure-Requests: 1

factura=34&submit_factura=1

Aquí, el parámetro factura=34 es el valor que se está enviando al servidor para obtener los detalles de una factura específica. Como estamos en una sesión administrativa, el sistema no parece aplicar las mismas protecciones que podríamos encontrar en áreas menos sensibles, permitiendo que este parámetro sea vulnerable a SQL Injection.

Ejecución del Ataque SQL Injection

Usando sqlmap, una herramienta automatizada para la detección y explotación de inyecciones SQL, ejecutamos un análisis sobre la petición:

┌──(root㉿kali)-[/home/kali/Desktop/CPPJ]
└─# proxychains sqlmap -r reporte1-request.txt

El análisis de sqlmap muestra que el parámetro factura es vulnerable a varios tipos de SQL Injection:

[18:05:43] [INFO] POST parameter 'factura' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
POST parameter 'factura' is vulnerable.

Esto confirma que el parámetro factura puede ser manipulado para realizar consultas SQL arbitrarias contra la base de datos del backend, lo que abre la puerta a múltiples vectores de ataque.

Tipos de SQL Injection Identificados

sqlmap identificó varios tipos de SQL Injection que pueden ser explotados en esta petición:

1. Boolean-based Blind: En este tipo de inyección, las respuestas del servidor dependen de si la condición en la inyección es verdadera o falsa. Esto permite inferir información sin que el servidor devuelva directamente el resultado de la consulta.

2. Time-based Blind: Este tipo de inyección aprovecha la función SLEEP en SQL para retrasar la respuesta del servidor, permitiendo determinar si la consulta se está ejecutando correctamente según el tiempo de respuesta.

3. Union-based SQL Injection: Permite unir múltiples consultas para obtener datos adicionales de la base de datos. Este es uno de los métodos más utilizados para extraer información de manera directa.

Identificación del Backend

sqlmap también confirma que el backend de la aplicación está utilizando una base de datos MySQL, específicamente una versión superior a 5.0.12 (probablemente un fork de MariaDB), lo cual es información valiosa para ajustar los ataques a las características de este DBMS:

[18:05:46] [INFO] the back-end DBMS is MySQL
web application technology: Apache
back-end DBMS: MySQL >= 5.0.12 (MariaDB fork)

Riesgos Asociados a SQL Injection en Sesiones Administrativas

La SQL Injection en este contexto tiene implicaciones serias, especialmente porque estamos en una sesión administrativa, donde los usuarios ya tienen acceso a áreas críticas de la aplicación. Si un atacante logra explotar esta vulnerabilidad, podría:

1. Acceder a Datos Sensibles: Como estamos en una sesión de alto privilegio, un ataque exitoso podría permitir al atacante acceder a información sensible de la base de datos, como datos de usuarios, registros financieros, contraseñas, etc.

2. Manipular la Base de Datos: El atacante podría modificar o eliminar registros críticos, comprometiendo la integridad de los datos de la aplicación.

3. Obtener Control Total del Sistema: En casos más graves, el atacante podría obtener acceso total al sistema, ejecutar comandos en el servidor o incluso instalar backdoors para comprometer el sistema de manera permanente.

Esta vulnerabilidad tambien pudo ser descubierta sin el uso de SQLMAP por medio de un intruder de BurpSuite:

El intruder debe tener la siguiente configuracion:

Y luego de un tiempo, se logra apreciar lo siguiente:

Recomendaciones y Mitigaciones

Para mitigar este tipo de vulnerabilidades, es esencial implementar las siguientes medidas:

1. Validación Rigurosa de Entrada: Todos los parámetros que son enviados al servidor, especialmente en sesiones con privilegios elevados, deben ser rigurosamente validados para evitar la inyección de código SQL.

2. Uso de Consultas Preparadas (Prepared Statements): Las consultas SQL deben implementarse utilizando consultas preparadas o statements, que separan los datos de las consultas, evitando así que los datos enviados por el usuario sean interpretados como parte de la consulta SQL.

3. Análisis Continuo y Auditorías de Seguridad: Las aplicaciones deben ser evaluadas de manera continua para detectar posibles vulnerabilidades como SQL Injection, especialmente después de actualizaciones o cambios importantes en el sistema.