New backdoor worm found attacking websites running Apache Tomcat

Tomdep harnesses strength of servers to wage powerful denial-of-service attacks.

Read the whole story

 

[zachlipton]

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.

 

[Deleted member 192806]

This a poor thing when your Tomcat gets a backdoor worm.

 

[Chuck Knucka]

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.

 

[motytrah]

Chuck Knucka[/url]":22peklgj]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.

 

[hubick]

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.

Edit:

http://tomcat.apache.org/tomcat-7.0-doc ... ion_Access

The manager app is disabled by default, and the config example shows it restricted to localhost.

 

[rakkuuna]

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.

 

[Pirokobo]

motytrah[/url]":2oxhe9xi]

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.

 

[Faramir]

motytrah[/url]":2p4x523z]By default a fresh Tomcat server no admin user/password and for all intensive purposed is disabled.

for all intents and purposes

 

[kalzekdor]

Faramir[/url]":20i8u7go]

motytrah[/url]":20i8u7go]By default a fresh Tomcat server no admin user/password and for all intensive purposed is disabled.

for all intents and purposes

Beat me to it, fellow logomachist.

 

[toyotabedzrock]

I love how the Java runs on everything promise is now a liability.

 

[Pse]

toyotabedzrock[/url]":ydv7ddya]I love how the Java runs on everything promise is now a liability.

This is not a Java issue, read the article.

 

[rockforbrains]

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.

 

[bonewah]

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?

 

[motytrah]

bonewah[/url]":24f4o57m]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.

 

[Massolo]

Is there a game afoot at Ars Technica for every article writer to get a picture of their cat into a story? I noticed it before with their GF/SO's as well.

 

[jzgoda]

So wait, this has nothing to do with a vulnerability, just very poorly run Tomcat servers with the worst possible passwords.

This could be done to basically ANY server.

 

[haar]

great cat photo...

 

[fuzzysteve]

oops.

ignore this post.

 

[dangoodin]

bonewah[/url]":bhsmv398]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.