🔎🦶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: