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