Hack The Box - Jerry

DISCLAIMER: I am not an expert penetration tester. For all thoughts, opinions, insights, tools, techniques, tactics, hashtags mentioned below, do verify with industry standard resources and references. Methods below are for educational purposes and should not be used outside of a practice lab environment or without the express written consent and authorization of all parties involved. This is my journey to develop as a pentester, internalize methodologies, and attempt to give back to the infosec community by teaching what I learn along the way.

Name: Jerry
OS: Windows
Difficulty: Easy
Release: 30 Jun 2018
IP: 10.10.10.95

Hacker Status: Noob 

Scanning

Nmap scan to identify open ports, services running, and operation system information.

'nmap -A -T4 10.10.10.95'

Only port 8080 is open running an HTTP service. From the scan output, it appears that a web server is running an Apache Tomcat/7.0.88 web service with a default webpage.

Enumeration

We go to the HTTP webpage running on port 8080 to validate our scan results and further enumerate service information. This is indeed a default Apache Tomcat/7.0.88 web page. We are immediately drawn to the 'Server Status' option on the right side of the page

Clicking on 'Server Status', we are then prompted with a login prompt requiring authentication.

Gaining Access

Having nothing to go off of, we simple type in 'admin' 'admin' as the credentials to see if there is default creds access on the default Apache webpage.

Success! Now we are able to view the status of web server and gather further information about the target's operating system version and architecture.

Enumeration

After exploring the links under the 'Manager' header, it appears that this portal is document repository as well. Remembering that there were manager portals on the home page, let's go back to the home page and check out the 'Manager App' portal.

We are prompted again with the login window to enter credentials. Naturally, we try the 'admin' 'admin' credentials to see if they are the same default creds.

Unfortunately, the credentials were not the same for the 'Manager App'. But in the '401 Unauthorized' webpage response we see another set of credentials 'tomcat' and 's3cret'. So let's test these new credentials out and try again to login into the 'Manager App'.

Voila. We are in the web application manager portal.

Scrolling through the portal we come to an interesting section labeled 'Deploy' where we are able upload a WAR file document.

This being a web app, our first thought should be we could use this function of the application to upload a malicious script to produce a reverse shell back to our attacking machine.

Not exactly sure what a 'WAR' file is, we go to Google to get a better understanding of this file format.

Looking at the search results, it becomes evident that the path forward here is to create a WAR file payload.

Exploitation

To do this we want to utilize msfvenom to generate a payload that will be compatible with the target web server, and upon execution, create a reverse shell that is also compatible with our listening attacking machine.

Luckily, we search for msfvenom cheat sheets online and copy the example the msfvenom syntax provided to generate a WAR file payload.

Taking the the msfvenom example WAR payload syntax, we then input our listening host machine (attacking machine) and listening port into the command.

The command reads as, we are going to run msfvenom to create a java/jsp_shell_reverse_tcp payload (-p) for our listening host and port, formatting (-f) the payload as a WAR file and saving (>) the input as a 'shell.war' shell in the current attacking machine's directory.

Now that we have generated our WAR file payload. We navigate back to the web app manager console, select 'Browse' under the 'Deploy' section and upload our 'shell.war' payload file onto the web server.

Once the malicious WAR file is uploaded, select 'Deploy' and a new directory labeled '/shell' will appear on the web app manager console, validating that the file upload was successful.

Now, we go back to our attacking machine and launch Metasploit to set up a listener for our incoming reverse shell. We use the multi/handler listener. Update our payload, listening host, and listening port in the module options. Validate options, then type run to begin listener on attacking machine.

After our listener is up and running on our attacking machine, go over to a browser and visit the directory listening of the malicious payload that we uploaded to the target's web server 'https://10.10.10.95:8080/shell/'

Visiting the '/shell' directory of our target web server triggers the malicious WAR file payload to execute, sending our attacking machine a reverse shell, which our attacking machine catches with the Metasploit listener.

Once our attacking machine catches the reverse shell from the target web server, we are able to validate that our active shell connection is for target machine.

Then, we traverse to the admin's desktop to pick up the user and root flags (2-for-1 special).

Fun box to start exploring web applications and their functions.

Excited to further develop wep app exploitation.

It's almost blasphemy to talk about web apps exploitation and not mention the OWASP Top 10 (more to come on that!)

Prost,

interested in actively following along? Check out the Hack The Box invite code challenge :)