Hack The Box: Pandora
Hack The Box: Pandora
Pandora is an easy rated, now retired machine on Hack The Box. The community seems to have given this machine rating to more on the medium side of difficulty, so I was excited to see if I could crack into this box!
Enumeration
First things first, let's get an Nmap scan going.
From the TCP results, we only have SSH and a web server open. Heading over to the web server, we are greeted with a nicely laid out page.
But, after some enumerating there doesn't seem to be anything useful here so at this point, I decide to run an Nmap scan on the UDP ports.
Awesome, now we have something. We can see that UDP port 161 is open, which is a port associated with the SNMP protocol. We can see that it's running SNMPv1 which provides no encryption, and it looks like Nmap was starting to pull back some information from the MIB already.
Knowing that there is a public SNMP password (called a 'community string',) we can use a tool called onesixtyone to attempt to crack it. Now, the default string is "public" and given that Nmap was already pulling back information, I would assume it's probably still set to the default. However, we can just run this to check (and just for practice.) I'll be using the default 'dict.txt' wordlist provided by the creators of onesixtyone.
As we can see, it's definitely set to public, so lets enumerate this using snmp-check. I run this command and pipe the output to a text file.
You can see that snmp-check was able to pull back currently running processes, and we can see one where some credentials were passed as an argument. For the heck of it, let's see if we can SSH into the machine with this username/password.
Success! Awesome. Let's see if we can snag a user flag.
Well, I guess that would have been TOO easy, haha. From the image above, you can see that there is nothing in the user "Daniel" home directly, but that there is another user "matt" and the flag is in their home directory. Unfortunately, we can't read the "user.txt" file unless we're Matt, so back to enumerating!
After some other enumerating, I check for active ports/connections and I notice that there is a webserver being hosted on the loopback (localhost) address.
So, I close out my SSH connection, and start up a new one. However, this time I use the -L switch which will initiate a local port forwarding of the Pandora's webserver (specifically, the one being hosted on Pandora's loopback) back to a port I specify. To note, I use port 8081 as the local port to forward to since Burp Suite uses 8080. I could change that on the Burp side, but this was easier :)
Exploitation
Alright, so we're greeted with a login page for Pandora FMS, a network monitoring tool (which now explains the name of the box, and port udp/161 being open.)
I notice that we are on a page in the "pandora_console" directory. I use my SSH terminal to browse to /var/www to see the structure laid out, and I find the directories.
If we check the permissions on everything in this folder, we can see that everything on this web-server is using the user "matt." Boom, I'd say we've found the path to escalate our privileges here.
If you go back to the login page on the webserver, you can see the Pandora FMS version that this is. A quick google search reveals a SQLi vulnerability in the session_id parameter of /include/chart_generator.php, which leads to a login bypass.
I wanted to just double verify that this server was vulnerable, so I went to /include/chart_generator.php and ran a single quote as my parameter to test. Sure enough, it was vulnerable!
From here, I head to the first repository listed in the prior image which provides a payload to input which will initiate the login bypass.
We duplicate the Pandora FMS homepage and once we query this, we will refresh the duplicate and according to this, we should be logged in as admin. Let's give it a shot.
Success!! We have officially bypassed the login, and are currently logged in as the admin!
At this point, I start looking up more vulnerabilities, but everything else that I'm finding requires authentication. Given that we bypassed authentication, none of these exploits were useful to me as we don't actually have the users password. So, my next thought is to look for somewhere that I can upload files to.
I ended up finding a File Manager under the "Admin Tools" portion of the application where I was able to upload files to. I select a PHP reverse shell script to see if it will accept it.
It successfully uploaded the PHP file!
Now, I just needed to figure out where it uploaded to. I go back to my SSH connection where I'm logged into the server as "daniel" to find where this is. I end up finding it under the "images" directory, and was indeed owned by Matt!
Boom! We have a shell as the user "matt" and we can go snag the flag!
Post-exploitation
As I'm enumerating as Matt now, I find that there is a binary called "pandora_backup" that has an SGID bit set.
I check the permissions of this binary, and sure enough, the "matt" group is able to run this command with the SGID bit set!
I attempt to run it, but am faced with a "Permission Denied" mesage which is odd, because I should be able to run this.
I tried running a sudo -l command to test if sudo would work at all, but it appears that it's not working for my current shell.
But, if I went back to my SSH connection as the user "daniel" and ran sudo -l, it worked.
I knew at this point, I wanted to just log in as "matt" via SSH to use the same terminal as "daniel" (which would also provide me some persistence as well, avoiding having to locally forward the servers webserver to me, re-run the SQLi, and then re-run the PHP script just to get back on if for some reason I'm kicked off.)
I am able to generate some SSH keys as Matt, and I copy the private key over to my attacking machine.
So, I decided to create my own SSH keypair on my attacker machine, and copy the public key that is generated over to Matt's Authorized keys file.
Now, I went back and tried to SSH into the machine using the private key that I had generated from Matt.
Success!! We have successfully logged in as Matt via SSH! I test and run sudo -l to see if sudo will work now. It does! We can now proceed with elevating to root!
So now I run this binary to see what it does, and it looks like it just copies the entire "/var/www/pandora/pandora_console" directory! If I cat out the binary, I am able to see that it is using Tar to do so.
I first add my home directory to my PATH variable.
Then, echo "/bin/bash" and pipe that to a file called "tar" and I make that file executable
Then, I just run the pandora_backup binary.
Yes!! We have successfully gained a shell as the root user! Let's go snag the root flag!
Conclusion
Overall, this has to be my favorite machine that I've tackled to this day. This machine had a ton of steps, and really tested your ability to enumerate and think outside the box. To recap, we were originally able to gain an initial (very limited) foothold by exploiting an insecure protocol to gain some credentials that were passed as an argument for a system task. We then were able to locate a webserver only hosted on the loopback address that was vulnerable to a SQL injection which gave us the ability to bypass authentication and login as the admin of the application. We then took advantage of the site not having any upload restrictions to upload a reverse shell which would provide us the first step in our privilege escalation. Finally, we were able to take advantage of a system binary being ran by the super user as we were able to make a malicious file with the same name, and add that path to our PATH variable. This way, when the script ran and it attempted to use the Tar binary to do the backup, it would find our malicious file with the same name first and run whatever we supply inside the file. I am very pleased to have finished this machine, and can not wait to jump into the next one! Thank you very much for taking the time to read my walkthrough, and I hope this helps anyone who may need it!
