SecretJenkins

Máquina de dificultad fácil de la plataforma Dockerlabs

Comprobación

Empezamos este año 2026 con esta máquina de DockerLabs así que vamos a ver qué nos ofrece

Una vez que tenemos la máquina desplegada con la IP 172.17.0.2 vamos a ver si desde nuestra máquina de atacante podemos verla, para ello le vamos a lanzar una traza ICMP aunque antes de eso vamos a crearnos un directorio con el nombre de la máquina como hacemos siempre

Una vez que estamos dentro del directorio vamos a darle uso a una utilidad que tenemos previamente definida en la zshrc la cual nos crea tres directorios para poder llevar a cabo la prueba de pentesting de forma ordenada

Ahora que tenemos estos directorios creados, nos vamos a meter en reconocimiento y vamos a lanzarle la traza ICMP

Como vemos que recibimos el ping sin problemas vamos a proceder al escaneo de puertos

Escaneo de puertos

Comenzamos con el escaneo típico para poder ver qué puertos tiene abiertos la máquina víctima

Este escaneo tiene varios parámetros los cuales vamos a explicar

-p- –open

Con estos parámetros le decimos a nmap que englobe todos los puertos que existen y que estén abiertos

-sS

Este parámetro sirve para que a la hora de realizar el escaneo no se efectúe un Threeway-Handshake, a efectos prácticos es algo más silencioso, ahora cuando terminemos el escaneo vamos a ver qué es lo que pasa por detrás con Wireshark

–min-rate 5000

De esta manera le decimos a nmap que no queremos que se ejecute la herramienta con una velocidad inferior a 5000 paquetes por segundo

-n

Con este otro parámetro le indicamos que no queremos que nos aplique resolución DNS

-Pn

Este parámetro le indica a nmap que no queremos que nos aplique descubrimiento de hosts a través de ARP

-oG puertos_

Por último con este parámetro le decimos que nos exporte las evidencias en un formato que sea posible de tratar con expresiones regulares

Una vez que realizamos el escaneo nos muestra lo siguiente

Vemos que están los puertos 22 y 8080 abiertos, como he dicho antes vamos a ver por detrás qué es lo que hace nmap cuando le indicamos el parámetro -sS, para ello como sé que el puerto 22 está abierto le vamos a hacer un escaneo específico a ese puerto

Vamos a empezar con un escaneo sin indicar el parámetro -sS y vamos a ponernos en escucha para interceptar los paquetes y ver cómo viajan por detrás

Realizamos el escaneo y capturamos los paquetes en la interfaz de Docker ya que las máquinas CTF de DockerLabs son contenedores

Ahora vamos a capturar lo mismo pero utilizando el parámetro -sS de nmap

Una vez que tenemos las dos capturas vámonos a Wireshark para ver qué pasa por detrás

Vamos a empezar con la captura en la que no estamos utilizando el parámetro -sS

Como podemos ver enviamos un paquete SYN, nos devuelve la máquina un paquete SYN/ACK y por último enviamos un paquete ACK de vuelta, por lo que se completa una conexión y el llamado ThreeWay-Handshake, ahora vamos a ver la otra captura

Como podemos ver en este caso enviamos un paquete SYN, nos devuelve la máquina un paquete SYN/ACK y devolvemos un RST que es un reset packet por lo que no se llega a entablar la conexión y esto hace que no sea tan evidente que estamos haciendo un escaneo y que sea más rápido

Genial pues una vez que hemos visto esto vamos a seguir con la máquina

El archivo que nos genera nmap se lo vamos a pasar a mi herramienta portsClean.sh que es para tratar texto de este tipo con expresiones regulares

Ahí tenemos la información más importante y también nos copia los puertos en la clipboard de modo que ahora es más rápido pasar al siguiente escaneo en el que vamos a ver qué servicios y versiones corren para estos puertos

Para poder saberlo vamos a ejecutar nmap con los siguientes parámetros

Los parámetros que hemos utilizado son -sC que sirve para lanzar un conjunto de scripts de reconocimiento que tiene nmap previamente programados en Lua, -sV que sirve para determinar la versión del servicio que está corriendo en los puertos y por último -oN que nos exporta las evidencias de nmap en el mismo formato que nos lo ha representado por pantalla

Aquí tenemos los servicios y sus versiones, vemos que en el puerto 22 está corriendo SSH y en el 8080 un servidor HTTP

PD: Mi cat es un bat por eso puedo proporcionarle con -l un lenguaje de programación para que me lo represente en colores aunque este no sea un script hecho en Java

Genial pues ya que vemos que tenemos un servidor HTTP corriendo vamos a realizar las dos operaciones que realizamos siempre que estamos ante una CTF con servidor web

La primera de todas es detectar las tecnologías que corren para este servidor web con whatweb

