Cozyhosting
Publicado: 15 de Mayo de 2025 Autor: José Miguel Romero aKa x3m1Sec Dificultad: ⭐ Easy
📝 Descripción
CozyHosting es una máquina Linux que aloja una aplicación web de un servicio de hosting. La explotación comienza con la enumeración de servicios, donde encontramos un servidor web ejecutando una aplicación Spring Boot.
La máquina presenta múltiples vectores de ataque que incluyen:
Exposición de endpoints sensibles en la aplicación Spring Boot (/actuator)
Uso de sesiones inseguras que pueden ser manipuladas
Inyección de comandos en una funcionalidad de conexión SSH
Credenciales almacenadas en archivos de configuración
Escalada de privilegios mediante sudo mal configurado
El objetivo es obtener acceso inicial como usuario app mediante la inyección de comandos, pivotear al usuario josh usando credenciales encontradas en la base de datos PostgreSQL, y finalmente escalar a root abusando de permisos sudo para el binario SSH.
🔭 Reconocimiento
Ping para verificación en base a TTL
💡 Nota: El TTL cercano a 64 sugiere que probablemente sea una máquina Linux.
Escaneo de puertos
Enumeración de servicios
⚠️ Importante: Detectamos durante la fase de enumeración con nmap que se está realizando virtual hosting. Debemos añadir el siguiente vhost a nuestro fichero /etc/hosts
🌐 Enumeración Web
80 HTTP
http://cozyhosting.htb
Hay un panel de login que nos permite enumerar la tecnología del sitio web junto con la extensión wappalyzer:
🕷️Fuzzing de vhosts
No hallamos resultados.
Revisando el código fuente enumeramos el nombre de la template que se está usando y la versión de Bootstrap
Aunque no encontramos vulnerabilidades ni exploits para estas versiones
🕷️Fuzzing de directorios
Tras probar a realizar fuzzing de directorios con las herramientas gobuster y feroxbuster
Observamos un recurso /error que está devolviendo un error 500
Este error es generado por una aplicación Spring Boot, cuando ocurre un error no manejado y no hay una ruta /error personalizada definida.
Probamos a realizar fuzzint también con dirsearch y tenemos más suerte:
Ahora que sabemos que la aplicación está usando springboot, existe un endpoint que utiliza spring boot para exponer los endpoints que se llama /actuator:
http://cozyhosting.htb/actuator
En el endponint de sessions vemos lo que parece ser o bien una cookie. De hecho por cada intento de sesión no autenticado vemos como se refleja en el endpoint:
Optamos por la vía de pensar que pueda tratarse de una cookie y la seteamos:
Accedemos con éxito al panel de admin como usuario kanderson:
Al enumerar el servicio vemos lo que parece ser una utilidad para establecer conexión vía ssh:
Interceptamos la petición con burp y vemos la respuesta:
Aquí comenzamos a probar con posibles inyecciones de comandos para ver si el parámetro username es vulnerable.
Encontramos este payload que nos permite confirmarlo:
Con el carácter ";" permitimos escapar y ejecutar nuestro comando, usamos ${IFS} para que nos indique que el comando no puede contener espacios y finalmente cerramos con otro ";" y un hashtag # para que ignore todo lo que hay a continuación.
Si iniciamos un listener en nuestro host de ataque en el puerto 80
Y a continuación lanzamos la petición con la inyección de comandos, veremos que hay respuesta:
SI aplicamos esta PoC creando un archivo index.html con el siguiente contenido:
Lo disponibilizamos en un servidor web con python:
Probamos a realizar un curl a nuestra propia máquina par verificar que hay respuesta:
Iniciamos un listener en el puerto anteriormente especificado
Lanzamos la petición añadiendo el pipe "|" con bash para que se ejecute el contenido con bash:
Recibimos la reverse shell:
Foothold
Una vez dentro, vemos que existe un usuario josh en el directorio /home pero no tenemos permisos para enumerar nada aquí. Enumeramos la máquina en busca de vectores que permitan la escalada
Capabilities
Permisos
Grupos
Revisamos el fichero de configuración de nginx por si encontrásemos alguna credencial, vhost o algún recursos de utilidad:
Si revisamos el fichero /etc/passwd vemos que únicamente el usuario josh tiene login:
No hallamos nada relevante.
Sí encontramos un archivo .jar en el directorio /app que merece la pena analizar:
Lo copiamos al directorio /tmp ya que necesitamos descomprimirlo:
O también podemos transferirlo a nuestro host de ataque de la siguiente forma
Si optamos por esta segunda vía, podemos verificar la integridad de la transferencia usando md5sum en el origen y en el destino para ver si coinciden.
Una vez descomprimido el archivo podemos usar el comando tree para ver la estructura de archivos y ver algo interesante.
Tras enumerar el contenido encontramos un fichero application.properties con credenciales de una base de datos postgres:
Si revisamos los puertos /servicios que se están ejecutando localmente en la máquina vemos que efectivamente en el 5432 hay un postgres:
Podemos conectarnos con las credenciales encontradas de la siguiente forma
Una vez dentro enumeramos las tablas usando el comando \dt:
Y a continuación consultamos el contenido de la tabla users:
Procedemos a intentar crackear estos hashes usando hashcat y rockyou y tenemos éxito con el hash del usuario admin:
👑 Escalada de privilegios
No hay ningún usuario admin en el sistema, recordemos cuando hemos enumerado el directorio /home y el fichero /etc/passwd que únicamente había uno llamado josh, veamos si se está llevando a cabo la mala práctica de reutilización de contraseñas.
Buscamos ahora la escalada de privilegios a root desde el usuario josh y vemos que este usuario puede ejecutar el siguiente binario como root:
Buscamos información sobre este binario en gtfobins: https://gtfobins.github.io/gtfobins/ssh/#sudo
Y usamos el siguiente comando para la escalada y obtenemos la flag:
Last updated