🔴Djinn3
Write-up de la máquina Djinn3 de Proving Grounds #writeup #walkthrough
Last updated
Write-up de la máquina Djinn3 de Proving Grounds #writeup #walkthrough
Last updated
Comenzamos la resolución de este CTF, enumerando que servicios tiene abiertos la máquina. Comenzamos con la enumeración rápida.
Cuatro puertos abiertos: 22, 80, 5000 y 31337. Continuamos con la enumeración profunda de estos servicios.
Servicios abiertos
Puerto 22 -> SSH -> OpenSSH 7.6
Puerto 80 -> HTTP -> lighttpd 1.4.45
Puerto 5000 -> HTTP -> Werkzeug httpd 1.0.1
Puerto 31337 -> ??? -> Elite??
La máquina objetivo está ejecutando dos servidor Web. Veamos su contenido.
Servidor Web en puerto 80
Servidor Web en puerto 5000
Encontramos un posible nombre de usuario.
Vamos a conectarnos a este puerto con netcat.
Nos pide un usuario, vamos a probar con el usuario que encontramos anteriormente "guest".
Nos conectamos con las credenciales guest:guest.
Abrimos el menú de ayuda y vemos lo siguiente:
Seleccionamos Open para crear un nuevo ticket y lo creamos.
¿Donde se envía este ticket? Vamonos al sitio Web que se ejecuta en el puerto 5000.
Existe una relación entre el proceso ejecutado en el puerto 31337 y el sitio Web ejecutado en el puerto 5000.
Vamos a buscar exploits para Werkzeug httpd 1.0.1. Investigando un poco llegamos a esta publicación.
Enviaremos el payload {{5*'5'}}. El resultado esperado debería ser 49 pero en caso de ser un motor de plantilla Jinja2, devolverá 7777777.
El sistema está ejecutando jinja2. Además, presenta una vulnerabilidad de SSTI. Vamos a realizar distintas inyecciones para ver que podemos hacer.
Aprovechando que podemos ejecutar comandos a partir de la vulnerabilidad de SSTI, vamos a tratar de ejecutar una shell desarrollada en Python.
Para ejecutar, guardamos la siguiente shell y la enviamos al objetivo a través de un servidor Web levantado con Python. Ejecutamos el siguiente comando para transferir el shell.py a la máquina víctima.
Ahora por un lado ejecutamos el shellcode transferido y por otro, levantamos un nc en el puerto 1234 en nuestra máquina de ataque.
Obtenemos acceso al sistema como www-data.
Comenzamos enumerando el directorio /opt.
Vemos dos archivos ocultos con nombres un tanto raros. Vamos a transferirlos a nuestra máquina de ataque de la siguiente manera:
En la máquina víctima ejecutamos:
En la máquina atacante ejecutamos:
Decompilamos .syncer.cpython-38.pyc
Decompilamos .configuration.cpython-38.pyc
Al analizar las fuentes, se deduce que debe haber una tarea programada (cron job) ejecutándose por el usuario llamado "saint" para ejecutar el script syncer.py.
Vamos a enumerar los procesos internos que se están ejecutando en el sistema. Para ello, vamos a utilizar la herramienta pspy64. La transferimos al sistema utilizando un servidor HTTP Python.
Estamos trabajando con un programa que tiene ciertos componentes faltantes, pero la información que tenemos nos permite entender su funcionamiento principal:
Nuestro programa utiliza un trabajo cron que ejecuta el script "syncer.py" cada tres minutos. Lo que este script hace es revisar y listar todos los archivos con la extensión .json que se encuentran tanto en el directorio home de un usuario llamado 'saint' como en el directorio /tmp.
Si encontramos archivos cuyos nombres están basados en el formato de fecha, procedemos a comparar estas fechas. Si resulta que la versión del archivo en /tmp es más reciente, copiamos el contenido del URL especificado en el archivo .json a la ubicación de destino también indicada en ese mismo archivo .json.
Por lo tanto, básicamente estamos usando este programa para sincronizar o actualizar información en una ubicación específica usando como fuente un URL dado, pero solo si la versión del archivo .json en /tmp es más reciente que la que se encuentra en el directorio home del usuario 'saint'.
Vamos a crear un archivo con el nombre /tmp/11-07-2023.config.json. El contenido de este archivo es el siguiente:
Ejecutamos un servidor web de Python utilizando el siguiente comando en el directorio /home/kali/.ssh. Una vez hayamos iniciado el servidor, esperemos un máximo de tres minutos para que se establezca una conexión desde el objetivo. Cuando se haya establecido la conexión a tu servidor web, podrás iniciar sesión como el usuario 'saint'.
Buscamos la flag local.txt
Comenzamos enumerando que puede ejecutar el usuario "saint" con sudo sin contraseña.
Aprovechando que "saint" puede añadir usuarios, vamos a crear un usuario con permisos de "root" para poder leer y sobreescribir archivos. Creamos un usuario "securiters"
Vamos a enumerar el contenido del archivo /etc/sudoers.
En el archivo /etc/sudoers, descubrimos que Jason tiene la capacidad de ejecutar apt-get como root sin necesidad de una contraseña. Sin embargo, parece que el usuario Jason no existe, posiblemente fue borrado por un administrador que olvidó eliminar su línea en el archivo sudoers.
Como "saint" puede añadir usuarios, vamos a añadir a jason.
Pivotamos a usuario jason.
Vamos a consultar en GTFOBins como podemos elevar privilegios a partir del vector que tenemos.
Ejecutamos el comando anterior, y ya tendremos conexión en la máquina víctima con privilegios máximos.
Solo quedará buscar la flag proof.txt para finalizar la resolución de la máquina.