The MarketPlace - TryHackMe
SUMMARY
Debemos encontrar 2 banderas en la maquina The Marketplace. Donde a partir del escaneo de puertos de Nmap pude saber que hay un servicio HTTP y Node.js, que actúa como un servidor web. Además, con un script de Nmap supe que hay una página web almacenada en el servidor web. Además, esta página web viene a formar parte de una aplicación web, que es vulnerable a SQLi basada en errores y XSS. Luego, explotando ambas vulnerabilidades llege a encontrar unas credenciales, que me permitió acceder al sistema destino siendo el usuario local jake. Luego, realice una escalada de privilegios horizontal aprovechando que podía ejecutar un script con los privilegios del usuario Michael. Además, el script utilizaba el comando tar y un comodin o wilcard. Donde aproveche el uso del comodín en el comando tar para generar una Shell con los privilegios del usuario michael. Luego, realice una escalada vertical para ser el usuario root aprovechando que el usuario michael pertenece al grupo secundario Docker.
FASE RECONOCIMIENTO
Para resolver este ejercicio empezaremos utilizando el comando openvpn con el fin de establecer una conexion VPN con la red virtual donde esta la maquina THe Marketplace. Para ello utilizaremos el archivo de configuracion, que lo podemos descargar en la plataforma de Tryhackme, que puede incluir informacion como la direccion del servidor VPN, los certificados y claves de seguridad, la configuracion de encriptacion, etc.
Luego de que se establece la conexion VPN se crea una interfaz virtual de red en nuestra maquina. Donde se enruta todo el trafico de red a traves de esa interfaz.
Ademas, la plataforma de Tryhackme nos muestra la direccion ip de la maquina The Marketplace.
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 The Marketplace. 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ámetro -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 levantado en el puerto 80, y el programa servidor HTTP que se está corriendo. Además, la versión del programa servidor HTTP.
- Hay un servicio Node.j, que se está actuando como un servidor web levantado en el puerto 32768.
- A partir del script http-tittle.nse de Nmap llegamos a saber que hay una página web que se aloja en ambos servidores web.
- Hay un servicio SSH, que esta levantado en el puerto 22, y el programa servidor SSH que se está corriendo. Además, la versión del programa servidor SSH
Ahora observaremos la página web desde mi navegador web.
Podemos observar que la página web, forma parte de una aplicación web, que presenta dos formularios donde puedo registrarme y autenticarme. Luego, de crear una cuenta y autenticarme, puedo acceder a la plataforma de la aplicación web. Donde puedo publicar artículos que los usuarios podrán visualizar cuando accedan a la aplicación web. Además, tenga la opción de reportar un articulo para que el administrador de la aplicación web pueda revisarlo.
Ahora pondremos a prueba si el sitio web presenta la vulnerabilidad XSS. Para ello observaremos como se insertan los valores que digitamos para describir nuestro artículo, que publicamos anteriormente, en el código fuente de la página web.
Podemos observar que se insertan dentro de las etiquetas h1 y br.
Ahora inyectaremos un código Javascript como valor de la descripción de un artículo que publicaremos con el fin de probar si la aplicación web no filtra o valida adecuadamente los datos ingresados en estos campos, y en el caso de que no lo haga se generara una ventana emergente con la palabra XSS.
Podemos observar que llegamos a obtener la ventana emergente con el mensaje XSS. Por lo tanto, la aplicación web es vulnerable a xss.
Ahora, sabiendo que podemos reportar el articulo para que un administrador de la aplicación web pueda evaluar el artículo. Utilizaremos un código Javascript que capture todas las cookies de inicio de sesión de todos los usuarios que interactúen con el artículo, y las envíe a un servidor web local que ejecutaremos en nuestro sistema.
Podemos observar que el payload XSS creara objeto Image, que viene a ser la etiqueta image, y aprovecharemos su atributo src para que el sistema destino realice una solicitud GET HTTP hacia mi servidor web local enviando la cookie de inicio de sesión cifrada del usuario, que ha interactuado con nuestro artículo, y va estar cifrada en base64.
Ahora antes de publicar el articulo con el payload XSS, debemos levantar el servidor web local en nuestro sistema.
Ahora si publicaremos nuestro artículo.
Podemos observar que hemos captura la primera cookie de inicio de sesión, y si la decodificamos, nos damos cuenta de que viene a nuestra cookie de inicie de sesión ya que nosotros hemos sido el primer usuario en interactuar con el artículo.
Ahora reportaremos el articulo para que el administrador de la aplicación web lo evalúe con el fin de capturar su cookie de inicio de sesión.
Podemos observar que logramos capturar la cookie de inicio de sesión del administrador.
Ahora cambiaremos nuestra cookie de sesión por la del administrador con el fin de omitir la autenticación que se requiere para acceder como administrador.
Podemos observar llegamos acceder al portal de la aplicación web como administrador. Ademas, podemos observar que el administrador tiene un panel para que pueda gestionar a los usuarios que se han registrado en la aplicación web. Ademas, podemos deducir que la aplicación web realiza consultas SQL hacia su servidor de base de datos utilizando el parametro GET user para obtener informacion sobre los usuarios registrados en la aplicación web de sus bases de datos.
Ahora intentaremos introducir el carácter “ en el parametro GET user para que nos genere un error, que provee el servidor de base de datos, en el caso de que la aplicación web presentara la vulnerabilidad SQLi basada en errores.
Podemos observar que la aplicación web si presenta la vulnerabilidad SQLi basada en errores.
Ahora calcularemos el numero de columnas, que tiene la tabla de la base de datos donde la aplicación web dirige su consulta SQL para mostrar la informacion que se observa en el panel del adminsitrador.
Podemos observar que el numero de columna, que tiene la tabla que la aplicación web va consultar, es 4.
Ahora enumeraremos la base de datos que administra y gestiona el DBMS en el servidor de base de datos de la aplicación web.
Podemos observar las bases de datos: informacion_schema, que se genera de manera predeterminada, y marketplace.
Ahora enumeraremos las tablas de la base de datos marketplace.
Podemos observar que las tablas de la base de datos marketplace son: messages, users, items.
Ahora enumeramores las columnas de la tabla messages.
Podemos observar que las columnas de la tabla messages son: User id, user_from, user_to, message_content, is_read.
Ahora volcaremos todos los registros de la columna message_content.
Podemos observar que los registros de la columna se muestra como una cadena de caracterers separados por comas. Donde podemos observar unas credenciales SSH en el primer registro de la columna. Estos nos da a suponer que el administrador de la aplicación web ha enviado un mensaje a un usuario local del sistema destino, que tambien se ha registrado en la aplicación web, para indicarle del cambio de sus credenciales SSH.
Ahora volcaremos todos los registros de la columna user_from. Para saber hacia que usuario ha enviado el mensaje el administrador.
Podemos observar que el primer registro de la columna user_from viene a ser 3, que hace referencia al valod del ID del usuario. Ademas, observando el panel de administracion de los usuarios registrados en la aplicación web, podemos saber que el ID 3 le corresponde al usuario jake.
Ahora intentaremos acceder al sistema destino con las credenciales del usuario jake y mediante el servicio SSH.
De esta manera obtenemos acceso al sistema objetivo siendo el usuario jake.
Ahora debemos buscar un vector de escalada de privilegios con el fin de ser un usuario con privilegios más elevados. Para ello enumeraremos los comandos y programas que puede ejecutar el usuario www-data con los privilegios de otros usuarios.
Podemos observar que el usuario jake puede ejecutar el script backup.sh con los privilegios del usuario michael sin la necesidad de proveer credenciales. Ademas, observamos que el primer comando del script, viene a ser imprimir un mensaje en pantalla. Luego, el segundo comando utiliza el comando tar con sus parametros -cf para crear un archivo tar y para especificar la ruta de su ubicacion y el nombre del archivo tar que se creara. Ademas, se utilizara el comodin para incluir todos los archivos y subdirectorios que haiga en el directorio actual.
Ahora crearemos los archivos -checkpoint=1 y -checkpoint-action=exec=sh reverse.sh en el directorio /opt/backups ya que gracias al comodin van a ser confundidos como parametros que se le pasan al comando tar. Por lo tanto, con el parametro -checkpoint=1, genero un punto de control despues de que un archivo del directorio actual sea archivado en el archivo backup.tar. Ademas, con el parametro -checkpoing-atcion especifico la accion que se tomara en cada punto de control. En este caso se ejecutara el script reverse.sh, que va generar una reverse shell con los privilegios del usuario michael.
Antes de ejecutar el script con el comando sudo y con los privilegios del usuario michael, tenemos que habilitar el puerto 1800 en nuestra sistema para que este en modo listening y esperando las conexiones entrantes.
De esta manera realizamos una escalada privilegios horizontal llegando a ser el usuario michael.
Ahora debemos buscar otro vector de escalada de privilegios para ser un usuario con privilegios mas elevados. Para ello aprovecharemos que el usuario michael pertenece al grupo secundario Docker. Por lo tanto, el usuario va a poder ejecutar y administrar contenedores Docker sin la necesidad de utilizar sudo e ingresar las credenciales del usuario root. Esto lo podemos comprobar ejecutando el siguiente comando para enumerar todos los contenedores Docker que se están ejecutando o que han sido ejecutados previamente en el sistema, incluidos los que están detenidos.
Aprovechando que podemos ejecutar contenedores Docker, utilizaremos el siguiente comando con el fin de iniciar un contenedor utilizando la imagen de Alpine Linux, y montando el sistema de archivos del sistema destino en el directorio /mnt del contenedor. Luego, cambiaremos el directorio raíz del contenedor a /mnt y ejecutaremos una shell interactiva dentro del contenedor con el fin de poder acceder a todos los archivos y directorios del sistema destino con los privilegios del usuario root.
De esta manera llegamos a ser el usuario root mediante una escalada de privilegios vertical.
Ahora buscaremos las dos banderas contenidas en los archivos root.txt y user.txt. Para localizar los archivos utilizaremos el comando find para buscar desde el directorio /, archivos con sus nombres.
