037#:HTB - Devvortex
Well, that last room kicked my butt. Let’s see how I fair with Devvortex on Hack the Box. I will be happy as long as I don’t run into as many technical issues with this room as I did with CozyHosting.
Cool, simple website and SSH. Let’s get gobuster running and check out the site in our browser. Gobuster fails at first, but checking nmap again we can spot the devvortex.htb domain. Adding that to /etc/hosts and we can now scan the domain.
At first pass, nothing is jumping out from the site or its source code. I’m not finding a whole lot so ran gobuster with a longer wordlist.
Nothing new there. Let’s try for subdomains then.
Sweet, we got a hit. Let’s add this to our /etc/hosts file, get another directory scan going, and then check out the site.
Exploring dev.sevvortex.htb we see two usernames, info and contact. When checking out the /administrator subdirectory’s source code I found a mention of a csrf.token value.
I made note of this and kept exploring. Most of these pages wouldn’t load for me. I got a version number for Joomla from the /README.txt page. We also find a bunch of interesting info at /web.config.txt about the security.
I’m going to start with just looking for vulns in Joomla. Searchsploit shows one that applies specifically to version 4.2.8. I can’t get anything useful from this though. Pulling up metasploit and searching for “Joomla 4” I saw an option for checking that the api was properly secured. We had found an api directory so I gave this a shot.
Whoa! Huge find there. Looks like we got two usernames and a database password. Let’s see if lewis is re-using their password for the Joomla portal.
That password works and we are greeted by the admin dashboard as well as a notice of our insecure PHP version being used. In the past, when attacking wordpress sites, I have uploaded a PHP reverse shell into the site so I’m clicking around to find a way to get my payload out there. Under the Components>Banners I was able to make a new banner. I then tried doing Insert>Code Snippet and choosing PHP as the language. Here I tried my payload.
This didn’t do anything for me though. I tried a few payload variations and moved on. I burned some time trying various techniques that didn’t work, mostly just variations of making a new web page that had my php payload in it. It never seemed to execute though, so back to clicking around the settings. In System> Templates we can edit Cassiopeia to add our own file.
Here I used pentestmonkey’s php reverse shell.
We saw the templates directory earlier with gobuster and we can see here that we can hit out payload at /templates/cassiopeia/payload.php. I go ahead and get my netcat listener started before pulling up the page in my web browser.
Sweet, we are connected. First I will want to stabilize my shell. I can see that logan user has a /home folder. The lewis password we found was for the Joomla database and is a great place to start.
We list the tables using ‘SHOW TABLES;’ and that the contents of the user table.
A bit messy to look at, but we can see the hash for logan in there. I echoed their hash value to a file named hash.txt and then tried to identify which module to use for hashcat. I think it may need module 3200 for ‘bcrypt $2*$, Blowfish (Unix)’.
There we have our password for logan and our first flag. Checking logan’s sudo rights we see something interesting.
The first thing I did was look for apport-cli on GTFObins. Nothing there, so I just ran it and then ran the –help for it. I also started just googling apport-cli to see what I could learn. I took note that it is version 2.20.11. Checking searchsploit for ‘apport 2.20’ yields one privilege escalation method.
Reading over the contents of this exploit, it looks like a pain in the toe to do manually. Instead, I opened metasploit and searched for it there.
I started a meterpreter handler and then traded out my php reverse shell for the meterpreter one.
Great, we have our session and we can now launch our privilege escalation attack. This failed though and upon inspecting the info for the module it wasn’t for the right version. For now I am going to run Linpeas on the machine and see if maybe there is a different path we can take. Early on we have a big hit for CVE-2021-3560.
When I went to google this, I realized I recently used this exploit in another room for privilege escalation. There is nothing wrong with that, but I figured I should spend more time on what looks like the intended path by using our sudo rights over apport-cli. I googled ‘apport-cli privilege escalation’ and found this NIST article. Reading over the links I wasn’t entirely sure what to do but they both showed a similar approach.
They start by viewing a crash report, but I don’t have one. I made a txt file named test.crash but that failed to load properly. I then tried looking up an example of a crash report and pasted that into test.crash but that threw a syntax error when loaded.
I started playing around, interacting with running processes using apport-cli. I didn’t have anything running though, so I first just ran python3 in interactive mode and then backgrounded it.
Looked through the help menu and tried using the various switches to interact with the running process. The goal is to get an interactive prompt going in apport-cli because it should maintain its root permissions. After a few failures, I was able to get an interactive prompt by using the –hanging switch to target my python3 PID.
We can see this also got our final flag. This was a fun room. I haven’t worked with Joomla much so it was some good practice there. Also the privilege escalation was fun as it required a bit of interpretation and tinkering. We could have also gotten root using that finding from Linpeas but I think this was the intended route.