Pandora was a fun box. I got to learn about SNMP exploitation and sqlmap.
Scanning the box for open TCP ports reveals only port 80 and 22. Not too interesting, but i'll check out the website.
After digging around the website for a while, I decided there was nothing to help me there so I moved on. I subdomain fuzzing, directory enumeration, and file detection, but nothing worked. There had to be something else, so I ran a UDP scan. UDP scans are extraordinarily slow, even with the proper speed flags set so I took the liberty of scanning only the 20 most common ports. Sometime between these two steps I added panda.htb to my /etc/hosts file.
sudo nmap -sU -top-ports=20 panda.htb
The box is running SNMPv1. SNMP stands for simple network management protocol, and it is used for network management and monitoring. SNMPv1was defined in RFC1157 and was the first iteration of the SNMP protocol. Because of this, it was designed with little to no security in mind. In fact, both SNMPv1 and SNMPv2 (fun fact, SNMPv2 is the most widely deployed version today) send cleartext messages. Only SNMPv3 (the most recent) supports encryption and authentication. SNMP stores information in a structure called a Management Information Base (MIB for short). This is a relational structure that deems what information can be read, written, and accessed. These use identifiers called OIDs, but it's not important to explain those. You can read about them here.
To retrieve information from machines running SNMP, a requester will send a GET request to the machine, along with a string to authenticate itself. SNMPv1 uses two different strings, called community strings, for authentication with machines. The read only string is usually for read-only information, and the read-write string is for the ability to modify some information. The great thing about these community strings is that they are unhashed, atomic, and easy to crack. I used this list to find the community string for the machine.
After I got the community string, I used a tool called snmpwalk to enumerate all the information I could.
snmpwalk -v 1 -c public panda.htb > snmpwalk-1.txt
As you can see, while I was going through the information I found a cleartext username and password, so I used those to log into the machine via SSH.
The user flag is in another user's directory, so I need to pivot into that user. The two primary targets I had were /var/www/html and /var/www/pandora. The html side was visible to the public, but the pandora was new. Inside the /etc/hosts file we see weird assignment, so I decide to use this as a lead.
If we assume that this hostname will trigger the pandora directory, then we will need to set up a dynamic tunnel. You can do this with the following command: ssh -D 9090 [email protected]
Using this tunnel, we can set up a proxy to view the webpage.
Note that it must be SOCKS5 so it supports DNS resolution (localhost.localdomain).
Navigating to localhost.localdomain/pandora_console will show us a login page for some software called Pandora FMS. Luckily for us, there are lots of CVEs out there for this software, and this post specifically shows us that the chart_generator.php file's session_id parameter is vulnerable. I want to use sqlmap for this, so I will need to use a great tool called proxychains. Proxychains was designed to create a chain of proxies that allow you to pivot your tools into systems without having to install tools on the other side of whatever you are pivoting into. To use proxychains, you need to specify the dynamic tunnel to pivot through via the /etc/proxychains4.conf file.
After setting that up, we can run a sqli attack against the chart generator file.
proxychains sqlmap --url="http://localhost.localdomain/pandora_console/include/chart_generator.php?session_id=''" -D pandora --tables
The table we are interested in is the tpassword_history table. After dumping that, we get the password hashes for matt and daniel. Just looking at the hashes, I can already tell they are md5 (I also looked in the php file that generates them). proxychains sqlmap --url="http://localhost.localdomain/pandora_console/include/chart_generator.php?session_id=''" -Ttpassword_history --dump
Furthermore, the php session ids are all stored in the tsessions_php table.
Nice, so now I can just copy one of matt's session IDs into the url and see if it works.
Sure enough, it brings me right to the dashboard. Unfortunately, despite This cve, I was unable to get a shell. I kept looking around and found this which might work. So I copied the URL from it and pasted it to get my admin cookie, and it surprisingly worked. Now that I'm admin on the fms, I spent some time going through the extra tools I got and ended up at the file manager dashboard.
I tried uploading php shells but it didn't work, so I ended up uploading a webshell and just using that to get a shell.
After getting this shell, it was clear that I was in some kind of restricted environment because the sudo command gave a strange response that I saw before on another box. So, amongst other things (to keep this short), I checked the binaries for suid bits, and found the /usr/bin/at with suid set. /ust/bin/at is on gtfobins and should allow us to move out of our restriction. I also elevated to an interactive shell with python.
When I was enumerating earlier before moving out of the restriction, I found a binary in /usr/bin called pandora_backup. I downloaded it to my machine and did some testing, and it looks like it uses the tar command to compress files. I created a poisoned tar file and ran the command to gain root.
