Hack the Box - Pandora
- BlueDolphin
- May 28, 2022
- 6 min read
Updated: May 29, 2022
Engagement flow
Tools used
Autorecon
SNMPwalk
SSH
Processes/Techniques
UDP port scanning
SNMP enumeration
Port Forwarding
SQL Injection
Session hijacking
Malicious file upload
SSH key authorization
Path Injection
References
https://www.dnsstuff.com/snmp-community-string
Summary
This was a very difficult machine to be placed in the easy category. It was however a wonderful experience in the end. We started simple with a small attack surface of 3 ports. The final port, an SNMP UDP port 161 was discovered thanks to autorecon. Leveraging SNMP walk revealed credentials as user Daniel. This provided ssh access to the target. From here there was an internal SQL DB running on port 3306 and a second webpage on port80. By forwarding the port we could view this second webpage. It was running pandora fms and we found several public CVE's. By leveraging an SQL CVE we were able to steal the admin session cookie and take over the session. This provided the access to admin only tools, to upload a file as a reverse shell.
Having gained access to the box now as use matt we proceeded to enumerate internally. We quickly found a SUID file "Pandora_backup".
Enumeration
Nmap for standard port discovery
In-depth scan for more.
Autorecon UDP161 discovery
Starting off with a basic nmap scan we reveal only 2 ports. This is a very narrow attack surface.
Performing a more in depth scan reveals our webserver on port 80 is running apache 2.4 which are latest patches at the time of the blog.
From here we run autorecon to work in the background.
Autorecon reveals port UDP161.
We could also manually run a UDP scan and find port 161.
└─$ sudo nmap 10.129.102.211 -v -sU
SNMP Enumeration / Initial Access
Run nmap over the UDP port
Run SNMP enum tool (snmp walk)
Research SNMP Community Strings
Confirm community string
Run SNMP walk with community string for credentials
SNMP
Simple network management protocol is a common networking protocol utilized for managing and monitoring network connected devices. The SNMP protocol is often found in enterprise equipment such as firewalls, servers, routers and even switches. The protocol is multi-vendor over LAN and WAN environments. According to the OSI model this is an application layer UDP protocol. Because SNMP does not utilize TCP, there is no error checking or SYN/ACK. It is a connectionless protocol.
Various applications use the SNMP protocol to provide a service. This can be found in the SolarWInds Network Performance Monitor for example. It uses the SNMP protocol to build and visualize your environment in a user friendly web portal. SNMP is also utilized by ManageEngine OpManager, whats up gold or even the Cacti device tracking software.
These applications when conjoined with the SNMP protocol underpin any large scale device management processes in enterprise environments. They collect and structure information about devices on the network. The information provided in the SNMP protocol is structured around OID's. They are identifiers in a simple sense. Vendors will often provide a MIB file which specifies which OID's are in use by their application or device.
SNMP Community Strings?
There is also what is known as the SNMP community string. In a sense, this is a verification process. You can set a device to only accept SNMP requests with a specific "Community String" that you define for your product. Quite often the default Community String is "Public".
Performing an nmap scan on the SNMP port UDP161 reveals further information. We have to remember that the server has intentionally been configured by an administrator or via the installation of an application to broadcast SNMP information. So we want to capture that information in order to progress to the next phase of this engagement.
We perform SNMP enumeration with SNMPwalk
A little research provided this great example as a use case.
As I continue to sift through the information and many times over. I finally found Daniel's credentials when doing a cat | grep daniel command.
From here we SSH into the box.
Internal enumeration
1. Check /var/www/ and observe multiple sites.
2. Check /etc/apache2/sites-enabled/
4. Check open ports
5. Check /etc/hosts
6. SSH port forward
7. Observe version number and research for valid CVE
We start off by observing multiple entries for the /var/www folder.
From here we pivot and check the "sites-enabled" directory where we find two config files.
Taking a look at /etc/hosts we see several new domains! It appears the domains are running on a different port than the pandora domain.
My next step was to identify what ports were open to suggest where we could find our second website. However I was quite confused when I checked using the netstat command and found port 80. However, I did notice that port 3306 was open which suggests something internally has a SQL DB.
From here we forward the port so we can view the website at the application layer.
ssh -L80:127.0.0.1:80 daniel@targetipWe can confirm the port forward worked by checking our local ports.
We see that 127.0.0.1:80 maps to our ssh connection.
We browse to localhost:80 and huzzah! The first thing I noticed was a version identifier at the bottom.
Web exploitation / User
Identify version at the bottom of the page
Research version and identify backend system
Research CVE-2021-32099
Capture with Burpsuite
Use SQLmap sqlmap -r sql.txt --dbs --batch
Enumerate tables with sqlmap -r sql.txt -D pandora --tables --batch
Dump table sqlmap -r sql.txt -D pandora -T tsessions_php --dump --batch
Steal the table with cookies
Refresh page and visit login as matt
Pivot to exploit here https://github.com/ibnuuby/CVE-2021-32099 and try again with cookie
Admin tools >> Filemanager
Upload malicious PHP reverse shell
Receive with listener
The first thing we noticed is a version identifier at the bottom of the page.
We copy and paste this identifier into google and immediate get a CVE recommendation for pandora. I toiled away with the CVE's below and was not able to make any progress. I decided to pull up and index of all available vulnerabilities for Pandora FMS.
After reviewing and trying several, I eventually came across this SQL injection CVE. I was drawn to this CVE as it was quite simple. Confirm the directory is reachable, capture with Burp and feed to sqlmap.
Browsing to the provided and vulnerable directory yield a successful resolve.
I confirmed the php session id is indeed present.
We check the site request with burpsuite and confirm the PHP session ID again.
If we add the session_id query with an arbitrary character we see that a cookie for PHPSESSID is provided right away.
From here we save the request and pass this to sqlmap.
sqlmap -r sql.txt --dbs
We followed up by dumping all tables.
sudo sqlmap -r request.txt -D pandora --tables
Unfortunately we have over 150 tables. So we have to pivot and start going through them.
Eventually we come across tsessions_php loaded with session cookies. We take the cookie utilized by matt as we have already identified matt as one of the users other than daniel on the target. Simple paste this session cookie and refresh the page.
Here we have portal access as user Matt. I was not able to get anywhere further from here.
Doing some more research showed an existing exploit crafted to fetch the admin cookie. This actually worked and I had admin access to the backend.
https://github.com/ibnuuby/CVE-2021-32099
From here I learned under Admin Tools --> File Manager --> upload php reverse shell. We notice that our USER shows as daniel but we have user matt when we run whoami.
Root
Upgrade shell to python shell
Identify SUID binary - pandora_backup
Upgrade to SSH by dropping pub key into user or matt folder
Troubleshoot binary with ltrace and alternative
Observe system call to tar without full path
Identify path hijacking
Create malicious pandora_backup and update environment variable
First we establish a small degree of persistence and upgrade our shell.
python3 -c 'import pty; pty.spawn("/bin/bash")'
We upload and run linpeas eventually to observe an interesting backup file with SETUID permissions.
We look at the permissions on the pandora_backup
Take a look at the file content.
Attempting to run the program failed.
Attempting to run as sudo to leverage the SUID permissions renders a permissions issue.
Researching this error lead to The Apache 2 ITK MPM variable.
From here we upgraded our shell to an ssh shell.
This was accomplished by generating a key as user Matt, copying the .pub to the authorized_keys file. Setting 600 permissions on authorized_keys and 700 permissions on /home/matt/.ssh.
Became
We now have an ssh shell.
From here we were able to run the pandora_backup binary. We notice the binary is calling tar from the command line without and absolute path. This allows for path injection.
From here we create a custom environment variable with
export PATH=/tmp:$PATHWe then create a var folder and run pandora_backup as root :)
Comments