SQHell - TryHackMe
SUMMARY
Debemos encontrar cinco banderas en la maquina SQHell. Donde a partir del escaneo de puertos de Nmap pude saber que hay un servicio HTTP y SSH.Además, con un script de Nmap supe que había una aplicación web almacenado en el servidor web. Luego, me encontré con la vulnerabilidad SQLi In-band basada en errores en la página web. Donde se podía obtener información sobre el contenido de cada post, y llegue a volcar todos los registros de las bases de datos, obteniendo la primera bandera. Luego, me encontré una vulnerabilidad SQLi Blind en un formulario HTTP, que me permitió omitir la autenticación y obtener la segunda bandera. Luego, me encontré con la vulnerabilidad SQLi Blind en un pagina web. Donde se podía obtener información sobre los usuarios quienes habían posteado un post, y llegue a volcar todos los registros de las bases de datos, obteniendo la tercera bandera. Luego, me encontré con un registro que utilizaba una solicitud GET JSON que era vulnerable a SQLi Blind basada en booleanos, y llegué a volcar todos los registros de las bases de datos, obteniendo la cuarta bandera. Luego, a partir del uso del encabezado HTTP X-Forwarded-For y sqlmap, llegue a saber que se podía realizar una SQLi Blind Basada en el tiempo, y llegue a volcar todos los registros de las bases de datos, obteniendo la quinta bandera.
FASE RECONOCIMIENTO ACTIVO
En este caso debemos explotar diferentes tipos de vulnerabilidades SQLi de la aplicación web almacenada en el servidor web del sistema destino. Para ello empezaremos utilizando el comando openvpn con el fin de establecer una conexión VPN con la red virtual dónde está la máquinaSQHell. Para ello utilizaremos el archivo de configuración, que lo podemos descargar en la plataforma de Tryhackme, que puede incluir información como la dirección del servidor VPN, los certificados y claves de seguridad, la configuración de encriptación, etc.
Luego de que se establece la conexión VPN se crea una interfaz virtual de red en nuestra máquina. Donde se enruta todo el tráfico de red a través de esa interfaz.
Además, la plataforma de Tryhackme nos muestra la dirección ip de la máquina SQHell.
FASE ESCANEO Y ENUMERACION
Luego pasaremos a la fase de Escaneo y Enumeración con el fin de poder escanear los puertos del nodo. Además, obtendremos los servicios que se han levantado en los puertos abiertos, las versiones de los servicios, y el sistema operativo de la máquina SQHell. Para ello utilizaremos Nmap. Donde le pasaremos los siguientes parámetros:
- El parámetro -sC o –script=”default” para utilizar todos los scripts de la categoría default con el fin de realizar un escaneo y detección de los puertos de manera avanzada.
- El parámetros -sV con el fin de conocer las versiones de los servicios levantados en los puertos abiertos.
- El parámetro -n para evitar la resolución DNS, y el parámetro –max-rate para indicarle el número máximo de paquetes por segundo que va a utilizar Nmap para el escaneo con el fin de evitar sobrecargar la red con el tráfico generado por la herramienta.
- El parámetro -p- para realizar un escaneo de los 65535 puertos del nodo y el parámetro –open con el fin de que nos muestre información solo de los puertos abiertos.
Los resultados que obtuvimos del escaneo vienen a ser:
- Hay un servicio HTTP que se está levantado en el puerto 80, y el programa servidor HTTP que se está corriendo. Además, la versión del programa servidor.
- Hay un servicio SSH que se está levantado en el puerto 22, y el programa servidor SSH que se está corriendo. Además, la versión del programa servidor SSH.
- A través del script http-title.nse de Nmap se pudo capturar el valor de la etiqueta o elemento HTML title, que viene a ser el título de una página web almacenada en el servidor web.
Ahora, observamos la página web desde mi navegador web.
Podemos observar que la página web viene a ser la página de inicio de una aplicación web. Donde los usuarios pueden publicar sus posts, y que consta de los siguientes elementos:
- Un formulario o login HTML donde te puedes autenticar para acceder al portal de administración de la aplicación web.
- Un registro. Donde ya no admite más registros.
- Páginas web donde puedes obtener información sobre los usuarios quienes han posteado algún post. Además, podemos observar un parámetro GET id que probablemente es utilizado por la aplicación web para realizar su consulta SQL hacia su base de datos para mostrar la información sobre el usuario.
- Páginas web donde puedes obtener información sobre los posts completos. Además, podemos observar un parámetro GET id que probablemente es utilizado por la aplicación web para realizar su consulta SQL hacia su base de datos para mostrar el contenido completo del post.
FASE HACKING O GANAR ACCESO O EXPLOTACION
Ahora probaremos si el formulario HTML es vulnerable s SQLi. Para ello insertaremos la consulta SQL ‘ or 1=1;– - con el fin de omitir la autenticación ya que si el desarrollador de la aplicación web no ha utilizado consultas parametrizados con marcadores de posición nuestra consulta SQL maliciosa se concatenara con la consulta SQL, que realiza la aplicación web hacia su base de datos, para verificar nuestra identidad, pero debido a nuestra consulta SQL malicioso, la consulta SQL original siempre arrojara un valor true cuando sea procesada por el DBMS.
Podemos observar que el formulario HTML si es vulnerable a SQLi. Además, llegamos a obtener nuestra primera bandera.
Ahora probaremos si el parámetro GET id de la página web, donde se observa el contenido completo de cada post, es vulnerable a SQLi. Para ello introduciremos los caracteres ‘ o “” con el fin de saber de si se el valor que introducimos se concatena directamente con la consulta SQL que realiza el sitio web hacia su base de datos. Además, si es el caso obtendremos un mensaje de error emitido por el DBMS en el sistema destino, que gestiona las bases de datos.
Podemos observar que cuando introducimos el carácter “nos generó un mensaje de error. Por lo tanto, el sitio web si es vulnerable a SQLi.
Ahora enumeraremos las bases de datos que utiliza la aplicación web.
Podemos observar que consta de dos bases de datos, aunque una de ellas viene por defecto al momento de instalar el DBMS.
Ahora enumeraremos las tablas de la base de datos sqhell_5.
Podemos observar que la base de datos park contiene las tablas flag,posts, and users.
Ahora enumeraremos las columnas de las tres tablas.
Tabla flag:
Tabla posts:
Tabla users:
Podemos observar todas las columnas de las tablas.
Ahora volcaremos todos los registros de las tres tablas:
Tabla flag:
Tabla posts:
Tabla users:
Podemos observar que llegamos a obtener las credenciales de usuario (admin:password) de la aplicación web en la tabla users. Además, encontramos otra bandera en la tabla flag.
Otra manera que pudimos haber optado para automatizar la explotación de la vulnerabilidad SQLi del sitio web, es mediante el uso de la herramienta sqlmap de la siguiente manera:
Podemos observar que llegamos a obtener todas las bases de datos gestionados por el DBMS del sistema destino.
Ahora volcaremos todos los registros de todas las tablas de la base de datos flag.
Podemos observar que llegamos a obtener los mismos resultados, pero de una manera más rápida.
Ahora probaremos si el parámetro GET id de la página web, donde se observa información sobre el usuario quien posteo el post, Para ello introduciremos los caracteres ‘ o “” con el fin de saber de si se el valor que introducimos se concatena directamente con la consulta SQL que realiza el sitio web hacia su base de datos. Además, si es el caso obtendremos un mensaje de error emitido por el DBMS en el sistema destino, que gestiona las bases de datos.
Podemos observar que no se obtuvo un mensaje error. Por lo tanto, lo mas probable es que se trate de una vulnerabilidad SQLi blind. Donde el desarrollador de la aplicación web haya deshabilitado que los mensajes de error emitidos por el DBMS sean mostrados por el navegador web.
Ahora intentaremos enumerar las bases de datos gestionadas por el DBMS en el sistema destino.
Podemos observar que el parámetro GET id si presenta la vulnerabilidad SQLi blind. Además, el desarrollador de la aplicación web no ha implementado ninguna validación hacia los parámetros que se pueden insertar como valor en el parámetro GET id. Además, llegamos a enumerar las bases de datos.
Ahora enumeraremos las tablas de la base de datos sqhell_4.
Podemos observar que la base de datos sqhell_4 consta de una sola tabla.
Ahora enumeraremos las columnas de la tabla users.
Podemos observar que la tabla consta de 3 columnas.
Ahora volcaremos todos los registros de la tabla users.
Podemos observar que encontramos las credenciales del mismo usuario, que encontramos anteriormente, pero nos damos cuenta de algo inusual en el valor del parámetro Posts, ya que no se muestran los dos valores que observamos anteriormente (First Post and Second Post). Esto ha sucedido cuando hemos cambiado el valor del parámetro User ID. Por lo tanto, nos da a suponer que la aplicación web realiza otra consulta SQL a partir del valorUser ID, que se obtiene de la primera consulta SQL que realiza la aplicación web con el parámetro GET id, con el fin de mostrar los valores del parámetro POSTS.
Ahora probaremos si el parámetro User ID es vulnerable a SQLi Blind o In-Band (Donde se nos mostraría a un mensaje de error en nuestra pantalla al momento de insertar un carácter especial).
Podemos observar que el parámetro User ID es vulnerable a SQLi Blind.
Ahora enumeraremos las bases de datos gestionados por el DBMS.
Podemos observar que son las mismas bases de datos encontradas anteriormente.
Ahora teniendo en cuenta la sugerencia que nos da el creador de la maquina vulnerable, volcaremos los registros de la columna flag de la tabla flag.
Podemos observar que llegamos a encontrar la tercera bandera.
Ahora si volvemos al registro encontrado anteriormente.
Podemos observar que se realiza una verificación de la disponibilidad del username en tiempo real. Además, si analizamos el código fuente del registro, nos encontramos con un código Javascript. Donde se realiza una solicitud GET JSON al servidor web destino para verificar si el valor introducido en el parámetro “username” está disponible o ya ha sido tomado. Luego, el servidor web procesa la solicitud con la ayuda de sus bases de datos que utiliza, y envía una respuesta JSON de vuelta al cliente. Si la respuesta contenida en la respuesta JSON del servidor web esta la palabra available. Entonces, nos aparece el mensaje Username available caso contrario nos aparecerá el mensaje Username already token en nuestro navegador web.
Ahora accederemos a la ruta que se utiliza en la solicitud GET JSON para poder interactuar con la respuesta GET JSON obtenida del servidor web.
A partir de este valor booleano que obtenemos. Podemos obtener información sobre la base de datos que utiliza el servidor web para validar si unusername esta valido o no.
Ahora probaremos si el parámetro username admin es vulnerable a SQLi Blind basada en booleanos donde obtendremos los valores false y true a partir de nuestras consultas SQL maliciosasa. Para ello utilizaremos sqlmap ya que el proceso manual es bastante engorroso.
Podemos observar que la herramienta llego a encontrar dos bases de datos, aunque la primera base de datos es especial ya que se crea por defecto al momento de instalar el DBMS.
Ahora enumeraremos las tablas de la base de datos sqhell_3.
Podemos observar que se llego a enumerar las tablas de la base de datos sqhell_3.
Ahora volcaremos los registros de ambas tablas.
Tabla flag:
Tabla users:
Podemos observar que llegamos a encontrar la cuarta bandera. Además, encontramos unas credenciales (admin: icantrememberthispasswordcanyou).
Ahora si volvemos a la pagina de inicio de la aplicación web nos encontramos con otro recurso que nos habla sobre los términos y condiciones.
Uno de los términos y condiciones nos indica que se está registrado nuestra dirección IP por propósitos analíticos. Esto nos da suponer que hay un dispositivo intermedio entre el servidor web y las solicitudes HTTP que realizaremos, por ejemplo, puede haber un WAF o un balanceador de carga o un proxy. Además, estos dispositivos intermedios pueden estar configurados para que agreguen las cabeceras HTTP X-Forwarded-For o X-Originating-IP o X-Remote-IP o X-Forwarded-Host o X-Remote-Addr, con el fin de que capturar la dirección IP del sistema quien esta realizando la solicitud HTTP, y de esta manera el servidor web puede saber nuestra dirección IP. Aunque, la cabecera X-Forwarded-For HTTP viene a ser la cabecera estándar ampliamente reconocida y utilizada por el protocolo HTTP.
Ahora si buscamos información sobre utilizar el encabezado X-Forwarded-Host para realizar ataques SQLi, nos encontramos con este post https://resources.infosecinstitute.com/topics/application-security/sql-injection-http-headers/. Donde nos comenta un caso donde se genera una SQLi a partir de que el valor del encabezado X-Forwarded-For es utilizado como el valor de un parámetro que es utilizado en la consulta SQL que realiza la aplicación web hacia su base de datos con el fin de almacenar todas las direcciones IP.
Ahora utilizaremos sqlmap para poder saber si a través del encabezado X-Forwarded-For es posible realizar un SQLi. Para ello utilizaremos uno de los comandos encontrados en Hacktricks: https://book.hacktricks.xyz/pentesting-web/sql-injection/sqlmap y que están relacionados con SQLi a través de encabezados HTTP.
Después de esperar bastante tiempo, sqlmap nos dijo que si era vulnerable a SQLi Blind basada en Tiempo. Además, podemos observar el payload que utilizo la herramienta para enumerar información sobre la base de datos. Además, llegamos a obtener los nombres de las bases de datos gestionadas por el DBMS en el sistema destino.
Ahora enumeraremos las tablas de la base de datos sqhell_1.
Podemos observar las dos tablas de la base de datos sqhell_1.
Ahora volcaremos todos los registros de la tabla flag.
Podemos observar que llegamos a obtener la quinta flag.