Symantec has recently discovered a trojan/worm-ish thing that threatens application servers running Apache Tomcat. It seems to follow the typical command & control pattern with control servers having been found in Taiwan and Luxembourg so far.
This threat is using a very specific attack vector by trying to spread via the Apache Tomcat Managers and their (quite often unchanged) weak passwords and the weak users/passwords Apache Tomcat ships with as (commented and not by default active) examples . If it’s successful, it’ll try to deploy itself as a servlet and the cycle restarts.
You can prevent the whole thing from happening if you either have disabled the Manager applications or have setup users with non-default, strong passwords. The file to check is tomcat-users.xml and its content.
Why is this even interesting for Adobe ColdFusion and Railo users? Mainly because a lot of people run their CFML servers on Apache Tomcat. There are various use cases of which you should be aware of:
a) Adobe ColdFusion 9 as a single server install is safe from this attack as it’d be using JRun. In Adobe ColdFusion 9 Tomcat deployment was never properly supported officially, but certainly doable through custom .war deployments. If you did that, it’s quite likely that you might be running a full version of Apache Tomcat and that you might be vulnerable, depending on your setup (see above).
b) Adobe ColdFusion 10 comes with a preinstalled and embedded Tomcat instance if you do a single server install. That could theoretically expose you. However, I’ve checked an install I’m running on OS X and it seems that there are no users and roles enabled in the configuration either. Again, if you’ve done a custom J2E deployment on your own Tomcat – make sure you check that and know what you’re doing.
c) Current Railo 4 installers and custom installs: The installers are all very safe and secure by default, there haven’t been any modifications to the users/role setup. The current 4.1 installers don’t even install the Tomcat-own webapps. If you used a vanilla Tomcat from Apache’s website and dropped Railo into that as a .war/.jar file you’ll be fine, too, as there are no users enabled for the Tomcat Manager apps.
The essence is: by default you should be fine according to what I’ve seen. If you’ve modified your Apache Tomcat setup in any way, please make sure you’re staying safe as well. Not to forget that the full credit for making me aware of the Tomcat threat in the first place goes to Jordan Michaels.
Updated (29/11/2013): Changed the wording in 2nd paragraph.
Please cease spreading the misinformation in your second paragraph that Apache Tomcat ships with well-known and/or weak passwords for the Manager application. Every Apache Tomcat release in the last 9 years (i.e. since Tomcat 4.0.0 and possibly further back than that) has shipped with zero users configured with access to the Manager application. System administrators must explicitly grant a user access to the Manager application. To make a Tomcat installation vulnerable to this thread, a system administrator would have to create a new user (possibly using the commented out examples in tomcat-users.xml) with a weak password and then grant that user access to the Manager application. Frankly, any system administrator sloppy enough to do that is almost certainly going to have created a whole bunch of other security issues as well.
Mark, you are correct – my wording could leave the impression that Tomcat ships with by default active roles, users and passwords for the Manager. It doesn’t and my change makes that more clear.
However, if you look at the reality out there, you’ll find that there are large amounts of installations of Tomcat out there where people uncomment the examples to have a starting point for their own setup and
a) Keep the user and the role setup and just change the password (avoiding this direct attack, still leaving an attacker with a good guess vector of what the user names would be)
and/or
b) Add their own users with better passwords and leave the examples just uncommented.
Like it or not, that’s what one sees regularly in the wild. Is it the user’s fault? Sure it is. I’d argue though that those example roles/users/passwords should not even be part of a Tomcat configuration file (not even in a comment) and only provided in the documentation outside of any config files.
Normally when I setup Tomcat, the first thing I do is remove the manager, host-manager, examples, and docs folders from webapps. Your post was timely as it reminded me that I’d recently upgraded several servers from Tomcat 6 to Tomcat 7 and had forgotten that step! So, thank you for the reminder 🙂
Comments on this entry are closed.