top of page
BlueDolphin

Hack the Box - Pandora

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

  1. Nmap for standard port discovery

  2. In-depth scan for more.

  3. 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
  1. Run nmap over the UDP port

  2. Run SNMP enum tool (snmp walk)

  3. Research SNMP Community Strings

  4. Confirm community string

  5. 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@targetip

We 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
  1. Identify version at the bottom of the page

  2. Research version and identify backend system

  3. Research CVE-2021-32099

  4. Capture with Burpsuite

  5. Use SQLmap sqlmap -r sql.txt --dbs --batch

  6. Enumerate tables with sqlmap -r sql.txt -D pandora --tables --batch

  7. Dump table sqlmap -r sql.txt -D pandora -T tsessions_php --dump --batch

  8. Steal the table with cookies

  9. Refresh page and visit login as matt

  10. Pivot to exploit here https://github.com/ibnuuby/CVE-2021-32099 and try again with cookie

  11. Admin tools >> Filemanager

  12. Upload malicious PHP reverse shell

  13. 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
  1. Upgrade shell to python shell

  2. Identify SUID binary - pandora_backup

  3. Upgrade to SSH by dropping pub key into user or matt folder

  4. Troubleshoot binary with ltrace and alternative

  5. Observe system call to tar without full path

  6. Identify path hijacking

  7. 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:$PATH


We then create a var folder and run pandora_backup as root :)


57 views0 comments

Recent Posts

See All

Comments


bottom of page