Seventeen
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.227.143
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-01 05:02 EDT
Nmap scan report for 10.129.227.143
Host is up (0.0095s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
8000/tcp open http-altBased on normal HTB practice, we can add seventeen.htb to our /etc/hosts file.
Web Ports -> Subdomain Enum
Port 80 hosts a education based website:
The Github tag there is to the creator's own repository, so there's nothing to investigate there. There isn't much on the website aside from the usual. Let's move on to port 8000.
Perhaps we need to gain access and do port forwarding for this later. For now, we can fuzz for both subdomains and directories within the main website itself.
A directory scan reveals nothing, but the subdomain scanner finds an exam.seventeen.htb to exist.
Exam Management
The website is hosting some kind of exam reviewer software.
A quick search via searchsploit reveals that there are exploits for this software.
We could try the RCE one, but we don't have any credentials. As such, we can grab the SQL Injection one first. Following the PoC, we have to run this command:
Success! This works and we can try to dump the database. Using sqlmap, we can slowly enumerate the database:
So now we have some password hashes and usernames. However, none of these can be cracked using Crackstation, and john didn't manage to work either. In this case, it seems that our RCE won't work because we cannot get the required admin credentials.
The most interesting part of this was the avatar column, which a directory within ../oldmanagement. Most of the time, within Linux servers, it is hosted at /var/www/html. In this case, because we have an exam subdomain, it's probably in /var/www/exam. So, the avatars are located within /var/www/oldmanagement and might be under the subdomain of oldmanagement.seventeen.htb.
School File Management
When we add the new subdomain to our /etc/hosts file and visit it, it brings us to a new login page.
Now there's another management system, and we still have SQL Injection within the exam system to find the passwords needed. We can continue to enumerate that database:
The hashes in the user table cannot be cracked. However, the hash for Kelly within the student table can be cracked.
Using this, we can login to the school system.
Based on the theme of this box, we can search for more exploits regarding the software used here:
No exploits here do RCE, so let's move past this. As we can see from above, there's a PDF file within the system. We can download it, and when viewed it has this message at the end:
It appears there's another subdomain for an email client at mastermailer.seventeen.htb.
Webmail -> RCE
When we visit the new subdomain, we are presented with antoehr login page.
A quick inspection on the page source reveals this is using an application called RoundCube.
The page source also tells us this is RoundCube version 1.4.2. When searching for exploits, we can come across this:
It seems that we can use directory traversal to execute code via a file we upload. At the same time, the school application allows us to upload files to the machine. So for this case, we need to chain the 2 vulnerabilities together to get RCE.
So first, let's determine what kind of files we can upload to the school system. Based on searchsploit, it appears that it is a PHP-based website, so let's try to upload a PHP reverse shell. First, we can download the source code from here:
download.php is the code that handles uploads, and here's the contents of it:
We find that it stores the uploads at /files/<studentID>/uploads. We can then verify the upload works by uploading a malicious papers.php. This name is required based on the PoC requiring our PHP file to have the same name as the directory it is in. This just contains a basic shell executed by PHP system calls.
Great! However, when I tried the exploit the first time, it wouldn't work for some reason. Turns out, we did not find the right directory where the files are stored. Running a feroxbuster scan for the upload directory would reveal another one.
The /papers directory seems to be where they are stored. After that, we can perform the RCE. Following the PoC, we need to send this POST request via Burp.
After sending this, we just need to reload the page and we would catch a reverse shell.
Docker Breakout
SSH Credentials
Notice that we are in a Docker container, so we need to find a way to escape. There was another file within the /var/www/html folder.
Within the /employeemanagementsystem/process/dbh.php file, we can find some credentials:
Interesting, however this doesn't work when I try to su to root on the Docker. Instead, let's take a look at the users present because this might be their SSH password.
The /home directory is empty, so let's examine the /etc/passwd file to see if we have any users. At the very end, we see a user called mark. We can login as the user using this password.
Then, grab the user flag.
Privilege Escalation
DB-Logger Credentials
Within the /home directory, we find another user called kavi.
Within the user's home directory, there are some hidden directories:
There was nothing in them though. I checked netstat -tulpn output, and it revealed some hidden ports:
We can check all of them to see what's running. Port 4873 was running another HTTP site based on curl.
As such, we can do some port forwarding using ssh. Viewing it reveals some sort of pacakage manager for NPM.
Within the /opt/app directory, there's a startup.sh script:
This seems to check for the db-logger and loglevel NPM modules, and then runs an application using them I presume. Also, I found some mail for the kavi user in /var/mail:
"Private registry" and "old logger" are probably referring to the website on port 4873 and the db-logger module. We can try to install the db-logger module from that website using this command:
When we view the files, we see this:
We can use that password to su to kavi.
NPM Module RCE
This user has sudo privileges to run the startup.sh script.
I already included the contents of the script above, but basically it checks for two modules db-logger and loglevel, and installs them if they are not present. So to exploit this, we probably need to run this as root and get the machine to install a module for RCE.
Within that directory, we can also see an index.js file that calls for uses the loglevel module:
Take note that this index.js is run right after the modules are downloaded using startup.sh, so that's where our module is loaded and we can execute code as root.
First, let's create the logger.js file:
I added some dummy functions in order to make sure the application does not crash when we run it since index.js calls those functions from the module. Then, we can create a package based on this.
Now, we need to edit the .npmrc file that specifies where the registry is. This is located within kavi home directory
Edit this to point to our host on the same port. Now, we need to host the Verdaccio instance.
Then, we need to publish the module there:
Afterwards, simply run the startup.sh script.
Now that the application is running, it means that the module is loaded and our command has been executed and we can get an easy root shell.
Rooted!
Last updated