Researchers have identified new self-replicating malware that infects computers running the Apache Tomcat Web server with a backdoor that can be used to attack other machines.

Java.Tomdep, as the backdoor worm has been dubbed, is Java Servlet-based code that gives Apache Tomcat platforms malicious capabilities. It causes infected machines to maintain Internet relay chat (IRC) communications with attacker servers located in Taiwan and Luxembourg. The control servers send commands and receive progress reports to and from the infected machines. Affected platforms include Linux, Mac OS X, Solaris, and most supported versions of Windows. Researchers haven't said precisely how the malware takes initial hold of servers, but there's no evidence yet it exploits any vulnerability in Tomcat or any other software running on infected servers.

In a blog post published Wednesday, Takashi Katsuki, a researcher at security firm Symantec, said Java.Tomdep appears to be designed to harness the huge amounts of bandwidth and computing power available to Web servers for use in denial-of-service attacks against other machines. Unlike Darkleech and other malware targeting Web servers, there's no indication that it's used to attack end users visiting websites. Katsuki explained:

The Java Servlet is executed on Apache Tomcat, but it does not create a webpage and instead behaves as an IRC bot. It connects to an IRC server and performs commands sent from the attacker. End users who visit webpages from the compromised Tomcat server are not affected by this threat. Aside from standard commands such as download, upload, creating new process, SOCKS proxy, UDP flooding, and updating itself; compromised computers can also scan for other Tomcat servers and send the malware to them. It is thus possible that DDoS attacks from the compromised servers are the attacker’s purpose.

Tomdep-infected machines also seek out other servers running Apache Tomcat and attempt to log in to them using commonly used combinations of user names and passwords. When the credentials match, Tomdep gets installed on another machine.

So far the number of infected machines appears to be low. Then again, the malware was detected less than a month ago. Given the epidemic of weak password hygiene and the lack of antivirus programs used on many Web servers, the threat could still spread.

19 Reader Comments

You've got to hand it to Symantec, who reassures us in their blog that all their anti-virus products are able to detect the worm, but provides no other details for Tomcat admins who happen not to use Symantec products. Now I know that my management port isn't publicly accessible and I have a non-default password set, but some basic "check for foo.war in your webapps/" directory is usually basic information that vendors provide in these situations.

Of course this is a big deal for Symantec because their Endpoint Protection product uses a Tomcat server to host its web admin console.

I've always been rather puzzled why a security company relies so heavily on Java and Java plugins.

Because the servers themselves are actually quite secure. By default a fresh Tomcat server no admin user/password and for all intensive purposed is disabled. In order for the server to be infected someone had to manually go into the config file and set a weak sauce username and password.

One of the reasons I suspect the infection rate is so low is because very few people use the UI for production servers. You only need to set up an admin user if you want to use the UI to administer the server. You don't need to use the admin user to deploy a Java app. Just copy the WAR or EAR file into the webapp directory from the command prompt. Anything that can be managed in the UI can be managed in the config files from the command prompt too. The rare times I have seen the UI used in prod it was restricted behind a firewall or on a port on accessible internally.

Generally speaking Java in an application server context is light years more secure than Java the browser plug-in.

compromised computers can also scan for other Tomcat servers and send the malware to them. When it finds another Tomcat server, it first attempts to log in with the following pairs of weak usernames and passwords

So, this isn't a Tomcat vulnerability, so much as a warning to change the default passwords.

If I understand this correctly, the newsworthy thing about this is that backdoor is self replicating? Not that there is any security holes in Tomcat? And the only attack vector is using poor password set by administrator? Tomcat by default doesn't even have administrator account.

One of the reasons I suspect the infection rate is so low is because very few people use the UI for production servers. You only need to set up an admin user if you want to use the UI to administer the server. You don't need to use the admin user to deploy a Java app. Just copy the WAR or EAR file into the webapp directory from the command prompt. Anything that can be managed in the UI can be managed in the config files from the command prompt too. The rare times I have seen the UI used in prod it was restricted behind a firewall or on a port on accessible internally.

I Investigated this alert and realized our deployment garbage cleanup would actually be an effective anti-virus in this case, because the installed code would appear as an app that doesn't jive with our payload manifest. It'd treat it as a remnant of a faulted undeploy.

I understand this is primarily a weak username/password combination problem which is a not a specific software problem. This is a user problem but I do not know if it is stupidity, laziness, or something else.

So to be clear here, the exploit vector is weak passwords? This isnt some new vulnerability in tomcat? Can the author perhaps state that explicitly in the article?

I wouldn't hold your breath. Dan's articles relating to programming languages and the infrastructure around them tend to be high on headlines and short on details and context. I think most of it comes from lack of knowledge. Which isn't unusual. A lot of security folks know networking and OS really well, but are totally in the dark about application servers and the execution environment/VM.

So to be clear here, the exploit vector is weak passwords? This isnt some new vulnerability in tomcat? Can the author perhaps state that explicitly in the article?

There's nothing in the original research -- or in my article, for that matter -- that indicates there's a vulnerability in Tomcat or any other software running on infected machines. We also know that the self-replication method relies on weak passwords. That said the absence of evidence isn't evidence of absence. It often takes months for researchers to fully unravel how a newly discovered piece malware works. (Researchers still aren't sure how Darkleech spreads, for instance.) That being the case, I'm not prepared to state categorically there's no software vulnerability involved here.

I've updated the story to make explicit there's no evidence of a software vulnerability.