🔎🦶Enumeration/Foothold
Seal is an Medium Linux box from HTB and created by MrR3boot. This box features a web server with an exploitable Tomcat running jmxproxy alongside nginx which we use to access the Tomcat host manager and deploy a reverse shell. Once on the box we use ansible playbook alongside a symlink to escalate.
I begin each box by running a RustScan. This is bundled into my setup.sh script which I’ve mentioned in a few of my other posts. Running RustScan with nmap filters. Reviewing the results I see multiple ports open:
Reviewing the results I see Port 80/443 open. Navigating to the HTTPS version of the site I am presented with a certificate error. Viewing the certificate provides the following information:

Shows the website seal.htb as well as a possible user.
Seeing this I add seal.htb into my hosts file:

Seal Market Vegetables Shop
Navigating to the website shows a Seal Market vegetable shop. I see when clicking Search it adds an ?+Vegetable=[input]# parameter. I note this down and kick off a FeroxBuster scan.
Next after reviewing my nmap results I can see that Port 8080 is open and shows a registration form:
I fill out the registration form and log into the website. After logging in I can see two repositories, one of which is seal_market. Navigating to it shows a ToDo and two folders:

ToDo List for Seal Market App
So this tells us a lot as we can see that both nginx and tomcat are running and that the manager/host-manager for tomcat are still available. Seeing these two items and a tomcat folder and check if any revisions exist. Using Ctrl+F to find in Firefox I search for password= as that is the string you see for tomcat based passwords.
Next I reviewed my FeroxBuster scan I kicked off earlier. It showed the manager directory unfortunately it was reporting 302.
I used FeroxBuster again on the manager directory poking at it further with a tomcat discovery list by SecLists
Seeing that I was able to hit certain modules within Tomcat I began researching nginx + tomcat exploit traversal and found a great presentation from Blackhat. I changed the url and logged into the Host Manager.
I tried uploading a reverse shell but was unable to do so as a CSRF token prevented the upload.

Tomcat host manager screen and deployed reverse shell.
I went into Burp Suite and changed the request on the upload. Reviewing the request I can see the POST request is going to /manager/html/upload which will fail as we do not have direct access. Change this to include the traversal exploit above allows the shell to be uploaded:

Burp Suite changing the request for the jmxproxy.
You can see the shell successfully uploaded:

Reverse shell uploaded on the Tomcat host manager.
🔝Escalation
I spawn a nc session and navigate over to the reverse shell page I then check /var/lib/python to validate Python3 is installed and upgrade my session:
I then navigate to the temp directory and upload LinPEAS to the box.
⚠ Attack Machine
🎯 Victim Machine
Reviewing the LinPEAS output I was was able to find both entries above telling me to focus on the run.yml file. Reviewing the file I can see that its doing a copy to move files from one directory to another. I can also see that the copy_links=yes means symbolic links are allowed.
I check the /admin/dashboard directory and notice an uploads folder with read/write access. I do a symlink to pull the .ssh directory from Luis’ home directory.
Once the backup is done being created (takes around a minute) I copy the file into my working directory under tmp
I then navigated to the uploads directory and copied the id_rsa to my attacking machine. Once on the attacking machine I set the permissions to 600 and logged into the box.
Upon entering the box via SSH I check what can be run as SUDO.
Just like the first escalation method we can use ansible-playbook as root. I create a quick escalate.yml based off the run.yml file and upload it to the host.
⚠ Attack Machine
🎯 Victim Machine
I grab both flags and finalize the box:
