tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Mon, 22 Apr 2013 20:45:11 GMT
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: Howard W. Smith, Jr. []
>> Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>> HTTP/1.0" 404
>> also, if an 'ANN' email was sent, where /expert tomcat/ users can derive/develop
a list of the popular/frequent URLs that bots use when attempting to compromise /tomcat/ servers.
> Wouldn't this depend on what user applications are deployed on the Tomcat server?  By
default, I thought we concluded that Tomcat "out of the box" is not compromised?  Did I mis-read

I don't think you did.
And I believe that if there was any knowledge that Tomcat "out of the box" was 
compromised, the Tomcat developers would instantly set everything else aside and plug the


About this "/manager" access which started this thread : a long time ago, maybe as far 
back as Tomcat 4.0 or Tomcat 5.0, I believe that the manager application was by default 
enabled, and the tomcat-users.xml file that was shipped with it, also enabled the default

user-id and password that allowed to login to it and run it.
Then someone found a way to use this, to inject a rogue application into running and 
web-accessible Tomcats.  That hole was soon plugged, and hasn't been part of the default 
distributed Tomcat for years.  But apparently, there are still some bots on the www which

try it out, just in case there would still be one of these vulnerable old versions still 
in activity (as there probably are; "never fix a running system", he ?).
That's all there is to it, as far as I know.

Now if you are running Tomcat as an internet-facing webserver on port 80, that Tomcat is 
likely to be submitted to regular bot scans which are really targeting vulnerabilities in

applications which are relatively widespread on Apache httpd and IIS.  These correspond to

URLs like "/phpadmin", "/mysqladmin", "/vti_bin" and the like, which do sometimes exist 
under Apache httpd and/or IIS and sometimes do have security weaknesses, but which are 
very unlikely to be installed in a Tomcat webserver (because they are not Java 
applications, for one).
Thus you would see these accesses also in Tomcat access logs, because the bots are not 
always discriminating enough to first check the type of webserver that they scan.  But 
under Tomcat, it would be very unlikely that you would have a webapp which actually 
responds to one of these URLs, and consequently most of these attempted accesses would be

met with a 404 "Not Found" response.

Do not take the above as a recommendation to forget about it and to not regularly inspect

your webserver logs though.  It is perfectly possible to create a Tomcat webapp which will

open up a huge security hole, and give it a context name that will be irresistible to the

first bot that notices it ("/secret" and "/private" come to mind).

If you set up an Apache httpd as a front-end to Tomcat (with an Apache/Tomcat Connector 
such as mod_jk or mod_proxy), it is also quite easy to configure Apache httpd so badly 
that it will provide access to files within Tomcat, which contain things that you would 
never want an external client to see.  The main example of this kind of bad configuration

consists of making the Apache httpd DocumentRoot and the Tomcat webapps directory overlap,
as mentioned here, in red characters :

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message