Continuando con las entradas relacionadas a explotación sobre MSSQL, ahora exploraremos como explotar bases de datos enlazadas y la posibilidad de desplegar un servidor SSH “portable” a través de una base de datos MSSQL con la función “xp_cmdshell” habilitada y que utilice a un usuario de servicio.
Configuración de bases de datos enlazadas
Utilizaremos la base de datos del anterior post y una nueva instalada en el servidor coreint.
Ahora, accedemos con un usuario privilegiado a la base de datos en dbint, navegando en las siguientes opciones hasta identificar la carpeta Linked Servers, donde hacemos click derecho y accedemos a la opción New Linked Server.
Acá podemos definir el hostname del servidor, por lo que es necesario que los registros DNS estén configurados de manera correcta en el servidor DNS, en el caso de que se tenga un enlace sobre un servidor en un dominio distinto, se tendrá que agregar el registro hacia este nuevo servidor en el DC actual o establecer el DC del dominio distinto como servidor DNS principal.
En nuestro caso, ambos servidores están en el mismo dominio, así que no es necesario alterar los registros DNS, simplemente establecemos el hostname y marcamos la opción SQL Server.
Luego, hacemos click en la opción Security y marcamos la ultima opción, definiendo una credencial de autenticacion local que creamos en la base de datos de coreint, en mi caso, sqluser.
Finalmente, vamos a la opción Server Options y cambiamos los valores de las dos opciones de RPC a True.
Hacemos click en OK y no deberíamos tener errores al obtener la nueva base de datos enlazada.
Podemos ejecutar una consulta de prueba desde el mismo gestor para validar que tenemos acceso.
De esta manera, ya tenemos la base de datos enlazada lista para la explotación.
Explotación
Para la explotación asumiremos el caso de compromiso de la cuenta sqluser, tanto de dominio como local de la base de datos.
Podemos acceder a través de Impacket para empezar la enumeración.
Podemos utilizar la query propia de MSSQL, exec sp_linkedservers o una función de la herramienta, enum_links, que al final devuelven la misma información, ahi observamos que el enlace esta establecido.
Ahora, podemos utilizar consultas propias de MSSQL para ejecutar consultas en la base de datos enlazada, en este caso, utilizaremos la opción Execute.
De esta manera, podríamos ejecutar consultas para habilitar la ejecución de comandos remota en este servidor y obtener acceso remoto.
Podemos utilizar la función use_link del cliente MSSQL de Impacket, definiendo el nombre entre comillas dobles ya que contiene puntos, los cuales el cliente interpretara como parte de una consulta SQL en lugar de un string.
Ahora, podemos habilitar la ejecución de comandos como en posts anteriores.
Ya podríamos realizar acciones de post explotación sobre este servidor y continuar con la cadena de explotación.
Por esta razón, vale la pena enumerar bases de datos MSSQL, que este tipo de situaciones pueden ser identificadas en entornos empresariales.
Ahora, exploraremos la posibilidad de desplegar un servidor SSH “portable”.
Configuración del entorno
Lo principal es asegurarse que el servicio MSSQL esta siendo ejecutado bajo un usuario de servicio a través del administrador de la base de datos.
Luego, click derecho en la opción SQL Server (SQLExpress), en mi caso, y acceder a las propiedades, seleccionando la opción Built-in account y alguna de las cuentas internas.
Junto a la posibilidad de ejecutar comandos a través de xp_cmdshell, procedemos a la explotación.
Explotación.
Para poder desplegar el servidor SSH sin la necesidad de instalarlo, podemos descargar el binario para Windows.
https://github.com/PowerShell/Win32-OpenSSH/releases/tag/v9.5.0.0p1-Beta
En mi caso, descargamos el fichero OpenSSH-Win64.zip, que tiene el siguiente contenido.
Dejaremos este fichero comprimido en una ruta accesible en el servidor de base de datos, esto se podría realizar a través de descargas ejecutando comandos a través de xp_cmdshell o similares, en mi caso, por temas de simplicidad, lo descargue de manera directa en el equipo.
Adicionalmente, copie el fichero ssh_config_default con un nuevo nombre, que sera el que modificaremos para que use nuestros propios parametros.
Revisamos el fichero de configuración por defecto, donde la primera sección que debemos modificar son las host keys.
Cuando el servicio se instala de manera regular, las host keys se almacenan en rutas predefinidas y el binario obtiene los parametros por defecto si no se especifica un fichero de configuración distinto, sin embargo, como queremos desplegar un servidor SSH sin realizar la instalación, necesitamos crear nuestras propias host keys.
Para hacer esto, podemos utilizar el binario ssh-keygen.exe, utilizando los siguientes comandos:
ssh-keygen -q -N “” -t dsa -f C:\Users\Public\Music\openssh\keys\ssh_host_dsa_key
ssh-keygen -q -N “” -t rsa -f C:\Users\Public\Music\openssh\keys\ssh_host_rsa_key
ssh-keygen -q -N “” -t ecdsa -f C:\Users\Public\Music\openssh\keys\ssh_host_ecdsa_key
ssh-keygen -q -N “” -t ed25519 -f C:\Users\Public\Music\openssh\keys\ssh_host_ed25519_key
Ahora, por temas de permisos, es importante considerar que tenemos que utilizar la cuenta que levantara el servicio para crear estos ficheros, caso contrario, la cuenta de servicio no tendra privilegios para leer estos ficheros y el servidor no funcionara.
Esto lo podemos hacer a través de la ejecución de comandos por MSSQL y xp_cmdshell.
Primeramente confirmamos que se esta utilizando una cuenta de servicio para la base de datos, al ejecutar xp_cmdshell, se utilizara el contexto del usuario configurado, en este caso, un usuario de servicio.
Ahora, generamos las host keys una por una en la ruta especificada a través de esta ejecución de comandos, garantizando que el usuario de servicio tenga acceso a estos ficheros.
Ejecutando el comando, listamos los contenidos del directorio confirmando que las llaves se crearon.
Creamos el resto de host keys.
Listamos el directorio, confirmando la creación de todos los ficheros.
Una vez creadas las host keys, modificamos el fichero de configuración que utilizaremos para levantar el servidor, especificando las rutas absolutas.
Otras opciones que podemos modificar en el fichero de configuración son las siguientes.
Otra opción importante que debemos modificar es la ruta del fichero .pid, en este caso, especificaremos una ruta de acceso libre para cualquier usuario.
Adicionalmente, es importante comentar las ultimas dos lineas del fichero de configuración, para que la autenticación funcione.
Ahora, podemos ejecutar el servidor ssh desde la sesión de comandos de la base de datos.
Primeramente, listamos los puertos en escucha, observando que no se tiene algún servicio en el puerto 2222, que es el que usaremos.
Adicionalmente, buscamos las aplicaciones instaladas, confirmando que OpenSSH no se encuentra instalado.
Ahora, ejecutamos el servidor desde la terminal de comandos, utilizando el parámetro -f que nos permite definir el fichero de configuración y el parámetro -p para definir el puerto, en mi caso, 2222.
No recibimos una respuesta, porque el binario esta en ejecución, esto lo podemos confirmar desde el mismo servidor.
Observamos que tenemos un nuevo puerto a la escucha.
Ademas, con el PID, obtenemos los detalles del proceso, confirmando que es un servidor SSH.
Si probamos el acceso, confirmamos que el servidor se encuentra funcional utilizando una cuenta de administrador local.
De la misma manera, podemos desplegar un túnel SSH dinámico, para temas de pivoting.
Ahora, podríamos utilizar este túnel para llegar a segmentos previamente inaccesibles, por ejemplo, el servidor dbjsec del dominio principal, con la dirección IP 192.168.30.150.
Validamos que desde nuestra Kali no tenemos acceso directo.
Pero si tenemos llegada desde el servidor dbint.
Así que utilizaremos proxychains para utilizar el túnel SSH creado anteriormente.
De esta manera, tenemos la posibilidad de desplegar un servidor SSH para acceso remoto, persistencia, pivoting u otras tareas de movimiento lateral.
Por el momento, el acceso remoto funciona únicamente utilizando una cuenta de administrador local, una cuenta de bajos privilegios no tiene la posibilidad de desplegar un túnel o levantar una shell interactiva, ando investigando como podría realizar esas acciones.
Utilizando una cuenta de dominio de bajos privilegios, no se establece la sesión de manera correcta.
Si bien es una técnica poco convencional y requiere de varias condiciones para funcionar, existen escenarios donde podría ser utilizada para pivoting sin mucha preocupación de que un antivirus o EDR bloquee la ejecución de binarios conocidos para esta tarea (chisel, ligolo-ng, Invoke-SocksProxy).