Buster

Fase de reconocimiento

Estos son los ajustes de red que tiene la máquina victima, lo demás lo he dejado como viene por defecto:

Para identificar la IP de la maquina victima tendremos que hacer uso del siguiente comando:

┌──(root㉿kali)-[/home/burpi]
└─# arp-scan -l
Interface: eth0, type: EN10MB, MAC: 08:00:27:6c:16:60, IPv4: 192.168.8.109
WARNING: Cannot open MAC/Vendor file ieee-oui.txt: Permission denied
WARNING: Cannot open MAC/Vendor file mac-vendor.txt: Permission denied
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.8.1     38:b8:00:ac:70:80       (Unknown)
192.168.8.101   a8:42:a1:81:3d:ea       (Unknown)
192.168.8.145   08:00:27:26:7d:86       (Unknown)

Nmap

Lo primero como siempre es escanear los puertos expuestos, esto lo podremos conseguir con Nmap; encontramos los siguientes puertos abiertos:

• 22 (SSH)

• 80 (HTTP)

La web es un WordPress y no tiene nada de mucho interés en su interior, así que sin mas dilación vamos a hacer un escaneo de WPScan

Fase de intrusión

WPScan

Con wpscan se pueden descubrir vectores potenciales para la explotación de un WordPress, en este lo que estamos buscando es algún plugin vulnerable del cual podernos aprovechar para escalar privilegios.

┌──(root㉿kali)-[/home/…/Desktop/maquinas/buster/nmap]
└─# wpscan --url 192.168.8.145 --enumerate ap,u --plugins-detection aggressive --api-token xxxx
_______________________________________________________________
         __          _______   _____
         \ \        / /  __ \ / ____|
          \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
           \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
            \  /\  /  | |     ____) | (__| (_| | | | |
             \/  \/   |_|    |_____/ \___|\__,_|_| |_|

Tras una larga espera 30 minutos aproximadamente, damos con el plugin vulnerable, el cual es el vector de explotación en esta máquina, "WP Query Console", un plugin vulnerable con el cual conseguiremos Ejecución Remota de Comandos (Or en English, Remote Code Execution, RCE ), no logro encontrar nada en exploit-db, pero en GitHub encuentro un POC (Proof Of Concept).

Lo replicamos en nuestro Burp-Suite y indagando un poco por la respuesta, encuentro una lista de funciones bloqueadas, así que tendremos que hacer uso de algún comando que no este en esta lista para ejecutar comandos:

Una alternativa podría ser shell_exec, comprobamos que funciona haciéndonos un ping:

Escalada de privilegios

Nos mandamos una reverseshell para poder hacer Ejecución Remota de Comandos y como no, lo primero que haremos será la Depuración de tty:

Dentro del wp-config.php, hayamos unos credenciales

Iniciamos sesión en mysql con dichos credenciales, vamos a navegar entre las bases de datos y tablas hasta encontrar con más posibles credenciales:

John

Bingo, encontramos dos hashes de unos usuarios, vamos a pasárnoslos a la maquina atacante, para con John, una herramienta de cracking, dar con la contraseña valida:

┌──(root㉿kali)-[/home/…/Desktop/maquinas/buster/content]
└─# john --wordlist=/usr/share/wordlists/rockyou.txt hashwelcome

También probé con el hash de ta0 pero no encuentra nada, da igual, porque con el credencial obtenido con John, iniciamos sesión como welcome (Un usuario del sistema)

Se nos ha jodido la shell al iniciar sesión, no pasa nada, volvemos a hacer la Depuración de tty

Revisando los permisos suid, encontramos que podemos ejecutar gobuster como cualquier usuario, es decir, podríamos ejecutarlo como root, quizás podríamos jugar con el output de los directorios encontrados usando gobuster...

Pspy64

Nos descargamos pspy64 para poder revisar las tareas cron que se están ejecutando en el equipo y encontramos que se ejecuta con la bash un archivo .sh, "test.sh".

Las cosas que se me viene a la mente que podríamos hacer serian:

1. Con el output de gobuster, editar el /opt/.test.sh para así obtener una reverseshell como root

2. Con el output de gobuster, editar el /opt/.test.sh para que a su vez el /etc/sudoers se edite y así obtener root haciendo un sudo bash -p

Yo hare la segunda porque la primera ya la hizo ll104567 en su writeup, también una cosa interesante que se podría hacer es editar el /etc/passwd como hizo 7r1UMPH, de está manera no se utilizaría la tarea cron y solo editaría el /etc/passwd. Os dejo por aqui un pequeño esquema en Paint de lo que tengo pensado hacer:

Primero nos creamos la ruta que queramos que ejecute la tarea cron en nuestra maquina atacante:

Ahora nos creamos la wordlist para que busque la ruta creada en nuestra maquina atacante y corremos el gobuster (Para comprobar que el archivo se ha editado correctamente se le puede hacer un "ls -al /opt" y revisar la fecha de edición):

Yo en este punto lo que he hecho, ha sido crear en el /tmp/sudomucho de la maquina victima, un archivo que añada con un echo al /etc/sudoers una orden para que el usuario welcome pueda ejecutar comandos de privilegios elevados sin proporcionar contraseñas:

Archivo /tmp/sudomucho, que se ejecutara porque le hemos especificado en la tarea cron que lo haga (Aseguraros de hacerle un chmod +x)

Se ejecuta el script y conseguimos ser root :)

La escalada de privilegios de está maquina ha sido divertida, hay varias maneras de hacerlo así que no te cortes y prueba de todas las maneras que se te ocurran! 😎👌