Ahí lo tenemos, podemos ver que está corriendo un Jenkins (aunque en el escaneo de nmap también nos lo indicaba)

Para el que no lo sepa Jenkins es un servidor de automatización escrito en Java

Una vez que hemos terminado de detectar las tecnologías vamos a pasar a realizar un pequeño fuzzing con un script de nmap

El script se aloja en esa ruta absoluta del sistema y así es como queda el comando para utilizarlo

Lo que nos ha devuelto es lo siguiente

Como podemos ver tenemos disponible un archivo “robots.txt”, un directorio “api” y un directorio “secured”

Genial pues ya hemos terminado con el proceso de escaneo de puertos así que vamos directos a ver la web

Web

De primeras al entrar lo que vemos es lo siguiente

Un login de Jenkins pero al no tener credenciales no podemos hacer nada

Después de probar las rutas que nos ha dado nmap no me ha servido ninguna así que vamos a realizarle un fuzzing un poco más extenso para ver si podemos ver rutas ocultas

Como podemos ver hemos sacado muchas rutas en claro y después de revisarlas la que más me llama la atención es la ruta “cli” la cual contiene el siguiente contenido

Lo que se nos está compartiendo aquí es un archivo el cual nos permite tener un cliente remoto para poder hablar con Jenkins a través de su API es como “un control remoto de Jenkins desde la terminal”

De normal con el archivo “jenkins-cli.jar” no podemos leer archivos internos de la máquina que está corriendo el servidor web Jenkins, pero en este caso al ser la versión 2.441 (como vemos en la ruta /view/all/builds) sí que podemos aplicarle el CVE-2024-23897 lo que permite lectura arbitraria de archivos (“LFI”)

Para poder explotar esta especie de LFI tenemos que ejecutar lo siguiente

Este comando lo que hace es que el CLI de Jenkins vea @/etc/passwd, lea el archivo localmente y envíe su contenido como argumento a Jenkins y como Jenkins intenta usar el texto como nombre de nodo y como el nombre es inválido el comando falla y nos devuelve el error que refleja el contenido del /etc/passwd

Aquí tenemos todo el contenido del /etc/passwd de la máquina víctima

Podemos ver que hay dos usuarios inusuales, “bobby” y “pinguinito” por lo que vamos a intentar con hydra sacar cuáles son sus contraseñas para poder conectarnos como ellos por SSH

Tras probar con el usuario pinguinito y no tener éxito, he probado con el usuario bobby y he obtenido lo siguiente

Tenemos la contraseña de bobby para poder conectarnos como él por SSH

Genial pues ya estamos dentro por lo que vamos a comenzar con la fase de escalada de privilegios

Escalada de privilegios

Si nos vamos al directorio /home podemos ver que tenemos directorios de dos usuarios, bobby que es con el que estamos conectados y pinguinito por lo que seguramente vamos a tener que escalar primero a pinguinito

Al hacer un “sudo -l” veo lo siguiente

Puedo ejecutar el binario “python3” como el usuario pinguinito por lo que me da un vector clarísimo para poder escalar privilegios por ahí

Para poder hacerlo hay mil maneras ya que es un binario del que es muy sencillo abusar

Al intentar crearme un script en Python para poder escalar privilegios me doy cuenta que la máquina no tiene ni nano ni ningún editor de texto por lo que he recurrido a esta manera para poder crearme el script

Ahora simplemente dándole permisos de ejecución y ejecutándolo como el usuario pinguinito, obtendremos una shell con la sesión del usuario pinguinito

Y por ahí tenemos la primera escalada de privilegios, como ya he dicho hay varias maneras de elevar privilegios cuando el binario es python3, podríamos haber ejecutado python3 como el usuario pinguinito y desde el modo interactivo haber hecho lo mismo

Una vez que estamos como este usuario vamos a ver cómo podemos escalar a root

Si ejecutamos de nuevo “sudo -l” podemos ver que tenemos lo siguiente

Podemos ejecutar como el usuario root el script ubicado en opt llamado “script.py” por lo que vamos a irnos a este directorio para ver de qué trata el script

Básicamente lo que hace es copiar el propio contenido del script en otro llamado “script_backup.py”

Podemos ver que tenemos permisos de escritura en el directorio donde se encuentra este script por lo que podemos crear un script que se llame igual en este directorio pero que contenga el código que nosotros queramos

Para empezar vamos a cambiarle el nombre al script sobre el que teníamos permiso en un inicio

Y ahora vamos a crear nuestro script con nombre “script.py” para poder llegar a ejecutarlo como root

Como podemos ver ahora somos el usuario root por lo que ya hemos elevado nuestros privilegios al máximo

Al ser un lab de DockerLabs no hay flag que proporcionar ni nada por lo que este es el final de la máquina, creo que es divertida lo único que las formas de elevar privilegios un poco fáciles pero por algo es una máquina fácil