HTB - PermX Writeup

👾 Machine Overview

This is a writeup of the machine PermX from HTB , it’s an easy difficulty Linux machine which featured RCE in an LMS, credential hunting, and exploiting a misconfigured script.

🔍 Enumeration

An initial nmap scan of the host gave the following results:

Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-05 19:13 EDT  
Nmap scan report for 10.10.11.23  
Host is up (0.033s latency).  
Not shown: 998 closed ports  
PORT   STATE SERVICE VERSION  
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)  
80/tcp open  http    Apache httpd 2.4.52  
|_http-server-header: Apache/2.4.52 (Ubuntu)  
|_http-title: Did not follow redirect to http://permx.htb  
Service Info: Host: 127.0.0.1; OS: Linux; CPE: cpe:/o:linux:linux_kernel  
  
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .  
Nmap done: 1 IP address (1 host up) scanned in 9.41 seconds

Since there was very little open on the machine, I started out by looking at the website. I had to add permx.htb to my /etc/hosts file to view the site.

🌐 Web

I poked around on the site for a while and didn’t find anything particularly interesting functionality wise, there is a contact form but I wasn’t able to do much with it.

I used gobuster to fuzz for web content on the main subdomain.

There was an interesting /server-status endpoint which did allow me to get the version of Apache the server was running (2.4.52), but that wasn’t very useful.

I used ffuf to fuzz for vHosts, and found www and lms.

🏫 Chamilo LMS

www didn’t have any new content, but lms hosted an instance of Chamilo LMS.

In the corner there’s a note than the admin for Chamilo is Davis Miller, and it links to his email [email protected].

I started searching for recent Chamilo vulnerabilities and found CVE-2023-4220 and this POC for an unrestricted file upload. The POC uploads a PHP webshell leading to RCE.

First I stood up a python web server and tested the exploit to see if I could get a callback.

It worked so I then used the exploit to download and execute a sliver beacon.

This got me sessions as www-data.

🥈 User

As www-data I wasn’t able to grab the user flag, so I started poking around the files for Chamilo to see if there’s anything interesting in configuration files.

In /var/www/chamilo/cli-config.php I found references to /app/config/configuration.php that should contain SQL credentials.

Checking out that file I found a cleartext password for the user chamilo for use on a local SQL database.

💻 SQL

I was able to use the credentials to login to the local SQL database (still from my sliver beacon, this isn’t externally accessible).

There’s a Chamilo database that I started to root through, there’s a number of tables for the Chamilo app.

I found a user table which contained password hashes, but I wasn’t able to crack them.

I got kind of stuck here for a bit, I couldn’t find anything else in the database of note. Eventually I went back to the host and found the user mtz. I tried reusing the SQL password on mtz and was successfully able to login and grab the flag.

🥇 Root

First as mtz I popped two new sliver beacons.

Next I ran LinPEAS, which flagged /opt/acl.sh as a file mtz could run with sudo.

Here’s the contents of /opt/acl.sh:

#!/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  x
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"

Looking at this script it allows the ACL for a file to be changed if it falls within the user mtz’s home directory. This allows us to grant ourselves read/write/execute permissions on any file within /home/mtz.

One way we can get around this restriction is through the use of symbolic links, or symlinks. Symlinks on linux are similar to a Windows file shortcut, they create a pointer to another file or directory.

This is useful in the case of the acl.sh script because we can create a symlink to a file within /home/mtz pointing to any other file and the script will allow us to get r/w/x.

I first tested this by creating a symlink to /etc/shadow, and was successfully able to view and edit the contents of the file.

I tried to find a nondestructive way to exploit this access, my initial thought was to edit /root/.ssh/authorized_keys and add my SSH key, but I couldn’t get this to work. I tried cracking root’s password hash, but I wasn’t able to.

I settled on removing root’s password hash from /etc/shadow, which allowed me to just login as root without a password and grab the flag.

Frankly I wasn’t super happy with this route, but it worked.

📖 Resources

🔗 Hyperlink	ℹ️ Info
B1TC0R3’s GitHub	CVE-2023-4220 POC