HTB: Writeup — Pandora

Recon

Initial nmap scan

An initial scan with nmap shows that there is two ports open, ssh on 22 and http on 80.

Site

Having a look at the page hosted on port 80 there appears to be a host name of Panda.HTB.

Next I added this host to the /etc/hosts/ file with my favorite editor nano. The line added to hosts should look like 10.10.11.136 Panda.HTB. Oddly the same page loads so there’s nothing new to see here.

Directory Enumeration

While walking the site its always best to run a directory scan with your favorite tool in the background. This one only returned the directory /assets

But there wasn’t much to see here.

NMAP UDP

Now it’s time to run a nmap scan to check all ports, but that came back with nothing. It never hurts to enumerate all the things while looking through the site some more so be sure to check at least the top UDP ports. Here I found that snmp port 161 is open!

SNMP - UDP PORT 161

As the only finding so far it is time to install some tools to check it out.

apt install snmp snmp-mibs-downloader

Then I ran:

snmpbulkwalk -Cr1000 -c public -v2c 10.10.11.136 > snmp-pandora

I got all kinds of information back from this. Running processes, network information, host information, installed packages and paths.

Initial Foothold

There is a lot to look through but the process running a script at /usr/bin/host_check stands out. This is where saving the results comes in handy as I can simply grep things that look interesting and see the result.

And here I found a username daniel and password HotelBabylon23! Time to try them out on ssh since the earlier scan showed that port is open.

Now that I am in its time to have a look around. There is nothing in Daniel’s home directory so I checked if there was any other users under home and sure enough there is a user named matt and matt has theuser.txt flag but I am unable to read it just yet.

cat: user.txt: Permission denied

Next I checked sudo -l but Daniel has no permissions to for sudo. So I went and checked if there was anything interesting in the webserver config files.

Here I found another virtual host mention by pandora.panda.htb. As this is an internal host I had to forward it through ssh.

ssh daniel@10.10.11.136 -L 8888:localhost:80

And now I have access the site locally.

CVE-2021-32099

I was immediately greeted with a Pandora FMS login page which nicely includes the version information at the bottom! A quick search reveals that this version has a vulnerability, CVE-2021-32099.

Reference:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32099

With this I gave sqlmap a quick attempt but as usual it found the injection but doesn’t exploit it.

sqlmap -u '[http://127.0.0.1:8888/pandora_console/include/chart_generator.php?session_id=1](http://127.0.0.1:8888/pandora_console/include/chart_generator.php?session_id=1)' --batch

I could however enumerate the database using --dbs

Checking the pandora tables with -D pandora --tables gives us a long list of 178 tables!

The most obvious table to check tpassword_history didn’t seem to reveal anything or at least I was unable to crack the password. -D pandora -T tpassword_history --dump

But in tsessions_php there was a list of 55 cookies. As I only need access to matt or admin accounts I ignored the NULL and Daniel cookies. Since the user.txt flag is located under matt I tried his cookie in the browser first and got access!

CVE-2020-13851

From here I found another known vulnerability that I could use, CVE-2020-13851 to perform RCE.

Reference:

https://www.coresecurity.com/core-labs/advisories/pandora-fms-community-multiple-vulnerabilities

From the console I went to Events and View Events and captured this request in burp which I then send over to repeater. I then modified the payload and started nc to be ready before sending the request.

And I am in as the user matt and can cat out the user flag in matt’s home directory!

Privilege Escalation

Nothing else in their directory so I try sudo -l with no luck. But the next thing to check for is SUID binaries find / -perm -4000 -ls 2>/dev/null and something interesting comes up

SUID

/usr/bin/pandora_backup

Strangely this fails and the connection keeps dropping so I dropped my public key in /home/matt/.ssh/authorized_keys and got a stable shell over ssh instead. This also made it so running pandora_backup now works just fine!

Tar is mentioned a few times here and has no path given. It may be susceptible to path hijack so I’ll use export PATH**=**/dev/shm:$PATH which makes the first place tar looks in as /dev/shm.

Time to make a payload nano tar

#!/bin/bash

bash

Then I changed permissions to executechmod +x tar and reran pandora_backup again and it changed to root shell and all that is left is to go claim that root.txt flag!