Deployable is a beginner windows box from cyberseclabs.co.uk hosting a tomcat server with default creds we can use to gain an initial shell and then execute an unquoted service path to elevate our privs. Let’s get to it!

Recon

We’ll start off by starting up autoenum (found here) and passing the IP of the box.

After the IP of the box has been supplied, you can choose the scan profile to use (I default to aggr) and let it do its thing.

PORT      STATE SERVICE            VERSION
135/tcp   open  msrpc              Microsoft Windows RPC
139/tcp   open  netbios-ssn        Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds       Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
3389/tcp  open  ssl/ms-wbt-server?
|_ssl-date: 2020-09-01T20:11:07+00:00; +1s from scanner time.
5985/tcp  open  http               Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
8009/tcp  open  ajp13              Apache Jserv (Protocol v1.3)
|_ajp-methods: Failed to get a valid response for the OPTION request
8080/tcp  open  http               Apache Tomcat/Coyote JSP engine 1.1
|_http-favicon: Apache Tomcat
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/7.0.88
47001/tcp open  http               Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49152/tcp open  msrpc              Microsoft Windows RPC
49153/tcp open  msrpc              Microsoft Windows RPC
49154/tcp open  msrpc              Microsoft Windows RPC
49155/tcp open  msrpc              Microsoft Windows RPC
49156/tcp open  msrpc              Microsoft Windows RPC
49163/tcp open  msrpc              Microsoft Windows RPC
49164/tcp open  msrpc              Microsoft Windows RPC
 

The msrpc ports don’t usually have anything so we can ignore those. The WinRM ports (5985 + 47001) we want to look at for post-exploitation, not so much gaining a foothold. We can check the smb ports (139 + 445) but this doesn’t give us anything back as we’ll need creds to move forward on this route. We can check this by running smbclient -L \\\\172.31.1.13\\. This leaves us with ports 8009 and 8080, which are both http ports. Taking a closer look, we can see that 8080 is hosting Apache Tomcat, which is notorious for a featuring allowing us to upload a war file.

Waging War on Tomcat

Heading on over to the tomcat dashboard located at http://172.31.1.13:8080/, we’ll be greeted with the following.

Clicking on any of the three buttons on the right will open a login prompt (Though all three will prompt the login, Manager App will take us directly to where we want to go). After a little while of looking around and trying the usual suspects, I found this. Going down the list, we’ll find out that tomcat:s3cret gets us in. Now that we have the creds, let’s use them for the Manager App (If you haven’t already). Once we’ve entered the creds we’ll have access to a page that looks like this.

Scrolling down the page, we’ll find the feature we want.

We can see that we can deploy a war file to the server hosting the tomcat instance. We’ll create a malicious war file using msfvenom. The syntax for that can be found here.

Now that we have the malicious shell, we’ll start up a listener and upload the file. Once the file is uploaded, we should be able to see its location in the Manager App menu.

After verifying the file was uploaded, we’ll go to the directory where the shell should be and check our listener

We have a user shell!

Priv Esc

Now that we have a shell on the box, we’ll run the usual commands and go from there. Checking systeminfo tells us that this box has quite a few hotfixes and the architecture is x64. Moving onto checking the privs we come across something interesting.

Looks like we can exploit potato on this box (refer to potato write-up for more details on this). We’ll keep looking around but take note of this. Let’s get winPEAS (found here) on the box and see if it picks up anything. We’ll transfer it over using certutil and host it on py http server.

Now that we have it on the box, we’ll run it and give it a few minutes to work its magic.

Looks like we have a service with “No quotes or Spaces detected”…ok so why do we care about some service with no quotes or spaces detected?

Unquoted Service Path

This “No quotes or Spaces detected” warning is actually a good thing for us. It means we may be able to execute what’s called an unquoted service path. An unquoted service path is a vulnerability that arises when the path of a service has spaces and its not encased in quotes. The last part is important because of the way windows such interprets files. Let’s take a closer look at the path of this executable to make sense of all of this:

C:\Program Files\Deploy Ready\Service Files\Deploy.exe

As stated before, this is good news for us because of how windows interprets, or rather executes such services. But how does windows do this in such a way that it benefits us, the attacker? We already know that this path is not surrounded by quotes, meaning its not being treated as a single string, this is where the issue arises.

If this path is not being interpreted as a single path, then logic dictates it’s treated as more than one. But more than one what? There is only one path present…or is there? Taking another look at the path we can see that it is separated by spaces, three spaces to be exact. Instead of removing the spaces and windows treating this as C:\Program Files\Deploy Ready\Service Files\Deploy.exe, it treats it as the following:

C:\Program.exe
C:\Program Files\Deploy.exe
C:\Program Files\Deploy Ready\Service.exe
C:\Program Files\Deploy Ready\Service Files\Deploy.exe

Windows treats each space as it’s own executable and since there is more than one space it goes down the list executing what’s before the space before getting to the actual executable Deploy.exe.

Enumerating Deploy.exe

Now that we know what it is winPEAS was trying to tell us, we still have to do some enumeration on the Deploy service. We’ll use a util from Windows Sysinternals called accesschk.exe which can be found here. Once downloaded, transfer it over the same way we did with winPEAS.

Once we have accesschk.exe on the machine, we’ll use it to see what kind of permissions there are on this service and what kind of access we have to this service. If we can’t start the service, we’ll have to resort to a potato attack.

Looks like our user (DEPLOYABLE\tomcat) has start/stop perms, let’s take a look and see if we belong to any groups with any more access.

According to this, we belong to the NT AUTHORITY\SERVICE group, meaning we also have all the perms listed under NT AUTHORITY\SERVICE in the accesschk query. This isn’t too important as we already had the start/stop perms. The config perm would’ve been useful if the service path quoted but its not (this is beyond the scope of this write-up, feel free to read up on modifying the bin path of a service if you’d like to know more about how we can use the config perm).

Escalating with Unquoted Service Path

We know what an Unquoted Service Path is and that we have start/stop perms to the Deploy service, let’s use this to elevate our shell. We know that when running the Deploy service, windows follows this path to execute:

C:\Program.exe
C:\Program Files\Deploy.exe
C:\Program Files\Deploy Ready\Service.exe
C:\Program Files\Deploy Ready\Service Files\Deploy.exe

The next thing we have to do is see which directories we have access to.

Looks like we can’t mess with Files\ but we can cd into Ready\. Referring back to the list, we can see that Service.exe is executed in this directory. Let’s generate a shell and name it Service.exe that’ll execute when we start the service.

We’ve generated the shell so all that’s left is to move the shell to it’s place, open a listener, and start the service.

All that’s left is to open the listener and start the service.

And we have a system level shell!