Writeup magicgardens HTB
En el ataque a MagicGardens, primero se aprovecha una vulnerabilidad en un sitio web basado en Django, manipulándolo para que procese y apruebe de forma fraudulenta la compra de una suscripción premium. Gracias a esa suscripción, se inserta una carga maliciosa en un código QR, lo que permite capturar la cookie del administrador. Con esa cookie, se accede al panel de administración de Django, donde se obtiene el hash de la contraseña y acceso mediante SSH al sistema.
Dentro del sistema, se identifica a otro usuario que ejecuta un programa personalizado de monitorización de red. A través de un desbordamiento de búfer en el controlador de tráfico IPv6, se consigue abrir una shell con los permisos de ese usuario.
Este usuario tiene privilegios sobre el registro de Docker, lo que permite acceder a la imagen del contenedor que ejecuta el sitio Django, donde se encuentra un secreto codificado. Aprovechando una vulnerabilidad de deserialización en la aplicación del contenedor, se obtiene acceso como superusuario (root) dentro del contenedor.
Por último, se explota la capacidad de cargar módulos en el núcleo (kernel) desde el contenedor para escalar privilegios y conseguir acceso completo como root en el sistema principal.
lo primero como siempre el escaneo de nmap:
nmap -p- --open --min-rate 5000 -sn -sT -Pn -n -vvv 10.10.11.9
el escaneo encuentra dos puesrtos curiosos. el 80 con un dominio magicgardens.htb y un docker en el 5000
poenemos el dominio en el /etc/hosts y hacedemos a la web 
la pagina en si es una pagina de compra de flores. funciona como toda tienda normal. permite añadir al carrito y comprar. siempre que pongo la info para comrar recivo un mensaje de que el pedido se esta procesando
tambien puedo crear una cuenta. y generar un qr raro para comprar una nueva sub
al selecionar el banco nos salen 3 posibles opciones honestbank.htb, magicalbank.htb, and plunders.htb. esto por si acaso lo añadimos en el etc/hosts por si tiene que hacer algo con la API
si le damos a suscribir hace una peticion en POST ala propia tienda y un nuevo mensaje flash explicando que mi suscripción se está procesando. Al actualizar la página aparece un mensaje de error sobre problemas con el pago.
si pillamos la peticion en burpsuite vemos que podemos cambiar la peticion para que en vez al banco haga ping a nuestra ip :
nos ponemos en escucha con netcat:
Así que cuando intento pagar, envía una petición a /api/payments/ en el banco usando el módulo de peticiones de Python.
que pasa que si hacemos esta peticion nos devuelve un estado 402 Pago requerido y una carga útil JSON con el código de estado, el mensaje y el nombre y número de tarjeta del mensaje original. Este es probablemente el formato esperado por la tienda.
con python podriamos crear un servidor sencillo que intente imitar la API real
repetimos el proceso de burpsuite pero redirecionamos a nuestro exploit si lo emos echo vien saldra esto:
ahora cada vez que intentamos hacer una compra recibo un mensaje de morty pidiendome el qr aqui podriamos intentar colar un XSS en una imagen de esta forma
le pasamos la imagen y ganamos la cookie de morty
la ponemos en nuestro navegador y ya como morti podemos acceder a /admin puedo ver los objetos almacenados en la base de datos. Desafortunadamente el hash de la contraseña del usuario (admin) morty no es visible, pero también está registrado como Usuario de la Tienda y ahí puedo coger su hash de contraseña. 
tenemos el hahs y lo procedemos a romper con hashcat
y provamos a haceder por SSH 
ejecuto linpheas.sh y veo algo curioso 
hay un segundo usuario llamado alex 
aparte esta ejecutando harvest 
y el puerto de ejecucion es el 1337
podemos probar a aconectarnos de esta forma:
y nos salta esto
si el binario de harvest /usr/local/bin/harvest nos lo pasamos a nuestra mquina y lo analizamos con por ejemplo gidra o algun semejante
dentro de la funcion log_packet inicializa un nuevo buffer con longitud 65360, seguido directamente por el nombre del fichero log.
esto es curioso. porque en la función de llamada el buffer era más grande. Esto podría abrir un camino para desbordar el buffer y luego sobrescribir el nombre real del archivo.
vale como hacemos este buffer overflow? pues de la siguiente manera
creamos una clave publica ssh en nuestra mquina atacante
hacemos un cat al el .pub y sacamos la clave para ponerlo en el siguiente exploit:
ahora en nuestra maquina ejecutamos esto sobre el binario de harvest:
y ejecutamos el exploit en la maquina victima (DENTRO DE ELLA)
si todo a hido bien deveriamos poder hacer
y estar dentro 
root
si vamos a /var/spool/mail veremos dos archivo interesantes:
si hacemos un cat al de alex veremos lo siguiente: 
Antes de extraer el hash con zip2john decodifico el archivo adjunto codificado en base64 y lo paso a un archivo. Luego ejecuto john para intentar descifrar la contraseña. Eso tiene éxito y puedo descomprimir el archivo con realmadrid.
el .zip contiene la passwor de AlexMiles : AlexMiles:$2y$05$KKShqNw.A66mmpEqmNJ0kuoBwO2rbdWetc7eXA7TbjhHZGs2Pa5Hq
que la podemos romper con jhon y nos da la contraseña Diamonds
Con las credenciales AlexMiles:diamonds puedo autenticarme en el Docker Registry que se ejecuta en el puerto 5000.
con esto podemos usar DockerRegistryGrabber para descargar imagenes
En lugar de revisar cada capa de manera individual, extraigo todas las capas en el directorio de salida para obtener el sistema de archivos completo de la imagen final. El orden adecuado se determina según la marca de tiempo de creación, como se mostró en el script Python anterior. Dentro de los archivos extraídos, es posible encontrar el código fuente de la aplicación, incluyendo su SECRET_KEY en un archivo de entorno.
Django utiliza el pickling para almacenar información en las cookies2, por lo que en cuanto se filtra la SECRET_KEY, es posible falsificar cookies válidas que se deserializan en la aplicación.
y con ello hacer un explot para acceder
ahora si ejecutamos este exploit y nos ponemos en escucha en el puesrto que emos especificado
vale vamos a ver las capavilitis del usuario: 
El listado de capacidades revela el módulo cap_sys_module, que permite al contenedor cargar y descargar módulos del kernel.
por lo que podemos hacer lo sigiente
subimos esta revershell en c a la maquina por wget:
y este makefile
nos ponemos en eschucha y ejecutamos un make para que todo se cree 
y por ultimo un insmod reverse-shell.ko para obtener la shell
y somos root
Última actualización