Today we’ll be going through the Pandora machine from HackTheBox. This is an easy machine with a relatively simple foothold, if you remember to do your enumeration. Once on the machine, we have to do some port forwarding to expose an internal service. After compromising that service, we find that we have elevated our privileges on the server, but not to the root user. The second privilege escalation involves yet another SUID binary to finally get root.
We’ll start off with some nmap scans to see what’s all running.
Do a baseline scan with scripts and service detection.
Do a scan for all TCP ports to make sure we didn’t miss any.
With only two ports open, and one of them being SSH, we’ll go check out what’s on the HTTP port
On the home page, we spot a potential domain name, panda.htb. We will add this to our hosts file. If you look back at my nmap screenshots, you’ll see that I already did this and it printed the domain name name in some of the output.
sudo vi /etc/hosts
Make edits to the host file such that the line for panda.htb looks like this.
Although, typing panda.htb in our web browser and hitting Enter doesn’t turn up anything different.
I tried to enumerate some directories using gobuster, and the only entry found with the wordlist I used is the “assets” directory, which didn’t hold anything super interesting.
gobuster dir -u http://10.10.11.136 -w /usr/share/seclists/Discovery/Web-Content/common.txt -t 20 -x txt,html,js
Not pictured here, but I fired up BurpSuite and intercepted traffic when going through the contact form and other links on the page. Nothing special there either. Seems like there isn’t a whole lot to enumerate on this website.
As a last resort, I ended up running nikto, which told me that the target might be running WordPress. The output didn’t look promising, but I ran wpscan anyway, which just immediately told me it’s not running WordPress.
nikto -host http://10.10.11.136 -output nikto.txt
So now what? Well, when TCP ports aren’t giving you anything to work with, you should start to scan for UDP ports.
sudo nmap -vv --reason -Pn -sU -A --top-ports=20 --version-all -oA nmap/pandora-udp-top-20 10.10.11.136
There’s quite a bit of output here so we’ll cut to the interesting stuff.
Port UDP 161 (SNMP) is open, and nmap has already run some scripts to discover processes on the target over the SNMP protocol. If we scroll down more…
Uh oh, it looks like a user named daniel has included their password as a command line argument to run a process called host_check. We’ll check to see if we can login to their account via SSH using these credentials.
Sure enough, the creds work! Time to check out what else is happening on this server. We’ll see if there are any other users by listing out the home directory. When doing this, we find another user named matt. Listing processes owned by matt is a good next step, and we can see that they’re running apache web server.
If we take a look in the web content directory, there are two different web apps present. The html directory looks like the site we were looking at earlier, but pandora is something we have not seen yet, and it’s owned by matt.
This website is most likely only available internally to this web server, since we did not see an open port for it in our earlier scans. As a simple test, we can curl localhost. It tells us that we should be going to the pandora_console directory, so we modify our curl command, run it again, and we get the source code to a web page.
Nice, we’ve found something called Pandora FMS and it’s console homepage. We need to take a closer look at this, but we can’t do that too well in our SSH terminal with it running locally on the server. Lucky for us, SSH has the capability to tunnel this service to our Kali box for further testing.
What we’re going to do next is called local port forwarding via SSH. This command tells SSH that once we login to the target, please forward whatever is on localhost port 80 and run it on our local (attacker box) port 80.
After entering daniel’s password, a regular SSH login greeting appears. Good, now we’ll leave this SSH window open because it is actively doing the port forwarding for us. We can check this by using a web browser on our attacker machine and going to localhost port 80.
We get redirected to the Pandora console, which means our port forward worked! We notice the version number of the software is at the bottom of the page – v7.0NG.742_FIX_PERL2020.
Currently, we don’t have any creds to login. With searchsploit, we can see if there are any unauthenticated exploits for this version of Pandora.
There are quite a few exploits list, but not what we want. From what I can tell, none of them are really what we are looking for. These exploits are either for the wrong version of Pandora, require us to be authenticated, or are not something useful to us right now (ex: Cross-Site Scripting).
So, we’ll result to good ol’ Google and simply plug in the version number and the keyword “exploit”. It looks like there are some public exploits available that weren’t on the searchsploit list. There’s a GitHub repo with some exploit code and a blog that explains an unauthenticated SQL injection. They sound like something we want to look more into.
GitHub repo: https://github.com/shyam0904a/Pandora_v7.0NG.742_exploit_unauthenticated
Blog page: https://blog.sonarsource.com/pandora-fms-742-critical-code-vulnerabilities-explained/
Let’s give it a shot. Clone the GitHub repo. I prefer to organize code like this in the opt directory.
cd /opt
git clone https://github.com/shyam0904a/Pandora_v7.0NG.742_exploit_unauthenticated.git
Reading the sqlpwn.py code we just downloaded, we can see it’s going to give us an interactive shell with two steps:
- It first uses the unauthenticated SQL injection to bypass the login and impersonate the admin user. As described in the blog, the ‘session_id’ parameter is injectable, so the code takes advantage of that to get us an admin cookie.
- Next, it crafts an HTTP POST request with what appears to be a php web shell as the data payload. The endpoint it is posting to looks like a file upload capability, and by sending the admin cookie along with the POST request, it will think we have permissions to upload any file we want (in this case, the web shell).
From there, it’s as easy as sending Linux commands through our fancy interactive web shell.
Nice! We’re executing commands as matt, since that’s the user the Pandora software is running as on the server. This is nice and all, but we want a more stable shell. This user has a home directory and the SSH port is open, so as usual, we’re going to drop an SSH key.
Notice how when sending the echo command with the public SSH key, the plus signs in the key are URL encoded as %2B. This is because we are technically using a web shell, and + is interpreted as a space when using URLs. So to avoid that from happening, we encode it as %2B, which is then converted to +. We use the cat command to double check it was stored properly on the server. Make sure you use your own public SSH key and not the one shown here.
After we confirm that the public key looks good, we’ll use our private key on our attacker machine to SSH in as matt. We’re in. Don’t forget to grab the user flag!
While doing local enumeration as matt on the server, we come across an interesting SUID binary called “pandora_backup”. A simple command confirms it is in fact owned by matt
We’ll want to grab a copy of this binary and put it on our attacker box for further examination. The target machine doesn’t even have basic tools for this installed, like “strings”. Luckily, SSH comes to the rescue again. We can use scp to securely transfer the file.
Once the file is transferred, we will use strings as our first tool to see what’s all going on inside. Right away, we see a tar command, which looks to be backing up everything in the pandora_console directory and zipping it up into a backup directory owned by root.
There’s one pretty big flaw in the tar command listed here – it isn’t using an absolute path (ex: /usr/bin/tar). Because of this, we can easily create our own tar binary, add its directory to our path, and have the pandora_backup binary execute our malicious tar binary rather than the “real” one they wanted to execute.
I’m going to use /dev/shm as the directory, since that’s what I’m used to using for temporary file creation. We’ll create a simple shell script that pops a bash shell. We’ll also add /dev/shm to the beginning of our PATH environment variable so that the operating system will look there first for the tar binary, before going to any other directory listed there.
With our malicious tar binary in place and PATH variable modified, all we have to do is run the pandora_backup command. Because we hijacked the path to tar, when it comes time for the routine to execute tar, our shell script is executed instead. We now have a shell with root privileges! Grab the root flag.
Key Learnings
- If a port isn’t required for any functionality, don’t leave it open. In this case, port UDP 161 is sometimes needed for some SIEM log ingestion functionalities. If leaving this port open, a more secure of accessing credentials should be used, such as an environment variable. Although, environment variables aren’t always the answer, and they should generally be avoided, especially if using a version control system such as git
- Always keep your software up to date, especially when there are high risk vulnerabilities published for your version that are easy to exploit. In this case, it was the unauthenticated SQL injection for Pandora FMS
- Use absolute paths when executing binaries. Path hijacking will no longer be an option if you are specific in what you want to execute