Cómo sacar partido a las Variables del Sistema en ataques SQL Injection a MySQL #SQLInjection #MySQL

Ayer os comentaba un tip para utilizar @@version en lugar de version() cuando se hace una explotación de un bug de SQL Injection en un SGBD basado en MySQL. Como no entendía bien el motivo de este comportamiento, pasé un poco de tiempo de mi tarde del domingo para revisar en detalle este comportamiento, que al final da mucho más juego de lo que pensaba y que permite hacer muchas cosas peligrosas. Vamos a ver que os lo explique un poco más en detalle.

Figura 1: Cómo sacar partido a las variables del sistema en ataques SQL Injection a MySQL

El motor de MySQL, como el resto de los motores de bases de datos, cuenta con Variables del Sistema. Este conjunto de variables del sistema se utilizan para configurar un arranque concreto del motor de MySQL, estableciendo valores como la zona horaria, el charset o los ficheros de log,  o para configurar los valores de una determinada sesión de usuario, como el tiempo máximo de interactividad, o la ubicación de los recursos temporales. Estas variables pueden ser estáticas o dinámicas, y muchas de ellas pueden ser consultadas desde el CLI (Interfaz de comandos).

Figura 2: Extracto de la lista de Variables del Sistema de MySQL

El valor que tengan se puede consultar vía comando SQL utilizando @@ antes del nombre de la variable. Lo cierto es que dependiendo los permisos de la sesión, y del tipo de variable se podrá acceder a ella o no, pero los resultados a las pruebas que hice durante la tarde del domingo fueron muy satisfactorios.

Figura 3: Versión de MySQL para un sistema operativo Linux

Una vez que ya sabemos que lo que se consulta con @@ son las variables del sistema, ya solo basta con ir a la documentación y buscar qué variables tenemos allí. Como se puede ver, la lista de estas variables del sistema es larga, muy larga, y por supuesto está @@version y, como me apuntó mi compañero Amador Aparicio, @hostname, que da información muy útil. 

Figura 4: Accediendo al hostname del servidor en que corre MySQL

Pero no solo estas variables. Hay variables pasa saber en qué puerto (@@port) corre el servidor MySQL, qué protocolo de seguridad tiene, cuál es la política de contraseñas, cuál es el comentario de la versión de MySQL, qué compilación para qué sistema operativo tiene, etcétera.

Figura 5: Puerto por el que corre el motor de MySQL

Muchas de ellas, por supuesto, tienen información de rutas a ficheros o directorios de configuración, con lo que es fácil hacer un descubrimiento de rutas del servidor a través de estas variables, que pueden ser extraídas, también, por ataques Blind SQL Injection.

Figura 6: Accediendo a la ruta de @@datadir

De todas ellas, hay unas que me han parecido las más peligrosas, que son report_hostname, report_port, report_user y report_password, que se utilizan para configurar un sistema de reporte de esclavos en entornos de replicación. Es decir, que al final, podríamos sacar información de la infraestructura y credenciales válidas.

Figura 7: Variables para configuración una conexión a un servidor de reporte

También son curiosas, @@proxy_user, que puede filtrar datos de cuentas de usuario, @@datadir que informa dónde están los ficheros de datos en el sistema, o @@tmpdir, que también puede ayudar a localizar puntos con permisos de escritura dentro del sistema operativo.

Figura 8: Imprimiendo con un ataque de SQL Injection inband el directorio temporal configurado en MySQL

Dependiendo de la versión de MySQL con la que estemos trabajando y la configuración del sistema, se podrá obtener más o menos información, pero ya sabéis cómo sacar la versión de MySQL, ¿no?

Saludos Malignos!