> 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/the-hacker-labs/avanzado/hellroot.md). # HellRoot ## Información de la máquina

**Hellroot** es una máquina Linux de nivel *avanzado* en *The Hacker Labs*, diseñada para simular una cadena de explotación realista que involucra tanto técnicas web como explotación avanzada a nivel de sistema. El reto comienza con una aplicación vulnerable de búsqueda DNS expuesta en el puerto 5000, la cual permite RCE a través de una mala validación de entradas. Esta vulnerabilidad da acceso a un contenedor Docker, aislado del sistema principal. Paralelamente, una instancia de **Gitea** expuesta en el puerto 443 proporciona el código fuente completo de la aplicación, lo que permite realizar una auditoría de seguridad completa. A través del análisis del tráfico de red y la exposición de credenciales, se obtiene acceso por SSH al sistema anfitrión como el usuario **astro**. Finalmente, se detecta una oportunidad de **Library Hijacking** en un binario con bit SUID, lo que permite escalar privilegios y obtener acceso como **root**. Esta máquina es ideal para quienes desean fortalecer sus habilidades en análisis de código, explotación de contenedores y técnicas avanzadas de post-explotación en sistemas Linux. *** ## Reconocimiento Empezaremos haciendo un primer reconocimiento para ver los puertos abiertos en el sistema.

**. `-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 65,535 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). * 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 **`allPorts` .** El escaneo revela muchos puertos abiertos. Ahora haremos un escaneo más detallado.

**1. `-p` → Escaneo de puertos específicos** Con `-p`, le indicamos que **solo** escanee los puertos que queremos **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**. En el puerto **5000**, encontramos una aplicación web que permite realizar búsquedas DNS (Domain Lookup), lo que significa que podemos introducir un dominio y obtener su resolución DNS, similar a un `nslookup`.

En el puerto **443**, accedemos a una instancia de **Gitea**, una plataforma similar a GitHub. En ella se encuentra alojado el **código completo de la aplicación web del puerto 5000**.

## RCE in webapp -> Docker container access Dentro del repositorio en Gitea, el archivo **`index.php`** revela el comportamiento interno de la aplicación del puerto 5000. Analizando el código, detectamos una **vulnerabilidad lógica** que permite ejecución remota de comandos (RCE).

El código evalúa si la cadena ingresada contiene un **punto y coma (`;`)**. Si es así, **omite el tratamiento seguro del input** y pasa el valor directamente a `shell_exec()`, lo que permite la **ejecución arbitraria de comandos**. Específicamente, si la entrada contiene un `;`, se ejecuta directamente en el sistema: ```php $output = shell_exec($decoded . ' 2>&1'); ``` Probamos con una entrada como `ejemplo.com; whoami`, la cual convertimos a **hexadecimal** y la enviamos al formulario de la web. El servidor ejecuta el comando y nos devuelve la salida: `www-data`.

La pegamos en la aplicación y se nos ejecuta el comando correctamente, respondiendo con www-data

A continuación, construimos una **reverse shell** usando el mismo método.

Lo pegamos en el input (sin errores de espacios).

Nos ponemos en escucha con `nc` y al ejecutarlo recibimos acceso. Sin embargo, **no accedemos a la máquina principal**, sino a un **contenedor Docker** aislado.

## Docker privilege escalation Revisando otros archivos del repositorio en **Gitea**, encontramos **credenciales de acceso para el usuario `astro`**. Usamos estas credenciales dentro del contenedor para cambiar a este usuario.

Migramos a este usuario.

Al enumerar los privilegios del usuario `astro`, vemos que puede ejecutar el comando `su` con **sudo**. Esto nos permite usar `sudo su` para obtener una shell como **root dentro del contenedor**.

## SSH credentials -> Astro access machine Para avanzar, encontramos un archivo llamado **`sniff.txt`** en `/var/www/html`. Este menciona el uso de herramientas para **esnifar tráfico de red**, lo que sugiere que podemos capturar credenciales en tránsito.

Usamos **`tcpdump`** para capturar tráfico en la interfaz de red y lo almacenamos en un archivo `captura.cap`

Mientras tanto, intentamos iniciar sesión en Gitea desde otra terminal usando las credenciales de `astro`.

Al revisar el archivo `.cap`, vemos que obtenemos una contraseña distinta a la que teníamos.

Ahora, usando esa contraseña, podemos acceder finalmente a la **máquina principal por SSH** como el usuario `astro`.

## Privilege escalation -> Library Hijacking Para escalar privilegios, descubrimos **dos binarios con el bit SUID** habilitado. Como son binarios personalizados, **GTFObins no nos sirve como referencia directa**, por lo que los analizamos manualmente.

Usamos `ldd` para identificar las bibliotecas dinámicas usadas por los binarios.

Luego, con `readelf`, vemos que uno de los binarios (**secmonitor**) intenta cargar una biblioteca desde una ruta relativa no segura. Esto permite realizar un **Library Hijacking**.

Escribimos un código en **C** para una biblioteca maliciosa que lanza una shell (`/bin/bash`).

Compilamos la librería con `gcc -shared -fPIC` y la colocamos en la ruta esperada.

Al ejecutar el binario `secmonitor`, este carga nuestra librería y se ejecuta con **permisos de root**, dándonos una shell privilegiada.

Finalmente, accedemos a la **flag final** del sistema.

*** ## Conclusión La máquina **Hellroot** representa un excelente ejemplo de cómo una exposición combinada de código fuente, validaciones mal implementadas y configuraciones inseguras puede llevar a una cadena completa de compromiso del sistema. Desde la obtención inicial de RCE en una aplicación web hasta la evasión del aislamiento de Docker mediante credenciales filtradas y tráfico capturado, cada etapa refleja situaciones realistas encontradas en entornos productivos. La explotación final, mediante una técnica de **Library Hijacking**, demuestra la importancia de validar rutas absolutas en binarios con permisos elevados. En conjunto, **Hellroot** es una máquina desafiante y didáctica que cubre múltiples vectores modernos de ataque, ideal para afianzar habilidades ofensivas avanzadas.