To begin working on the machine, we first perform a quick scan to identify open ports using Nmap:
sudo nmap -sS --min-rate 4500 -n -Pn -vvv 10.10.11.82
Once we know which ports are open, we perform a more detailed scan on them:
nmap -sCV -p22,8000 -n -Pn 10.10.11.82 -oN target
We can see that port 8000 is hosting a web server.
Home page
Clicking on the Download App button downloads a ZIP file.
This archive contains the default structure of the web application.
Here we can see the files it contains, and after checking the requirements, we notice that it uses a vulnerable version of js2py, which can be exploited through RCE (Remote Code Execution). Exploit: CVE-2024-28397
To exploit this, we will run the provided JavaScript code inside an interpreter. Let’s register on the victim’s web application and see which programming language we can execute.
Luckily, we can execute JavaScript directly from the web interface.
It works perfectly, we can execute commands as the user app. Next, we will establish a Reverse Shell to gain access inside the machine.
We start by setting up a listener with Netcat on port 4444, and then execute the Reverse Shell payload in the exploit.
Now that we are inside, let’s remember that when we downloaded the ZIP earlier, it contained a file named users.db. At that time, it was empty since it was just the default database. Knowing its location and purpose, let’s inspect it again.
We transfer the file to our local machine for easier handling.
This is where the passwords of all users registered in the web editor are stored, including ours.
To save time, we will first check which users exist on the system so we only attempt to crack relevant passwords.
Perfect, we see that marco exists on the machine. We will use Hashcat to crack Marco’s password and see if it is reused for system login (John The Ripper didn’t work for me here).
We manage to log in without any issues, which allows us to retrieve the User Flag.
Privilege escalation to Root
Running sudo -l, we discover that Marco can run a backup binary as root without needing the root password.
This binary requires a configuration file to work. Fortunately, we already have one in Marco’s home directory. Although it is owned by root, Marco has read permissions.
(With the -h option we can see all the available parameters.)
From this, we learn that the root user employs this configuration file to back up the web application we’ve been exploiting earlier. To escalate, we can create a copy of the configuration file and modify it so that the backup targets the /root directory.
We then run the backup using:
sudo /usr/local/bin/npbackup-cli -c ./test.conf -b
Next, we list all snapshots to identify the one we need:
sudo /usr/local/bin/npbackup-cli -c ./test.conf --snapshots
Once we know the snapshot ID, we can list its contents:
sudo /usr/local/bin/npbackup-cli -c ./test.conf --snapshot-id ID --ls
Finally, we obtain the Root Flag and complete the machine.
sudo /usr/local/bin/npbackup-cli -c ./npbackup.conf --snapshot-id 0121d0a3 --dump /root/root.txt