That’s The Ticket - TryHackMe

December 08, 2023

SUMMARY

Debemos lograr autenticarnos en un login con las credenciales del administrador. Para ello primero me creo una cuenta mediante el registro de la aplicación, luego accedo al portal de gestión de la aplicación donde puedo crear un ticket. Además, en los tickets podría agregar un mensaje.Además, me di cuenta de que la aplicación web no realizaba una sanitización sobre el mensaje al momento de incrustarlo en su respuesta, por lo que intenté capturar las cookies de sesión del administrador y enviarlas a un dominio de mi control, pero se había implementado la flag HttpOnly.Además, me di cuenta de que había un firewall que filtraba las solicitudes realizadas hacia sistemas externos. Luego, utilizando una herramienta que registraba consultas DNS y solicitudes HTTP realizadas hacia cierto dominio, logre obtener el email del administrador a traves de una consulta DNS registrada y realizada por el navegador web del administrador debido a un payload XSS Stored ingresado en el mensaje del ticket.Luego, utilice Hydra para realizar un ataque de fuerza bruta de contraseña, logrando obtener la contraseña del administrador.

FASE RECONOCIMIENTO ACTIVO

En este caso lograr autenticarnos con las credenciales de un administrador de una aplicación web. Primero, empezaremos utilizando el comando openvpn y el archivo de configuración OpenVPN con el fin de establecer una conexión VPN y poder acceder a los laboratorios donde están las máquinas virtuales y vulnerables.

Además, la plataforma de Tryhackme nos muestra la dirección IP de la maquina.

FASE ESCANEO Y ENUMERACION

Ahora pasaremos a la fase de Escaneo y Enumeración con el fin de poder escanear los puertos del sistema destino. Además, obtendremos los servicios que se han levantado en los puertos abiertos, las versiones de los servicios, y el sistema operativo del sistema destino.

Los resultados que obtenemos son:

Un programa servidor SSH que se ejecuta en el puerto 22.
Un programa servidor HTTP que se ejecuta en el puerto 80. Ademas, podemos observar que hay una pagina web.

Ahora accederemos a la pagina web a traves de mi navegador web.

Podemos observar que se trata de una aplicación web que consta de un registro y login. Además, en la página de inicio de la aplicación web nos indica que podemos registrar tickets de soporte con soporte IT así que me imagino que un administrador de la aplicación web va a estar viendo nuestros tickets que registremos. Por lo que ya podemos ir pensando en utilizar la vulnerabilidad XSS Stored para robar las cookies de sesión del administrador que vaya a revisar nuestros tickets de soporte.

Ahora nos crearemos una cuenta mediante el registro con el fin de autenticarnos en el login y poder acceder al portal de gestión de la aplicación web.

Podemos observar que al momento de crear nuestro ticket en una parte de la pagina web sale nuestro correo electrónico por lo que testearemos si la aplicación web introduce el correo de nuestra cuenta en su respuesta HTTP de manera insegura, es decir, sin realizar una correcta sanitización. Además, debemos tener en cuenta que el correo de nuestra cuenta esta dentro de la etiqueta HTML label.

Ahora crearemos una cuenta con un correo electrónico que contenga nuestro payload XSS.

Desgraciadamente podemos observar que la aplicación web realiza una sanitización, eliminado los caracteres < y > de nuestro payload XSS introducido en el correo electrónico.

Ahora probaremos si el mensaje, que digitamos al momento de crear el Ticket, se introduce en la respuesta HTTP de la aplicación web de manera insegura. Además, debemos saber que el mensaje de nuestro Ticket esta dentro de la etiqueta HTML textarea. Ademas, crearemos un ticket con un mensaje que contenga nuestro payload XSS.

Podemos observar que si llego a ejecutarse nuestro payload XSS. Por lo tanto, la aplicación web introduce los mensajes en sus respuestas HTTP de manera insegura, es decir, sin una correcta verificación.

Ahora, suponiendo que nuestros tickets creados son vistos por un administrador de la aplicación web,ingresaremos un payload XSS en el mensaje con el fin de capturar sus cookies de sesión y reenviarlo a un servidor web que está bajo nuestro control.

Podemos observar que en nuestro servidor web llegamos a registrar una sola solicitud GET que fue realizada por nuestro navegador web cuando observamos nuestro ticket creado, pero no se llegó a capturar una solicitud GET realizada por el navegador web del administrador al momento de observar nuestro ticket. Además, en la solicitud GET capturada no se logro observar nuestro cookie de sesión otorgada por la aplicación web, y la razón del porque sucede esto radica en que el hecho de que la flag HttpOnly esta habilitada por lo que no podemos extraer la cookie utilizando document.cookie(Esto también lo podemos comprobar utilizando la herramienta Console integrada en nuestro navegador web).

Ahora debemos tener en cuenta el enunciado de la máquina.

Según el enunciado se ha implementado un firewall que posiblemente este bloqueando las solicitudes GET realizadas desde el sistema destino hacia otros sistemas externos. Esto puede ser una causa a que nuestro servidor web no haya registrado ninguna solicitud GET desde el sistema destino. Además, nos proveen de la URL de una herramienta que nos permite registra solicitudes HTTP y solicitudes DNS realizadas hacia el dominio d2535039011407078f4a02e073da9aa3.log.tryhackme.tech y cualquier subdominio.

Ahora, suponiendo que en el firewall se haya establecido una regla para evitar filtrar las solicitudes HTTP y consultas DNS realizadas hacia los dominios y subdominios mostradas en esta herramienta, ingresaremos un payload XSS en el mensaje del ticket para verificar si se registro una solicitud GET o consulta DNS realizadas por el navegador web de algún administrador de la aplicación web.

Podemos observar que la herramienta logro registrar una consultas DNS realizadas desde cierta direccione IP que puede estar asociada con el sistema desde donde el administrador de la aplicación web revise nuestro Ticket lo que género que su navegador web realice esa consulta DNS, peo solo se logro registrar la solicitud GET realizada por nuestro navegador web, por lo que se reafirma la suposición de que el firewall en el sistema destino anda bloqueando las solicitudes GET HTTP realizadas por los navegadores de los dos sistemas asociadas a esas dos nuevas direcciones IP.

Ahora teniendo en cuenta que no podemos capturar las cookies de sesión del administrador debido a la flag HttpOnly, intentaremos obtener el correo electrónico del administrador mediante las consultas DNS que se vayan a registrar. Para ello debemos tener en cuenta que en la parte superior a la derecha del portal de administración de la aplicación web, podemos observar nuestro correo electrónico. Además, podremos observar que el valor del correo viene a ser el texto de una etiqueta HTML span con el atributo id igual a email. Por lo tanto, el correo fácilmente lo podemos obtener con el siguiente comando JavaScript.

Ahora incluiremos este comando en nuestro payload XSS que ingresaremos en el mensaje de un Ticket con el fin de poder observar el correo electrónico del administrador en la solicitud GET que haga su navegador web cuando ejecute nuestro payload XSS. Además, aprovecharemos que se puede realizar solicitudes GET hacia cualquier subdominio del dominio principal indicado en la herramienta, para hacer que el navegador web del administrador realice una solicitud GET hacia un subdominio que va a tener el valor de su email.

Podemos observar que solo se registró una solicitud HTTP GET (realizada por nuestro navegador web) donde la cabecera Host (que viene a ser añadida por el navegador web para indicarle al servidor web que sitio web se quiere acceder) solo aparece una parte de nuestro email y al parecer el @ es el problema.

Ahora crearemos un payload XSS donde se modifique el @ en el valor del email.