Tomcat security: Why run an exploit if you can just log in?

Published: 2015-02-05
Last Updated: 2015-02-06 16:07:44 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

In our honeypots, we recently saw a spike of requests for http://[ip address]:8080/manager/html . These requests appear to target the Apache Tomcat server. In case you haven't heard of Tomcat before (unlikely): It is a "Java Servlet and JavaServer Pages" technology [1]. Essentially an easy way to create web applications using Java servlets. While Java may be on its way out on the client (wishful thinking...), it is still well liked and used in webapplications. The vulnerabilities being attacked by the requests above are unlikely the same buffer-overflow type vulnerabilities we worry about on the client. Instead, you will likely see standard web application exploits, and in particular attacks against weak Tomcat configurations.

In particular the URL above points to the "manager" web app, a web application that comes with Tomcat to allow you to manage Tomcat.  Luckily it is "secure by default" in that there are no default users configured to use this manager web application. So you will need to add your own users. The password better be complex. 

By default, passwords are not hashed or encrypted in Tomcat's configuration file. However, they can be hashed. To do so, you need to edit the confserver.xml file. By default, the confserver.xml file includes a line like:

<realm classname="org.apache.catalina.realm.UserDatabaseRealm" resourcename="UserDatabase"></realm>

Change this to

<realm classname="org.apache.catalina.realm.userdatabaserealm" digest="SHA" resourcename="userdatabase"></realm>

The hashing is performed by the digest.sh script, that you can find in the tomcat "bin" directory. (for Windows: digest.bat). You can use this script to hash your password:

digest.sh -a SHA password

Ironically, digest.sh is just a wrapper, calling a script "tools-wrapper.sh" . and various SHA versions (e.g. sha-512). But it is better then keeping the password in the clear. (anybody got a link to a comprehensive documentation for this?)

Once a user is able to connect to the Application Manager, they have "full" access to the server in that they are able to change the configuration or upload new applications, essentially allowing them to run arbitrary code on the server. 

OWASP also offers a brief guide to secure Tomcat [2] . It also doesn't hurt to check the Tomcat manual once in a while. 

[1] http://tomcat.apache.org
[2] https://www.owasp.org/index.php/Securing_tomcat

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
3 comment(s)
GNU Privacy Guard (gpg) needs your help. If you have a couple $$ to spare, check https://www.gnupg.org/donate/index.html
ISC StormCast for Thursday, February 5th 2015 http://isc.sans.edu/podcastdetail.html?id=4343

Adobe Flash Player Update Released, Fixing CVE 2015-0313

Published: 2015-02-05
Last Updated: 2015-02-05 00:16:04 UTC
by Johannes Ullrich (Version: 1)
14 comment(s)

An update has been released for Adobe Flash that fixes according to Adobe the recently discovered and exploited vulnerability CVE-2015-0313. Currently, the new version of Flash Player is only available as an auto-install update, not as a standalone download. To apply it, you need to check for updates within Adobe flash. (personal note: on my Mac, I have not seen the update offered yet).

The new Flash player version that fixes the problem is 16.0.0.305. The old version is 16.0.0.296.

Adobe updated its bulletin to note the update: https://helpx.adobe.com/security/products/flash-player/apsa15-02.html

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords: 0day adobe cv20150313
14 comment(s)

Comments


Diary Archives