> For the complete documentation index, see [llms.txt](https://4lec4st.gitbook.io/4lec4st/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://4lec4st.gitbook.io/4lec4st/writes-ups/hack-the-box/easy/titanic.md).

# Titanic

## Información de la máquina

<figure><img src="/files/BwEAnAhJGXUeIWMvTxqz" alt=""><figcaption></figcaption></figure>

Titanic es una máquina Linux de dificultad fácil que cuenta con un servidor Apache que escucha en el puerto 80. El sitio web en el puerto 80 anuncia las comodidades del legendario Titanic y permite a los usuarios reservar viajes. Tras realizar pruebas de fuzzing, se identifica un segundo vHost que apunta a un servidor `Gitea`. El servidor Gitea permite registros, y la exploración de los repositorios disponibles revela información interesante, como la ubicación de una carpeta de datos `Gitea` montada, que se ejecuta mediante un contenedor Docker. Volviendo al sitio web original, se descubre que la función de reservas es vulnerable a un exploit de lectura arbitraria de archivos, y al combinar el directorio identificado de Gitea, es posible descargar la base de datos SQLite de Gitea localmente. Dicha base de datos contiene credenciales hash para el usuario `developer`, que pueden descifrarse. Las credenciales pueden usarse para iniciar sesión en el sistema remoto mediante SSH. La enumeración del sistema de archivos revela que un script en el directorio `/opt/scripts` se ejecuta cada minuto. Este script ejecuta el binario `magick` para recopilar información sobre imágenes específicas. Esta versión de `magick` es vulnerable a un exploit de ejecución de código arbitrario asignado [CVE-2024-41817](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-41817). La explotación exitosa de esta vulnerabilidad resulta en la elevación de privilegios al usuario `root`.

***

## Reconocimiento

La fase de **reconocimiento** es el primer paso a la hora de resolver una máquina. Su objetivo es recopilar la mayor cantidad de información posible sobre el sistema objetivo, permitiendo entender su estructura, tecnología y posibles vectores de ataque.&#x20;

Empezaremos haciendo un ping a la máquina víctima para ver si está encendida y ante que nos enfrentamos.

<figure><img src="/files/yICkXgQhRy68XmVt3Ta5" alt=""><figcaption></figcaption></figure>

Si recibimos respuesta, significa que la máquina está en línea. Además, observamos que el **TTL** (Time To Live) es **63**, lo que indica que es un sistema **Linux** (normalmente, los sistemas Windows tienen un TTL de 127).&#x20;

{% hint style="success" %}
Esto sucede porque Hack The Box virtualiza las máquinas, lo que a menudo reduce el TTL en un punto respecto al valor estándar.

En entornos reales tendrían los siguientes valores:

TTL Linux **→** 64

TTL Windows **→** 128
{% endhint %}

Empezaremos haciendo un primer reconocimiento para ver los puertos abiertos en el sistema.

<figure><img src="/files/izKD9m9wLR1DhgFbQWCL" alt=""><figcaption></figcaption></figure>

**1. `-p-` → Escaneo de todos los puertos (1-65535)**

Por defecto, `nmap` solo escanea los **1000 puertos más comunes**.\
Con `-p-`, forzamos a que escanee **los 65535 puertos** de la máquina objetivo, lo que puede ser útil para encontrar servicios que corren en puertos poco convencionales.

**2. `--open` → Filtrar solo los puertos abiertos**

Cuando escaneamos un sistema, muchos puertos pueden estar cerrados o filtrados por un firewall.\
Este parámetro hace que `nmap` **solo muestre los puertos abiertos**, reduciendo el ruido y facilitando el análisis.

**3. `-sS` → Stealth Scan (Escaneo Sigiloso con SYN)**

Es conocido como **"TCP SYN Scan"**, y funciona de la siguiente manera:

* `nmap` envía un paquete **SYN** (solicitud de conexión).
* &#x20;Si el puerto está abierto, el servidor responde con **SYN-ACK**.
* En lugar de completar la conexión con un **ACK**, `nmap` responde con un **RST (Reset)**, interrumpiendo la comunicación.

**4. `--min-rate 5000` → Velocidad mínima de paquetes (5000 por segundo)**

Por defecto, `nmap` ajusta dinámicamente la velocidad de los paquetes según la respuesta de la red.\
Con `--min-rate 5000`, obligamos a `nmap` a **no enviar menos de 5000 paquetes por segundo**, acelerando el escaneo.

**5. `-n` → Deshabilitar resolución DNS**

Normalmente, `nmap` intenta resolver el nombre de dominio de las IPs escaneadas (DNS lookup).\
Con `-n`, evitamos esta resolución de nombres, lo que **acelera el escaneo** y evita que los servidores DNS registren nuestra actividad.

**6. `-Pn` → Omitir detección de host (Host Discovery Off)**

Por defecto, `nmap` envía paquetes ICMP (ping) para ver si un host está activo antes de escanearlo.\
Si un firewall bloquea los pings, `nmap` puede marcarlo como "host down" y no escanearlo.

**7. `-oG`** **→ Exportar el contenido en formato grepeable**

Todo el resultado del escaneo lo exportaremos en un archivo llamado **`puertos` .**

El escaneo revela 2 puertos abiertos, puerto 22(SSH) y puerto 80(HTTP). Ahora realizamos un escaneo más avanzado sobre estos 2 puertos

<figure><img src="/files/oQWpP1QrQ5EzKQeTkF5q" alt=""><figcaption></figcaption></figure>

**1. `-p22,80` → Escaneo de puertos específicos**

Con `-p22,80`, le indicamos que **solo** escanee los puertos **22 (SSH)** y **80 (HTTP)**

**2. `-sCV` → Escaneo de versiones y scripts básicos**

Este parámetro en realidad es **dos combinaciones en una**:

* **`-sC`** → Activa los **NSE scripts por defecto** en `nmap` (similar a usar `--script=default`).\
  Ejecuta scripts básicos para enumerar información del servicio detectado, como banners, versiones, etc.
* **`-sV`** → Realiza **fingerprinting de versiones**, intentando identificar la versión exacta del software en cada puerto abierto.

**3. `-oN` → Guardar el resultado en formato Normal**

Por defecto, `nmap` muestra los resultados en pantalla, pero con **`-oN targeted`**, guardamos el resultado en un archivo en **formato legible para humanos**.

Cambiaremos el /etc/host ya que se aplica una redirección al dominio `titanic.htb` .

<figure><img src="/files/qunqDKldNbQVoIcJDIxt" alt=""><figcaption></figcaption></figure>

## Finding Subdomains

Utilizamos `ffuf` con una lista de posibles subdominios para descubrir subdominios válidos del dominio principal; entre los resultados, identificamos `dev.titanic.htb` como accesible.

<figure><img src="/files/p74dhfzTD3QbTHbYFDGK" alt=""><figcaption></figcaption></figure>

Para que nuestro sistema pueda resolver el subdominio `dev.titanic.htb` correctamente, lo añadimos manualmente al archivo `/etc/hosts`, asociándolo con la IP de la máquina objetivo.

<figure><img src="/files/DYzo9Yo4ZjNM7wKAjTJU" alt=""><figcaption></figcaption></figure>

En la web principal, se ofrece una funcionalidad para reservar vuelos. Interceptamos la petición de reserva usando Burp Suite para analizar los parámetros enviados y la estructura de la solicitud.

<figure><img src="/files/i1xgg5DKTdAKyz6DbU0i" alt=""><figcaption></figcaption></figure>

La primera petición HTTP contiene todos los datos ingresados por el usuario, como nombre, vuelo y otros detalles, que luego se procesan por el servidor.

<figure><img src="/files/BIiwyc14na6Ex6KwsUkq" alt=""><figcaption></figcaption></figure>

Después de enviar la reserva, la aplicación realiza una solicitud al endpoint `/download`, que devuelve un archivo JSON con la información del billete generado.

<figure><img src="/files/ujFftN7zBbrvpuSiV72G" alt=""><figcaption></figcaption></figure>

## File Read

Si replicamos la petición al endpoint `/download` en el Repeater de Burp y modificamos el parámetro `ticket` por una ruta arbitraria como `/etc/hosts`, el servidor devuelve el contenido de ese archivo, lo que indica una vulnerabilidad de *Local File Read (LFR)*.

<figure><img src="/files/Toc0Cyxjj0swux8WPU9b" alt=""><figcaption></figcaption></figure>

Gracias a esta LFR, accedemos a archivos del sistema, incluyendo información sobre el usuario `developer`, lo que nos permite localizar y leer la primera flag (por ejemplo, `/home/developer/user.txt`).

<figure><img src="/files/S7SpKeU4LklRToRUjSHl" alt=""><figcaption></figcaption></figure>

Navegando por el subdominio `dev.titanic.htb`, descubrimos que hay una instancia de Gitea (una plataforma de control de versiones similar a GitHub) corriendo, accesible desde una ruta específica.

<figure><img src="/files/gXrN7l9ZA1VBn9efuT5i" alt=""><figcaption></figcaption></figure>

## Obtain gitea.db

Accedemos al archivo de configuración por defecto de Gitea (`/home/developer/gitea/custom/conf/app.ini`) mediante la vulnerabilidad de lectura de archivos. En este archivo encontramos la ruta a la base de datos de Gitea (`/home/developer/gitea/data/gitea/gitea.db`), que almacena información crítica como credenciales de usuarios.

<figure><img src="/files/vZg0wt1e9jAjera0ZfS9" alt=""><figcaption></figcaption></figure>

Al leer la base de datos `gitea.db` con la misma técnica, confirmamos que contiene datos válidos y potencialmente sensibles.

<figure><img src="/files/8DqEObClLvNLIxA5CHzL" alt=""><figcaption></figcaption></figure>

Descargamos la base de datos completa utilizando `curl` y apuntando el parámetro `ticket` al path del archivo de la base de datos, almacenando el resultado en disco con `-o`.

```
curl 'http://titanic.htb/download?ticket=/home/developer/gitea/data/gitea/gitea.db' -o gitea.db
```

## Make hash cracked by Hashcat

Usamos `sqlite3` para inspeccionar el contenido de la base de datos descargada. Con el comando `.tables` listamos todas las tablas disponibles.

<figure><img src="/files/B5vwp7DUP9kHhRlYk9jb" alt=""><figcaption></figcaption></figure>

Ejecutamos `SELECT * FROM user;` para ver los registros de usuarios, donde encontramos información como nombres de usuario, correos y hashes de contraseñas.

<figure><img src="/files/ALUqyg3c7C0nHHDLBDXV" alt=""><figcaption></figcaption></figure>

Algunos campos no contienen directamente hashes crackeables, por lo que consultamos la documentación de Gitea para entender cómo están generados. Esto nos permite reproducir el formato de hash para facilitar el ataque por diccionario.

{% embed url="<https://hashcat.net/wiki/doku.php?id=example_hashes>" %}

Ejecutamos un `one-liner` para extraer y formatear los hashes correctamente, asegurándonos de que estén listos para ser procesados por herramientas de cracking como Hashcat.

<figure><img src="/files/hKJiDzcKpfSeXzFhM35F" alt=""><figcaption></figcaption></figure>

Con los hashes extraídos, usamos `hashcat` especificando el tipo correcto (por ejemplo, bcrypt) junto con un diccionario de contraseñas para intentar descifrarlos.

<figure><img src="/files/0JOi5aKiknCLowwqOd4L" alt=""><figcaption></figcaption></figure>

Tras un tiempo de procesamiento, `hashcat` logra romper el hash, revelando la contraseña del usuario `developer`: `25282528`.

## Initial Access user Developer

Utilizando la contraseña recuperada, accedemos al sistema mediante SSH como el usuario `developer`

<figure><img src="/files/kQ3mvEKUNcWVy9itQm61" alt=""><figcaption></figcaption></figure>

Si no lo hicimos antes, ahora podemos acceder al archivo `user.txt` en el directorio `/home/developer` y obtener la flag de usuario.

<figure><img src="/files/x1gXM5eFFqGO478DN3HY" alt=""><figcaption></figcaption></figure>

## Privilege Escalation - CVE-2024-41817

Durante la enumeración local, descubrimos un script llamado `identify_images.sh`, ubicado posiblemente en una ruta como `/opt/` o `/home/developer/scripts/`, el cual parece ser ejecutado automáticamente por el sistema.

<figure><img src="/files/foXSpU2CfjE9l9rfKWMV" alt=""><figcaption></figcaption></figure>

El archivo `metadata.log` muestra un historial de procesamiento de imágenes, lo cual indica que el script mencionado interactúa con este archivo. Además, tenemos permisos de escritura sobre él, lo que podría permitirnos manipular su contenido.

<figure><img src="/files/RWMU1143SDSKXmzEply9" alt=""><figcaption></figcaption></figure>

El script utiliza `magick`, el binario principal de ImageMagick, una suite para procesado de imágenes que ha tenido varias vulnerabilidades en el pasado. Verificamos la versión instalada para comprobar si es vulnerable al CVE-2024-41817 (RCE vía metadatos).

<figure><img src="/files/ay6I1hFF14FSl1TRNT9S" alt=""><figcaption></figcaption></figure>

Confirmamos que la versión instalada es vulnerable. Podemos inyectar comandos en los metadatos de una imagen o archivo manipulado, logrando que se ejecuten cuando el script los procese.

<figure><img src="/files/yfqdgbuYr3XJzm1kNhXt" alt=""><figcaption></figcaption></figure>

### PoC

Creamos una prueba de concepto (PoC) modificando los metadatos de una imagen para insertar una *payload* que, al ser procesada por ImageMagick, ejecutará comandos arbitrarios.

<figure><img src="/files/wNK4REB4CFLgAwISronE" alt=""><figcaption></figcaption></figure>

El payload que inyectamos modifica los permisos de `/bin/bash`, estableciendo el bit SUID, lo cual nos permitirá ejecutar bash como root posteriormente.

<figure><img src="/files/1yC3KgbOkLa7Qt1xRVXP" alt=""><figcaption></figcaption></figure>

El script vulnerable es ejecutado automáticamente por root cada minuto (probablemente por cron). Tras inyectar la payload, esperamos hasta que el exploit surta efecto. Verificamos que `/bin/bash` ahora tiene el bit SUID y lo usamos para obtener una shell con privilegios de root:

```bash
/bin/bash -p
```

Desde ahí, accedemos al archivo `/root/root.txt` y obtenemos la flag final.

<figure><img src="/files/XNMJEAuYVmmz3mXmNLdb" alt=""><figcaption></figcaption></figure>

***

## Conclusión

Comenzamos con una **enumeración de subdominios**, lo que nos permitió acceder a un entorno de desarrollo expuesto (`dev.titanic.htb`). A partir de ahí, aprovechamos una vulnerabilidad de **lectura arbitraria de archivos (LFR)** para extraer información sensible del servidor, incluyendo rutas internas y una base de datos de Gitea. Tras analizar esta base de datos y **descifrar hashes de contraseñas**, obtuvimos acceso al sistema como el usuario `developer`.

Posteriormente, al analizar los scripts internos del sistema, encontramos uno que usaba **ImageMagick** vulnerable al **CVE-2024-41817**, lo cual nos permitió inyectar comandos que se ejecutaban con privilegios de root. Finalmente, mediante una escalada de privilegios local, conseguimos acceso completo al sistema.