Olympus - TryHackMe
SUMMARY
Debemos encontrar cuatro banderas en la maquina OlympusRoom. 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 un nombre de dominio de un sitio web en desarrollo, llegando acceder al sitio web asociando el dominio con la dirección IP del servidor web en el archivo /etc/hosts. Luego, realice fuerza bruta de directorios con Gobuster para encontrar recursos escondidos en el directorio raíz del sitio web. Luego, me encontré con la vulnerabilidad SQLi en el sitio web utilizando la herramienta sqlmap. Llegando a volcar todos los registros de las bases de datos Olympus, y encontrando los hahes de tres usuarios, llegando a crackear uno de ellos con John the Ripper. Además, me percate de un subdominio asociados a los emails de dos de los usuarios. Luego, asociando el subdominio con la dirección IP del servidor web en el archivo /etc/hosts, llegando a encontrar una aplicación web que era vulnerable a File Upload, permitiendo carga un archivo PHP que me genero una reverse Shell. Luego, para la escalada privilegios horizontal utilice un archivo binario SUID del usuario Zeus, llegando a obtener el contenido de la clave privada SSH del usuario, pero estaba cifrada. Por lo tanto, utilice John the Ripper para obtener la clave para descifrarlo, y llegando acceder al sistema destino mediante SSH. Luego, para la escalada privilegios vertical utilice un script PHP del usuario Zeus, que resulto ser un backdoor para acceder al sistema destino siendo el usuario root.
FASE RECONOCIMIENTO ACTIVO
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 OlympusRoom. 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 OlympusRoom.
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 OlympusRoom. 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. Además, podemos observar que el titulo de la pagina web contiene un nombre de dominio.
Ahora teniendo en cuenta que el nombre de dominio puede ser de una aplicación o sitio web que está en desarrollo, debemos saber que al introducir el nombre de dominio en la URL de nuestro navegador web, este no podrá obtener la dirección ip del servidor web a partir de sus consultas DNS hacia los servidores DNS recursivos públicos proveídos por nuestro ISP ya que los registros DNS de este nombre de dominio estarán almacenados en servidores DNS recursivos privados, que le pertenecen al sistema destino. Por ello vamos a tener que especificar el nombre de dominio asociado con la dirección IP del servidor web en el archivo /etc/hosts de nuestro sistema con el fin de que el navegador web evite estar realizando consultas DNS hacia los servidores DNS recursivos de nuestro ISP.
Ahora observaremos la aplicación o sitio web desde nuestro navegador web.
Podemos observar una pagina web que nos dice que el sitio web esta bajo desarrollo, y que su vieja versión aun esta accesible a través de este dominio. Con este ultimo mensaje, deducimos que debemos realizar una fuerza bruta de directorios con Gobuster con el fin de encontrar recursos escondidos en el directorio raíz del sitio web.
Podemos observar que llegamos a encontrar unos cuantos recursos escondidos como ~webmaster, index.php, cuyos códigos HTTP vienen a ser 200 y 301.
Ahora accederemos al recurso ~webmaster a través de mi navegador web.
Podemos observar que el sitio web ha sido creado a partir de un CMS o Sistema de Gestión de Contenido. Además, podemos observar que las etiquetas de anclaje de las secciones Technology, Tutorial, News, Business, Educations, y sus atributos href no contienen ningún enlace. Por lo tanto, si les damos clic a esas secciones no seremos redirigidos a ninguna parte. Además, la etiqueta de anclaje de la sección Register contiene un atributo que hace referencia a un recurso que al parecer ha sido removido del directorio raíz del sitio web, y lo mismo sucede con todos los posts publicados por el usuario root. Además, en la página web de inicio del sitio web nos encontramos con un formulario HTML o login, cuyos parámetros no son vulnerables a SQLi. Además, nos encontramos con una sección llamada Categories, que contienen varias etiquetas de anclaje, cuyos atributos href nos redirigen a diversos recursos que si se encuentran en el directorio raíz del sitio web.
FASE GANAR ACCESO O EXPLOTACION O HACKING
Ahora pondremos a prueba si el parámetro GET cat_id de estas categorías son vulnerables a SQLi ya que lo mas probable es que el sitio web las utilice para realizar sus consultas SQL hacia sus bases de datos con el fin de poder mostrarnos la información de cada Category.
De los resultados de sqlmap, podemos saber que el parámetro GET cat_id es vulnerable a SQLi Blind basada en booleano y en tiempo. Además, podemos observar el payload que utilizo la herramienta para enumerar las bases de datos gestionadas por el DBMS.
Ahora voy a volcar todos los registros de todas las tablas de la base de datos Olympus.
Podemos observar que la base de datos Olympus consta de 6 tablas. Además, la tabla flag contiene nuestra primera bandera. Además, en la tabla users, llegamos a encontrar las credenciales de los usuarios del sitio web. Donde sus contraseñas están en forma de hashes, y a simple vista el algoritmo hash que utiliza es bycrpt.
Ahora intentaremos crackear los hashes de las contraseñas de los usuarios con John the Ripper, aunque en el segundo post del usuario root, que viene a ser el administrador del sitio web, les da un aviso a los demás usuarios que mejoren la robustez de sus contraseñas ya que las ha crackeado fácilmente. Esperemos que no le hayan hecho caso.
Podemos observar que la herramienta solo llego a crackear el hash de la contraseña del usuario prometheus fácilmente. Al parecer el usuario Zeus si escucho las advertencias del usuario root.
Ahora intentaremos acceder al sistema destino mediante el servicio SSH y utilizando las credenciales del usuario prometheus, suponiendo que es un usuario local en el sistema destino y que ha reutilizado sus credenciales en diferentes servicios.
Podemos observar que no llegamos a tener éxito. Por lo tanto, algunas de nuestras suposiciones son incorrectas.
Ahora accederemos al portal de administración del sitio web siendo el usuario prometheus a través del formulario HTML o login y utilizando las credenciales del usuario prometheus.
Podemos observar que llegamos acceder al portal de administración del sitio web exitosamente.
Ahora probaremos si el sitio web es vulnerable a Command Injection. Para ello introduciremos un código PHP en el contenido del primer post publicado por el usuario root con el fin de actualizar el post y esperar que el servidor web lo ejecute y nos muestre el resultado cuando volvamos a visitar la página web de inicio del sitio web. Además, podemos cargar una imagen en el post, aprovecharemos esto para saber si el sitio es vulnerable a File Upload, intentando subir un archivo PHP, que contiene código para generara una reverse Shell.
Podemos observar en la página web de inicio del sitio web, que nuestro payload PHP no se ha interpretado como código PHP, y el motivo lo podemos observar en el código fuente de la página web de inicio del sitio web ya que las etiquetas < y > de nuestro código, se han convertido a las entidades HTML < con el fin de evitar que el servidor web lo interprete como código PHP y lo ejecute. Por lo tanto, no es vulnerable a Command Injection. Además, podemos observar el link hacia donde se almacenados nuestro archivo PHP, que subimos como imagen del post, pero no tenemos permiso para acceder al directorio img. Por lo tanto, no es vulnerable a File Upload.
Ahora probaremos si el sitio web es vulnerable a Command Injection a través de añadir una Categoría con un código PHP con el fin de esperar de que se ejecuta un comando en el sistema operativo del sistema destino. Podemos observar en las siguientes imágenes que obtenemos los mismos resultados que con los Posts.
Ahora podremos a prueba si el sitio web es vulnerable a File Upload atraves de la opción de subir archivos como imagen para nuestro perfil, pero si revisamos el código fuente, nos damos cuenta de que los archivos que subamos van a ser almacenados en el directorio img. Donde ya comprobamos anteriormente que no tenemos acceso para acceder a él.
Ahora si observamos la sección de Usuarios, nos encontramos que el email de los usuarios Root y Zeus están asociados a un nombre de dominio algo diferente que el de prometheus ya que se les ha añadido un subdominio como se observa en la siguiente imagen. Además, si recordamos los resultados los obtenidos por sqlmap, llegamos a observar una tabla llamada chat, que contiene mensajes de una conversación entre los usuarios Zeus yprometheus.
Ahora especificaremos el subdominio con su nombre de dominio principal asociada con la dirección IP del servidor web en nuestro archivo /etc/hosts con el fin de que cuando intentemos acceder a chat.olympus.thm a través de mi navegador web, este no realice una consulta DNS a servidores DNS recursivos proveídos por nuestro ISP.
Podemos observar que, al ingresar al recurso, nos encontramos con un formulario HTTP. Donde llegamos a autenticarnos exitosamente con las credenciales del usuario Prometheus. Luego, accedemos a una aplicación web parecida a WhatsApp web. Donde el usuario Prometheus y Zeus han estado charlando. Además, podemos observar que la aplicación web te permite subir archivos, y que todos los mensajes son guardados en la tabla Chat de la base de datos Olympus. Además, en la tabla chats también se almacena el nuevo nombre que tendrá el archivo, que subimos, debido a la función que implemento la aplicación web.
Ahora probaremos si el aplicativo web es vulnerable a File Upload. Para ello probaremos si la aplicación web me permite subir un archivo PHP. Luego, volveremos a volcar los registros actualizados de la tabla chats con el fin de saber el nombre que ha tomado el archivo debido a la función, que ha configurado el desarrollador de la aplicación web.
Podemos observar que el nombre, que ha tomado mi archivo PHP que subimos anteriormente, es fbadf11195df9a32a98268bcce02c573.php.
Ahora realizaremos fuerza bruta de directorios sobre el directorio raíz de la aplicación web con el fin de saber el directorio donde se ha almacenado mi archivo PHP. Para ello utilizaremos la herramienta Gobuster.
Podemos observar que llegamos a encontrar un recurso, cuyo nombre hace referencia a uploads. Por lo tanto, debe ser el directorio donde se almacenan los archivos cargados en el aplicativo web.
Ahora accederemos al recurso uploads, y daremos clic a nuestro archivo PHP con el fin de que el servidor web ejecute su contenido lo que nos generara una reverse Shell.
Podemos observar que llegamos obtener acceso al sistema destino siendo el usuario www-data.
Además, podemos observar que al usuario www-data se le ha configurado para que utilice la Shell nologin cuando inicie sesión en el sistema destino. Esta Shell viene a ser no interactiva e inestable. Por lo tanto, realizaremos un tratamiento de la tty para tener una Shell estable e interactiva.
FASE ESCALADA PRIVILEGIOS
Ahora debemos buscar un vector de escalada de privilegios con el fin de ser un usuario con privilegios más elevados. Para ello utilizaremos la herramienta linpeas, que nos automatizara el proceso de buscar vectores de escala de privilegios en el sistema destino. Esta herramienta lo puedes descargar en el siguiente enlace: https://github.com/carlospolop/PEASS-ng/releases/tag/20230413-7f846812.
Podemos observar que la herramienta llego a encontrar un archivo binario ejecutable con el permiso SUID, y cuyo propietario es el usuario Zeus.
Ahora analizaremos su funcionamiento de este archivo binario ejecutable Para ello utilizaremos el comando strings con el fin de extraer los caracteres legibles para el ser humano del código fuente del archivo binario. Ademas, ejecutaremo el archivo binario en modo de deducir posibles comandos que ejecuta en segundo plano.
Podemos observar que el archivo binario ejecutable viene a trabajar de manera similar que el comando copy o cp. Por lo que podemos copiar archivos con los privilegios del usuario Zeus.
Ahora buscaremos un archivo importante del directorio home del usuario local Zeus con el fin de copiarlo a un archivo que podamos nosotros leer.
Podemos observar que al listar el directorio home del usuario Zeus, nos encontramos con la segunda bandera. Además, encontramos el directorio oculto ssh, que es utilizado para almacenar las claves privadas y publicas SSH, que viene a ser una manera de autenticarse mediante el servicio SSH en ves de proveer de credenciales. Por esta razón, utilizaremos el archivo binario ejecutable para copiar el contenido de la clave privada SSH a un archivo con el fin de observar su contenido y utilizarlos para autenticarnos al sistema destino mediante el uso de la clave privada SSH.
Ahora copiaremos el contenido de la clave privada a un archivo de nuestro sistema, y le asignaremos el permiso 600 con el fin de evitar que problemas durante la autenticación con el servicio SSH en el sistema destino.
Podemos observar que nos piden una clave para la clave privada. Por lo tanto, el contenido de la clave privada esta cifrada y necesitamos la clave para descifrarla. Para poder obtener la clave utilizaremos John the Ripper con el fin de crackear la clave.
Podemos observar que la herramienta llego a encontrar la clave.
Ahora nos autenticaremos al servicio SSH mediante la clave privada cifrada con el fin de ser el usuario Zeus.
Ahora debemos buscar un vector de escalada de privilegios con el fin de ser un usuario con privilegios más elevados. Para ello realizaremos una enumeración manual sobre los archivos, cuyos propietarios pertenecen al grupo primario del usuario local Zeus.
Podemos observar que llegamos a encontrar la segunda bandera en el archivo user.flag. Además, encontramos un script PHP, que en el caso de ejecutarlo nos generaría lo siguiente:
- Primero nos generaría un formulario HTML, que va a constar de un solo parámetro llamado password, y debemos ingresarle el valor de la variable pass, que se define en el mismo código del script., con el fin de que se siga ejecutando el código restante del script.
- Luego de autenticarnos exitosamente, se utiliza la matriz superglobal
$_SERVER [HTTP_HOST para extraer el valor del encabezado Host de la solicitud HTTTP que realizamos, y se utiliza la matriz superglobal $_SERVER[REQUEST_URI]
con el fin de obtener todos los componentes restantes que le pueden seguir al nombre de dominio o dirección IP del servidor web en la ruta de la URL. Además, se utilizará la función htmlspecialchars para concatenar estos dos valores y pasarle un filtro con el fin de convertir caracteres especiales y potencialmente peligrosos en sus entidades HTMlL y de esa manera evitar que se ejecuten. - Luego, se genera varios elementos HTML. Donde el primer elemento viene a ser un encabezado de nivel 2 que va a mostrar el mensaje snodew reverse root Shell backdoor. El segundo elemento viene a ser un encabezado de nivel 3 que va a mostrar instrucciones de cómo usar el backoor. Donde primero, tenemos que habilitar un puerto en nuestro sistema para que este en escucha. Luego, debemos digitar la ruta que nos especifica en la URL, indicando los parámetros ip y port.
- Luego, se ejecutarán dos comandos: uname -a, con el fin de obtener información sobre el kernel y el sistema operativo del sistema destino, y un archivo, cuya ruta esta especifica en el código del script.
Ahora que hemos analizado el código fuente de este script, podemos deducir que se trata de un backdoor para obtener acceso al sistema destino teniendo los privilegios del usuario root. Además, levantaremos un servidor web local con el interprete PHP del sistema destino en el directorio donde esta el script PHP con el fin de ejecutar el script PHP, y llegar a ser el usuario root.
De esta manera llegamos a ser el usuario root en el sistema destino.
Ahora buscaremos la tercera bandera en el directorio root.
Podemos observar el contenido de la tercera bandera.
Ahora buscaremos la ultima bandera, para ello nos dan dos pitas: Esta en el directorio /etc del sistema destino, y comienza con flag. Para ello utilizaremos el comando grep con algunos patrones de búsqueda.