SecretJenkins
Que tal lord & lady
En esta ocasión te traigo la resolución de maquina SecretJenkins de la plataforma Dockerlabs.es.
Requisitos previos:
- Tener configurado al menos una maquina virtual como Kali o Parrot (link aquí)
- Tener descargado lo necesario para el laboratorio de dockerlabs.es (link aquí)
Write Up Maquina SecretJenkins #dockerlabs.es
Reconocimiento
Con el ping nos damos cuenta de 2 cosas:
1- La maquina responde
2- Por el ttl=64 sabemos que es una maquina Linux
Yo acostumbro agregar un archivo a la carpeta de trabajo donde puedo identificar fácilmente tanto la IP como el sistema operativo, dado por el TTL.
Escaneo de puertos con Nmap
$ sudo nmap -sS -p- --open --min-rate 5000 -vvv -n -Pn 172.17.0.2 -oN nmap_quickScan.txt
Por ahí alcanzamos a ver que tenemos el puerto 22 y 8080 abiertos.
Vamos a revisar, con ayuda de Nmap, tanto el servicio como la versión que se ejecutan en estos puertos:
$ sudo nmap -sCV -p22,8080 172.17.0.2 -oN nmap_targettedPorts.txt
Bien, vemos que hay un puerto OpenSSH de versión 9.2p1 y ademas un puerto 8080 que nos indica que es un Jetty 10.0.18.
Puerto 22
Puerto OpenSSH, version 9.2p1
Vamos a ver que dice searchsploit:
Puerto 8080
Como es buena costumbre, vamos a revisar que hay en nuestro puerto 8080 utilizando nuestro navegador de confianza:
Por ahíi estamos viendo una plataforma de Jenkins.
Para aquellos que no han trabajado con Jenkins, Jenkins es una plataforoma de integración de DevOps, los famosos CI/CD (Continues Integration and Continues Deployment, respectivamente).
Pero, también como buena practica vamos a ver cual es la definición oficial:
Link: https://es.wikipedia.org/wiki/Jenkins
Bien, una cosa que a mi se me ocurriría, es dar Ctrl + U para ver la parte de código y ver si podemos ver cositas, como comentarios del desarrollador que se le hallan pasado, plugins, sus versiones, etc.
Se alcanza a apreciar un código un tanto minimizado, pero esta bien, vamos a revisarlo a detalle para ver que vemos...
Revisando un poco no alcanzo a ver plugins o versiones del jenkins. solo veo que hay una carpeta "/static/", habria que hay...
Interesante, sin indagar tanto podemos observar ya una versión de Jenkins, la 2.441.
Pues ni tan tarde, vamos a darle de una vez por aquí.
Si buscamos con "searchsploit" o en Github, Google vulnerabilidades para Jenkins utilizando esta versión, vamos a ver que encontramos.
searchsploit:
Al menos por aquí, no encontramos nada
Google y Github:
Vaya, aquí si que encontramos cositas, vamos a ir al primer link de Github donde veo que podemos leer un archivo del servidor.
Vamos a intentar elegir un exploit que nos permita realizar la lectura de algún archivo del servidor...
Jugando un poco por fin encontré uno que me permitió leer el famoso "/etc/passwd"
Aquí te explico los pasos que seguí:
1- Voy a link del archivo en Github de godylockz, elijo el archivo jenkins_fileread.py:
2- Le doy a raw y copio el link:
3- Voy a la terminal y lo descargo con wget:
$ wget https://raw.githubusercontent.com/godylockz/CVE-2024-23897/main/jenkins_fileread.py
Ya una vez que tengo el archivo, voy a intentar (según la ayuda de Github) leer el archivo "/etc/passwd":
Como pudiste observar, primero le tuve que dar permisos de ejecución al archivo con chmod.
Al final si pude leer el archivo, ahora vamos intentar leer otro archivo del sistema que guarda las contraseñas, en este caso es "/etc/shadow":
Excelente.
Como podemos observar en este ultimo archivo (shadow) tenemos algunos passwords que pudieramos crackear, tanto para el usuario bobby como el usuario pinguinito.
Crackeando contraseñas del archivo /etc/shadow
Vamos a crear 2 archivos uno como tal una copia del passwd y otro del archivo shadow, esto en nuestra maquina local de atacante:
passwd:
shadow:
Para ello ejecutamos el siguiente comando:
$ unshadow passwd shadow > unshadow
Ahora si, teniendo este archivo vamos a utilizar el famoso "john the ripper" para poder crackear las contraseñas.
Ejecutamos el siguiente comando:
$ john --format=crypt --wordlist=/usr/share/wordlists/rockyou.txt unshadow
Esto puede tardar unos segundos tal ves minutos, dependerá de la potencia de tu procesador.
Pues para este momento, hemos obtenido la contraseña de nuestro usuario bobby, que es chocolate.
Vamos a ingresar con este usuario por ssh:
Excelente! ya estamos dentro de la maquina, vamos a ver que podemos hacer.
Lo que yo acostumbro es verificar que puedo ejecutar a nivel de sudoers, de lo contrario, indagaremos mucho mas profundo procesos:
A nivel de sudo, podemos ejecutar python3 simulando el usuario pinguinito, vamos a ver si podemos ejecutar una consola con python3:
Excelente!
Hemos podido brincar de usuario bobby a usuario pinguinito, ahora realizamos lo mismo para este usuario, verificar que podemos ejecutar primeramente a nivel de sudoers:
Parece ser que podemos ejecutar para todos los usuarios el python3 y pasarle como parámetro el script.py de la carpeta /opt, vamos a ver revisar algunas cosas primero, como:
- ¿Qué permisos tiene python3?
Totalmente root.
- ¿Qué permisos tenemos sobre la carpeta /opt?
Tanto pinguinito como root tienen permisos totales para acceder a ella.
- ¿Qué terminales tenemos? y ¿Qué permisos tienen cada una?
Cuando menos para la bash y la sh (que por cierto, esta ultima apunta a una terminal dash) son absolutamente root.
Regresando al comando sudo -l, podemos ejecutar el archivo "/opt/script.py", veamos que contiene este script y ver si lo podemos modificar:
Vaya! vaya!
Parece ser que no tenemos ningún editor para poder realizar modificaciones.
Bueno, algo que se me ocurre intentar hacer es intentar con "echo" colocar datos en este script, pero primero vamos a sacarle un backup a este script.
Ahora bien, intentaré obtener una bash desde python, pero veremos si puedo escribir con echo sobre este archivo ya que yo soy el propietario:
Ejecutamos el siguiente comando:
No nos ha permitido, pero ¿Porqué no nos ha permitido?
Bueno, si revisamos detalladamente los permisos, vemos que para el usuario tenemos r_x en el primer tercio de los permisos:
Esto quiere decir que podemos leer (r=read) y podemos ejecutar (x=eXecute) pero no podemos escribir sobre el archivo (w=write).
Tendríamos que tener al menos el permiso de -rwxr--r-- para al menos poder escribir/modificar este archivo.
Bueno ¿Qué otra alternativa tenemos?
Si revisamos la imagen anterior, tenemos que el script.py hace un import de la librería shutil.
hay un concepto en el hacking que se llama "Library hijackng" que en otras palabras significa "Secuestrando libreria".
En python, una forma de poder hacer esto es, crear en el directorio actual el archivo shutil.py y esperar a que el archivo script.py lo "importe" antes de que importe la librería origial.
Elevación de privilegios por "Library hijacking"
Vamos al directorio /opt y ahí vamos a intentar escribir/crear el archivo shutil.py con el contenido como se muestra a continuación.
A y le damos permisos de ejecución:
Ahora intentamos ejecutar el comando de python pasandole como parametro el archivo script.py:
Y boom! somos root!
Post Explotación: Persistencia
Algo que suelo hacer como buena practica, es que realicemos persistencia en la maquina victima, esto para poder conectarnos nuevamente ya que cerremos o reiniciemos todo.
Para ello vamos a generar una clave para ssh que nos permita conectarnos sin contraseña a la maquina victima.
Generamos una clave en nuestra maquina atacante:
Lo anterior nos genera unas claves en nuestro usuario actual que es kali, en el directorio "/home/kali/.ssh/"
Desde aquí habilitamos un servidor en python y copiamos el archivo "id_ed25519.pub" a la carpeta "/root/.ssh/" con el nombre de authorized_keys.
Ojo: tu archivo .pub muy seguramente se va a llamar de forma diferente.
Maquina atacante:
Maquina victima:
Como puedes ver, tuve que ejecutar curl para poder obtener el archivo .pub ya que wget no esta instalado.
Ahora bien, este nuevo archivo debería darnos capacidad de entrar directamente a la maquina victima sin proporcionar contraseña:
Y con esto accedemos como root como todos unos expertos :) .
Resumen
Como pudiste observar, hemos conseguido explotar una vulnerabilidad de la plataforma Jenkins, que por cierto es muy actual, si vemos el CVE, trata de una vulnerabilidad del año 2024.
Con la vulnerabilidad pudimos extraer tanto el passwd y el shadow de la maquina victima, de la cual pudimos cracker una contraseña, la del usuario bobby.
Una vez extraída la contraseña, pudimos entrar a ssh con este usuario y de ahí, cambiamos de usuario a pinguinito gracias a la configuración de sudoers para este usuario.
Ya una vez con este usuario pudimos elevar privilegios a root gracias a la configuración de sudoers a python3 y la capacidad de ejecutar un script que utilizaba una librería shutil.py, la misma a la que hicimos hijacking.
Conclusiones
Yo te veo en un siguiente post.
Hasta luego!
Comentarios
Publicar un comentario