My initial nmap just shows port 8080 open, which appears to be an Apache Tomcat 7.0.88 landing page. There’s also a link to the server status and other data on settings, default configurations.
Whenever I encounter this, I typically assume “super lazy admin” and start looking for default install settings, default passwords, and unpatched known vulnurabilities.
While I’m testing all that, though, I make a point to continue running a more in-depth nmap, and also in this case dirb, just to make sure I’m not missing anything. I consider it good practice in case I end up going down a fruitless rabbit hole.
I’m feeling really lazy today, so I’m thought about firing up metasploit and scanning for vulnurabilities first, but sometimes admins are lazy, too, and in true lazy admin fashion, I didn’t even have to do that to get somewhere “admin/admin” gets us into the server status console. It’s an Apache Tomcat server.
A little digging at the initial set-up requirements/documentation tells us that the tomcat role can be configured for management access, and uses the password ‘s3cret’. I love lazy admins, don’t you? If you didn’t want to take the time to read the documentation, the tomcat_mgr_login metasploit module is another technique I’ve used before to test a variety of default creds. I double-checked it here and it is indeed successful on the tomcat/s3cret combination.
The docs themselves also specify how to deploy a .war file remotely, which we can then have extracted and have it call a shell back to us. This is TOO easy.
But first, a little background. What is Tomcat? What is a .war file? Why is this relevant to a penetration tester? These were the kinds of questions no CTF walkthrough ever addressed when I first started playing around with HTB last year, and I think these are important questions to answer because knowing WHY what you did worked is just as important as getting it to work in the first place.
Tomcat, Java, and .war files:
The short version is, Tomcat is an application server that serves requests to custom-built java servlets/JSP files on your sever. Tomcat has a built-in functionality, as you’ll see below, to deploy web applications via a Web ARchive (.war) file. WAR files usually contain XML files, relevant app-specific web pages, and more importantly, Java Servlets, classes, JAR (Java ARchive) files, etc. The following is taken from Tomcat’s documentation (https://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Configuring_Manager_Application_Access) on configuring manager application access to deploy WAR files:
Why this matters to us:
Through a tool like metasploit, or your own programming skills, you can create a .jsp file that will call a reverse shell back to you, wrap that up in a .war file, deploy it as a web application, and send yourself a convenient backdoor. I, as I’ve mentioned a few times on this blog, am not a developer by trade, so I chose to take the path of least resistance here and generate this payload in msfvenom. If you want a quick and dirty tutorial on this, follow along, or see this other write up that does a good job of explaining the general concept, although in a different format. https://pentestlab.blog/2012/08/26/using-metasploit-to-create-a-war-backdoor/
ON TO THE ACTUAL EXPLOIT
First, create your .war file:
Pro tip: extract the .war file to view the .jsp backdoor name that is randomly generated. The Tomcat system will automatically extract it, but in the process of generating the payload, the name of the .jsp is randomly populated, so if you want to know what file to execute, you’ll not want to miss this step.
Now, head over to the Tomcat Manager (in this case, http://10.10.10.95:8080/manager) and login using the credentials we sniffed out earlier.
From this point on, the exploit is really straightforward.
Start your meterpreter handler, upload the .war file, and execute by issuing a GET request to the location of the .jsp file (in this case, http://10.10.10.95:8080/reverse/wyjctezvllmeb.jsp ).
Head back to your MSF console, and watch and wait…
Drop into a shell, navigate to the standard location for the flags (in this case, it’s a 2-for-1 for user/root. This is what I call a “lunch break hack” in that I did it from boot to root in less time than it took me to down a Firehouse Sub. For people more experienced than me, a hack like this is ultra simple and takes a few minutes. Unfortunately, SO many admins configure their environments this way and this isn’t unlike what you might see in production. Moral of the story? Don’t be a lazy admin. Lazy admins get their stuff hacked.