Guardian WriteUp Hack The Box
Introducción
La máquina Guardian es posiblemente la más difícil y extensa que he resuelto hasta la fecha.
Esta máquina está compuesta por vulnerabilidades que involucran usuarios con credenciales por defecto, inyección de parámetros en la URL y varios ataques XSS para obtener cookies. Explotaremos tokens CSRF para crear usuarios con privilegios de administrador y así escalar nuestros privilegios. Una vez que tengamos acceso como administradores del sitio web, utilizaremos una vulnerabilidad de Local File Inclusion para establecer una conexión remota, acceder a la máquina como el usuario www-data, encontrar las credenciales de jamil en una base de datos y crackearlas utilizando una sal que acompaña a los hashes.
Una vez dentro de la máquina como jamil, encontraremos aplicaciones mal configuradas que nos permitirán escalar privilegios al usuario mark. Con este usuario, observaremos que puede ejecutar como administrador la herramienta safeapachectl. Finalmente, crearemos un módulo de configuración que nos permitirá establecer una conexión remota como el usuario root y obtendremos la flag final.
Enumeración
Comenzamos enumerando los puertos abiertos de la máquina. En este caso, tiene abierto el puerto 22, que no podremos atacar de inmediato porque no tenemos usuarios, y no merece la pena gastar tiempo realizando ataques de fuerza bruta. Además, tenemos el puerto 80; por lo tanto, debemos añadir la IP de la máquina y el dominio a nuestro archivo /etc/hosts para acceder a la web.
Al acceder al puerto 80 con el navegador, veremos una página de bienvenida sobre Guardian University.
Si investigamos un poco la web, encontraremos mensajes sobre estudiantes, donde podremos anotar posibles usuarios y cuentas para realizar ataques de fuerza bruta.
Si pulsamos en el botón “student portal” en la página principal, este nos redirige a portal.guardian.htb, por lo que debemos añadirlo a /etc/hosts. En este inicio de sesión, aparece una ventana emergente que nos indica que consultemos la guía del portal.
Si hacemos clic en el enlace de la ventana emergente antes de que desaparezca, veremos una guía sobre cómo usar el portal. Al parecer, a los estudiantes se les asigna una contraseña por defecto al crear una cuenta.
Utilizando los usuarios que encontramos al principio, descubrimos que el usuario GU0142023 no ha modificado su contraseña todavía, lo que nos permite acceder a su cuenta.
Una vez dentro de la plataforma, veremos distintas secciones como “My Courses”, “Assignments”, “Grades”, etc.
Si navegamos un poco por la sección de “Chat”, notaremos que tiene una URL algo extraña. Podemos realizar ataques de fuerza bruta y probar combinaciones para encontrar conversaciones a las que no deberíamos tener acceso.
Después de un rato de prueba y error, encontraremos una conversación entre jamil y el usuario admin. En esta conversación, el usuario admin le proporciona la contraseña en texto plano de la plataforma Gitea. Esto nos permitirá investigar y aprender cómo funciona la aplicación web.
Si accedemos al subdominio de Gitea e iniciamos sesión con las credenciales de jamil que obtuvimos anteriormente, veremos que existen dos repositorios: portal.guardian.htb y guardian.htb.
Investigando, encontraremos que dentro del repositorio portal.guardian.htb existe un archivo de configuración llamado config.php, donde veremos las credenciales de la base de datos, que pueden ser útiles para seguir escalando.
Cuando te encuentres en situaciones donde no sabes cómo continuar, lo primero que debes preguntarte es: “¿Qué aplicaciones y versiones están corriendo?”. Al buscar por aplicaciones, encontraremos phpoffice con una versión vulnerable.
Explotación
Una vez enumerado todo lo que podamos sobre la aplicación que queremos vulnerar, debemos investigar las vulnerabilidades de las aplicaciones que hemos encontrado. En este caso, podemos ver en el siguiente GitHub que la versión que se está utilizando es vulnerable a XSS en la función generateNavigation().
Como se muestra en la prueba de concepto, tendremos que generar un archivo .xlsx e introducir un payload XSS en la segunda pestaña del documento. En mi caso, utilizaré una web como Treegrid para generarlo.
Nota: He probado con distintas herramientas para crear archivos .xlsx, como Microsoft Office, Google Sheets o Calc de LibreOffice, pero no ha funcionado. Si alguien sabe por qué, por favor escríbelo en la sección de comentarios de la publicación de LinkedIn.
Una vez introducido el payload, abriremos nuestro servidor con Python para recibir las peticiones con la cookie del usuario que abra el archivo que hemos creado anteriormente.
Finalmente, solo queda enviar el archivo y esperar a que alguien lo abra.
Después de un rato, recibiremos la cookie del usuario que ha abierto el archivo.
Ahora podremos modificar nuestra cookie en el navegador y acceder al panel de “Lecturer”.
Tenemos nuevas secciones que investigar, como “Notice Board” y “Submissions”. Si examinamos detenidamente la sección de “Notice Board”, podemos ver qué tipo de peticiones utiliza este sitio.
Con la herramienta Burp Suite, podemos interceptar la petición de “Create Notice” para ver qué parámetros requiere la web. Probemos a crear una noticia indicando el título, el contenido y un enlace de referencia para que lo revise el usuario admin. Para este último apartado, abriré un servidor HTTP con Python para ver si realmente algún usuario abre el archivo.
Con Burp Suite, interceptaremos la petición para ver qué parámetros son necesarios para crear una noticia. Como se puede ver en la imagen, lo más importante que necesitaremos es un token CSRF.
Continuando con la petición, después de un rato, un usuario abre el archivo .txt que he dejado expuesto.
Volvamos a Gitea y entendamos cómo funcionan estos parámetros. En el archivo csrf-token.php, descubriremos que los tokens se guardan en el directorio /config/tokens.json.
Además, podemos ver cómo crear un usuario. Necesitamos investigar cómo funciona, ya que el usuario admin va a abrir nuestro archivo. Podemos crear un formulario para que el usuario admin lo ejecute y así escalar privilegios.
Comencemos creando el formulario que pulsará el usuario. Necesitaremos indicar a dónde apunta (en este caso, a createuser.php), el token CSRF que generaremos después, todos los parámetros que hemos visto antes y un script para que, al abrir el archivo, se ejecute el formulario.
Generaremos un token CSRF enviando una petición para crear una noticia.
En el directorio que hemos visto antes, se generarán los tokens.
Añadimos nuestro token CSRF a nuestro archivo .html y abrimos nuestro servidor HTTP.
Finalmente, crearemos la noticia enviándola con Burp Suite y esperaremos a que el usuario admin abra el formulario.
Como se ve en la imagen, el usuario admin ha accedido a nuestro archivo HTML. Ahora queda ver si el usuario que hemos especificado en el formulario se ha creado correctamente.
¡Lo hemos conseguido! Hemos escalado hasta el usuario admin, y ya queda menos para acceder a la máquina.
Accedemos al apartado de “Reports”, ya que es la sección que no tiene ningún usuario anterior. En este apartado, podemos ver un potencial Local File Inclusion en la URL.
Si miramos el código fuente, podemos confirmar que existe la vulnerabilidad.
Utilizando esta herramienta, podemos generar un payload que nos permita explotar la Local File Inclusion y, además, generar una reverse shell. Primero, modifiquemos el código para que utilice uno de los archivos de la web.
Probamos a generar un payload que cargue código; en este caso, que muestre la información de PHP que tenga instalada.
Si copiamos y pegamos todo el payload, comprobaremos que existe la vulnerabilidad, ya que muestra el panel de información de PHP.
Probemos con la conexión remota. Como sabemos que tiene PHP, intentemos crear una conexión remota utilizando PHP.
Activamos nuestro netcat y pegamos el payload en la URL. Así es como hemos logrado conectarnos a la máquina.
¿Recuerdas cuando encontramos las credenciales de la base de datos en el código?
El usuario www-data puede acceder a la base de datos, así que nosotros también.
Si copiamos los hashes e intentamos crackearlos, no lo conseguiremos, ya que, como se puede ver en el código fuente, los hashes tienen una sal que debemos tener en cuenta al crackearlos. Para hacerlo con la herramienta Hashcat, tendremos que añadir la sal de la siguiente forma.
Después de unos 2 minutos, obtendremos las contraseñas en texto plano de admin y jamil.
Si probamos a iniciar sesión en el SSH con ellas, descubriremos que jamil sí puede acceder al SSH. Finalmente, hemos llegado a la primera mitad de la máquina.
Con esto, hemos completado una parte significativa del proceso de explotación de la máquina Guardian. Ahora, con acceso a jamil, podemos continuar explorando y buscando nuevas vulnerabilidades para escalar aún más nuestros privilegios y, eventualmente, obtener acceso completo a la máquina.
Escalada de privilegios
Bien, hemos llegado a la máquina; solo queda alcanzar el acceso como root. Comenzamos, como siempre, enumerando qué puede hacer este usuario con privilegios. En este caso, jamil solo puede ejecutar el código utilities.py con el usuario mark.
Analicemos qué puede hacer este código. Parece que sirve para ejecutar comandos dentro de la máquina de forma automática, como hacer backups, comprimir archivos o comprobar el estado de procesos. Algo importante a tener en cuenta es que el usuario jamil solo puede ejecutar el parámetro system-status.
El código anterior ejecuta otros scripts dentro de la carpeta /utils. El usuario jamil solo puede ejecutar el parámetro system-status; como se puede ver en la imagen, no podemos editar ninguno de estos scripts, excepto el de status.py.
Probemos a crear una conexión remota para conectarnos como el usuario mark. Primero, encriptaremos la conexión remota con base64.
Después, modificaremos el código completo para añadir el payload, prepararemos nuestro netcat para recibir la conexión y, finalmente, lo ejecutaremos como mark.
Ahora estamos como el usuario mark. Veamos qué puede ejecutar con permisos de administrador. Puede ejecutar la herramienta safeapache2ctl, que permite cargar configuraciones en la máquina.
Si probamos a ejecutarla, veremos que nos pide un archivo de configuración desde la carpeta /confs/. En esa carpeta, podemos crear cualquier archivo de configuración.
Si investigamos un poco, al crear un archivo de configuración que cargue un módulo y, si da error, que ejecute una conexión remota, podemos aprovechar esto.
Ejecutamos la aplicación con el archivo de configuración malicioso y, finalmente, hemos escalado hasta el usuario root, completando así la máquina.
Conclusión
La máquina Guardian fue una experiencia realmente interesante que me ayudó a entender mejor cómo se pueden explotar vulnerabilidades y escalar privilegios. Desde el recorrido inicial por los puertos y servicios hasta la explotación de vulnerabilidades como XSS y Inclusion de Archivos Locales, cada paso fue clave para avanzar en el proceso.
La escalada de privilegios, comenzando con el usuario jamil y llegando hasta root, nos permitieron conocer bien las herramientas y scripts disponibles en el sistema. Poder modificar y ejecutar código en un entorno controlado nos permitió establecer conexiones remotas y aprovechar configuraciones que estaban mal protegidas.
Quiero agradecer a echoesofwhoami y a compañeros que me han ayudado a completar esta máquina.
Espero que esta publicación sirva como una guía para esta máquina tan compleja.