SQLMap - Explotación de S.O.
Última actualización
Última actualización
SQLMap tiene la capacidad de utilizar una inyección SQL para leer y escribir archivos desde el sistema local fuera del DBMS. SQLMap también puede intentar brindarnos la ejecución directa de comandos en el host remoto si tuviéramos los privilegios adecuados.
La primera parte de la explotación del sistema operativo a través de una vulnerabilidad de inyección SQL es la lectura y escritura de datos en el servidor de alojamiento. La lectura de datos es mucho más común que la escritura de datos, que es estrictamente privilegiada en los DBMS modernos, ya que puede conducir a la explotación del sistema, como veremos. Por ejemplo, en MySql, para leer archivos locales, el usuario de la base de datos debe tener el privilegio LOAD DATA
y INSERT
para poder cargar el contenido de un archivo en una tabla y luego leer esa tabla.
LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE passwd;
Si bien no necesariamente necesitamos tener privilegios de administrador de base de datos (DBA
) para leer datos, esto se está volviendo más común en los DBMS modernos. Lo mismo se aplica a otras bases de datos comunes. Aun así, si tenemos privilegios de DBA, entonces es mucho más probable que tengamos privilegios de lectura de archivos.
Para comprobar si tenemos privilegios de DBA con SQLMap, podemos utilizar la opción --is-dba
:
Como podemos ver, si probamos eso en uno de los ejercicios anteriores, obtenemos current user is DBA: False
, lo que significa que no tenemos acceso de DBA. Si intentáramos leer un archivo usando SQLMap, obtendríamos algo como:
Para probar la explotación del sistema operativo, intentemos un ejercicio en el que tenemos privilegios de DBA, como se ve en las preguntas al final de esta sección:
Vemos que esta vez obtenemos current user is DBA: True
, lo que significa que podemos tener el privilegio de leer archivos locales.
En lugar de inyectar manualmente la línea anterior a través de SQLi, SQLMap hace que sea relativamente fácil leer archivos locales con la opción --file-read
:
Como podemos ver, SQLMap guardó los archivos
a un archivo local. Podemos acceder al archivo local para ver su contenido con cat
:
Hemos recuperado con éxito el archivo remoto.
Cuando se trata de escribir archivos en el servidor de alojamiento, se vuelve mucho más restringido en los DMBS modernos, ya que podemos utilizar esto para escribir un Web Shell en el servidor remoto y, por lo tanto, obtener la ejecución del código y tomar el control del servidor.
Por este motivo, los sistemas de gestión de bases de datos modernos desactivan la escritura de archivos de forma predeterminada y requieren ciertos privilegios para que los administradores de bases de datos puedan escribir archivos. Por ejemplo, en MySQL, la configuración --secure-file-priv
debe desactivarse manualmente para permitir la escritura de datos en archivos locales mediante la consulta SQL INTO OUTFILE
, además de cualquier acceso local necesario en el servidor host, como el privilegio para escribir en el directorio que necesitamos.
Aun así, muchas aplicaciones web requieren que los DBMS puedan escribir datos en archivos, por lo que vale la pena probar si podemos escribir archivos en el servidor remoto. Para hacerlo con SQLMap, podemos usar las opciones --file-write
y --file-dest
. Primero, preparemos un shell web PHP básico y escribámoslo en un archivo shell.php
:
Ahora, intentemos escribir este archivo en el servidor remoto, en el directorio raíz web predeterminado de Apache /var/www/html/
. Si no conocemos el directorio raíz web del servidor, veremos cómo SQLMap puede encontrarlo automáticamente.
Vemos que SQLMap confirmó que efectivamente el archivo fue escrito:
Ahora, podemos intentar acceder al shell PHP remoto y ejecutar un comando de muestra:
Vemos que nuestro shell PHP efectivamente fue escrito en el servidor remoto y que tenemos ejecución de comandos en el servidor host.
Ahora que hemos confirmado que podemos escribir un shell PHP para obtener la ejecución de comandos, podemos probar la capacidad de SQLMap para proporcionarnos un shell de SO sencillo sin tener que escribir manualmente un shell remoto. SQLMap utiliza varias técnicas para obtener un shell remoto a través de vulnerabilidades de inyección SQL, como escribir un shell remoto, como acabamos de hacer, escribir funciones SQL que ejecuten comandos y recuperen la salida o incluso utilizar algunas consultas SQL que ejecuten directamente comandos de SO, como xp_cmdshell
en Microsoft SQL Server.
Para obtener un shell de SO con SQLMap, podemos utilizar la opción --os-shell
, de la siguiente manera:
Vemos que SQLMap utilizó de forma predeterminada la técnica UNION
para obtener un shell del sistema operativo, pero finalmente no nos dio ningún resultado No output
. Por lo tanto, como ya sabemos que tenemos varios tipos de vulnerabilidades de inyección SQL, intentemos especificar otra técnica que tenga más posibilidades de darnos un resultado directo, como Error-based SQL Injection
, que podemos especificar con --technique=E
:
Como podemos ver, esta vez SQLMap nos llevó con éxito a un shell remoto interactivo fácil, lo que nos permite una fácil ejecución remota de código a través de este SQLi.
Nota: SQLMap primero nos pidió el tipo de lenguaje utilizado en este servidor remoto, que sabemos que es PHP. Luego nos pidió el directorio raíz web del servidor y le pedimos a SQLMap que lo buscara automáticamente utilizando "ubicaciones comunes". Ambas opciones son las predeterminadas y se habrían elegido automáticamente si hubiéramos agregado la opción "--batch
" a SQLMap.
Con esto, hemos cubierto toda la funcionalidad principal de SQLMap.
Intente utilizar SQLMap para leer el archivo "/var/www/html/flag.txt
".
Nos da true, por lo que este usuario es administrador de la base de datos.
Utilice SQLMap para obtener un shell de sistema operativo interactivo en el host remoto e intente encontrar otra flag dentro del host.
Encontramos otra flag en el directorio raiz /
y conseguimos leer la flag sin problema 🏆