HackPark - TryHackMe
SUMMARY
Debemos encontrar dos banderas en la maquina HackPark. Donde a partir del escaneo de puertos de Nmap pude saber que hay un servicio IIS, RDC. Además, gracias a sus scripts, logre saber que hay un sitio web tipo blog almacenado en el servidor web IIS, que fue creado por el CMS BlogEngine.NET. Luego, a través de la funcionalidad Recuperar Contraseñas del CMS pude obtener un username valido con el fin de realizar un ataque de fuerza bruta con Hydra sobre el login del CMS, logrando encontrar una credencial valida y acceder al portal de administración. Donde pude saber la versión del CMS y que presentaba la vulnerabilidad Directory Transversal (CVE-2019-6714). Luego, encontré un exploit, que logré analizar con el fin de recrear la explotación manualmente. Luego, para la escalada de privilegios vertical suplante un archivo ejecutable, que era como una tarea programada ejecutada de manera periódica y con los privilegios de un administrador.
FASE ESCANEO Y ENUMERACION
En este caso debemos acceder al sistema destino y obtener las banderas. 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áquina HackPark. 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 HackPark.
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 HackPark. 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 -Pn para evitar que Nmap, que realice ningún tipo de sondeo o ping hacia el sistema destino con el fin de determinar si el host está vivo o activo, y realice el escaneo de puertos directamente.
- 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:
-
Un programa servidor web Microsoft IIS levantado en el puerto 80, que va a permitir alojar páginas y aplicaciones web. Además, gracias al script http-robots.txt, se enumero los recursos que están prohibidos los motores de búsqueda mostrar en sus resultados. Además, gracias al script http-title, se logro capturar el valor de la etiqueta title de una página web alojada en el servidor web.
-
Un programa servidor RDP levantado en el puerto 3389, que va a permitir conectarme al sistema Windows remotamente y acceder a su escritorio y aplicaciones.
Ahora accederemos a las rutas de los recursos del archivo robots.txt.
- /search.aspx
Podemos observar que viene a ser una página web que forma parte de un sitio web, y que consta con la funcionalidad de realizar búsqueda. Para ello se ha implementado una función en Javascript que se ejecutara cuando presionemos enter sobre el campo de entrada o si presionamos el botón Search. Además, podemos observar que nuestra búsqueda se ve reflejada en la página web, esto nos da la idea de probar si el parámetro GET q es vulnerable a XSS.
Podemos observar que el parámetro GET q no es vulnerable a XSS ya que la página web está realizando una codificación de caracteres u operación de escape con el fin de que los navegadores web conviertan los conviertan los caracteres especiales como <,>, & en sus entidades HTML y evitar que se interpreten como código JavaScript.
Ahora, desglosaremos el código de la funcion JavaScript SearchPage con el fin de entender su lógica:
- Primero se selecciona el valor ingresado por el usuario en el campo q. Además, se realiza una codificación URL sobre su valor, y se almacena este valor codificado en la variable SearchTerm,
- Luego, se utiliza un operador ternario para expresar una condición sobre el valor de la variable check, que toma el valor de null debido a que no existe un elemento HTML con el id comment. Por lo tanto, el valor que se almacenara en la variable include es False.
- Luego, se almacenar un string en la variable comment.
- Luego, se asigna un valor en blanco a la variable comment a través de la condicional if cuya condición se cumplirá ya que la variable include tiene el valor de false.
- Luego, se asigna una cadena de caracteres (conformadas por los valores de las variables searchTerm, comment, y de la ruta /search?q=) hacia la variable url.
- Por último se utiliza el método localtion.href para redirigir a nuestro navegador web a la ruta especifica en el valor de la variable url
Podemos concluir que los valores que ingresamos en el campo de entrada de búsqueda de la pagina web no van a ser procesado por el servidor web si no que solamente el navegador web nos redirigirá la misma pagina web con ciertos cambios en la URL. Por lo tanto, el parámetro GET q no es dinámico, y va a ser en vano realizar un intento de SQLi sobre él.
Ahora accederemos a las demás páginas web a través de los elementos HTML <a>, que contienen enlaces hacia otras paginas web del sitio web.
Podemos observar que logramos acceder a la página web de presentación del sitio web que contiene dos posibles usernames: Visitor1 y ADMINISTRATOR. Además, accedimos a una página que consta de un formulario para acceder al portal de administración del CMS BlogEngine.NET que es utilizado para crear y gestionar blogs y sitios web del tipo blog sin requerir conocimientos avanzados de desarrollo web. Con esto podemos deducir que el sitio web ha sido creado a partir de este CMS. Además, podemos observar que el CMS consta de la funcionalidad Recuperar Contraseñas.
Ahora, utilizaremos la funcionalidad de Recuperar Contraseña del CMS para enumerar usernames válidos.
Podemos observar que logramos encontrar un username valido llamado admin.
FASE HACKING O GANAR ACCESO O EXPLOTACION
Ahora que hemos enumerado todos los recursos y solo hemos encontrado este username valido, nos queda realizar un ataque de fuerza bruta sobre el formulario o login del CMS. Para ello utilizaremos Hydra, pero antes realizaremos una captura de una solicitud POST realizada en la autenticación sobre este formulario con Burp Suite, con el fin de saber que parámetros están incluidos.
Podemos observar que la herramienta llego a encontrar una credencial valida.
Ahora nos autenticaremos al portal de administración del CMS.
Podemos observar que dentro del portal de administración del CMS, está la sección About que contiene los datos sobre la versión del CMS instalada que viene a ser la 3.3.6.0. Además, si buscamos información en Internet sobre vulnerabilidades relacionadas a la versión del CMS, nos encontramos con la vulnerabilidad Directory Transversal debido a que un parámetro GET theme, que es utilizado para especificar el theme para renderizar las páginas del blog, no es correctamente verificado lo que permite navegar por los directorios del sistema de archivos del sistema destino.
Además, nos mencionan que es posible cargar archivos al servidor web destino mediante la sección que nos permite editar el post. Aprovecharemos para subir un archivo ASP.NET malicioso que debe ser llamado PostView según el exploit, y que nos generara una reverse Shell cuando se ejecute.
Podemos observar que la ruta donde se almacena nuestro archivo ASP.NET es /App_Data/Files.
Ahora accederemos a nuestro archivo ASP.NET a través de la vulnerabilidad Directory Trasnversal que presenta el parámetro GET theme con el fin de que se ejecute el contenido de nuestro archivo y obtengamos la reverse Shell, pero antes habilitemos el puerto 1500.
Podemos observar que logramos acceder al sistema Windows.
FASE ESCALADA PRIVILEGIOS
Ahora debemos buscar un vector de escalada privilegios para ser un usuario con mayores privilegios. Para ello utilizaremos WinPeas con el fin de automatizar el proceso de búsqueda.
Podemos observar que la herramienta llego a encontrar que la ruta del archivo ejecutable del servicio WindowsScheduler tiene habilitado el permiso de escritura al grupo Everyone, es decir, cualquier puede modificar su archivo ejecutable. Por lo tanto, podemos suplantar el archivo ejecutable original del servicio por un archivo ejecutable malicioso, pero antes observaremos bajo que cuenta o usuario se ejecutara el archivo ejecutable del servicio.
Podemos observar que bajo la cuenta o usuario LocalSystem se ejecutara el archivo ejecutable del servicio, y viene a ser la cuenta con privilegios más elevados que un Administrador.
Ahora veremos si tenemos los permisos para reiniciar el servicio para ello utilizaremos la herramienta de línea de comando accesschk, que lo puedes descargar desde https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk.
Podemos observar que desafortunadamente no tenemos los permisos para reiniciar el servicio, solo el usuario LocalSystem o NT AUTHORITY\SYSTEM puede, pero si observamos el directorio donde se almacena su archivo ejecutable, nos toparemos con un archivo registro que contiene los registros de cuando se ejecuto un archivo ejecutable llamado Message.exe, y al parecer viene a ser como una tarea programa que se ejecuta de manera periódica con los privilegios del usuario Administrator.
Ahora enumeraremos los permisos habilitados en el archivo ejecutable Message.exe.
Podemos observar que tiene habilitado el permiso M al grupo Everyone, es decir, cualquiera puede modificar el archivo.
Ahora crearemos con msfvenom un archivo ejecutable que va a reemplazar al archivo ejecutable Message.exe, y que va a contener nuestro payload malicioso que nos generara una reverse Shell cuando se ejecute.
Ahora transferiremos nuestro archivo ejecutable malicioso hacia el sistema destino con el fin moverlo a la ruta C:\Program Files (x86) \SystemScheduler\s con el nombre de Advanced.exe. Además, le asignamos el privilegio F o Full Control al grupo Everyone, es decir, a todos los usuarios con el fin de que el sistema operativo pueda ejecutarlo siendo el usuario Administrator.
Ahora que hemos realizado la suplantación, habilitaremos el puerto 1800 en nuestro sistema para que este en modo listening y esperando la conexión entrante de la reverse Shell generado por la ejecución de nuestro archivo ejecutable malicioso.
Podemos observar que logramos acceder al sistema Windows destino siendo el usuario NT Authority \Sytem o LocalSystem.
Ahora buscaremos las dos banderas localizadas en los directorios Desktop de los usuarios Administrator y Jeff.
