ArcGIS Server java ed. exposes tomcat manager webapp with well know user credentials

This article concerns the ESRI ArcGIS Server java ed. versions 9.3 and 9.3.1 and possibly others.

ArcGIS Server 9.3sp1 and 9.3.1 expose the Tomcat html manager application; this in itself is not a bad thing if the user would be aware of the consequences and if the credentials which would be necessary to obtain access were not public knowledge [KB 37134 , KB 37147].
Neither of these conditions are met, causing a situation where the management of the built-in tomcat servers is open for anyone interested; you cannot get an easier way to launch a DoS attack. Essentially this makes the product unfit for deployment in the enterprise.

The Tomcat manager application provides the ability to manage web-applications deployed in the container, this includes starting, stopping, reloading, removing and also uploading web-applications.

There are various solutions to solve this; however primary concern is to document this properly so that anyone installing or having installed this software can fix this, either by disabling (parts of) the tomcat manager interface/webapp and/or changing the user credentials. (btw. KB 37147 gives information on how to change the credentials, this must be done in \ArcGIS\java\manager\config\build.properties)

Three possible solutions (in my order of preference) are:

  • Remove the html manager application; it is not actually used in the product and there are serious concerns wrt. security, such as the user credentials being transmitted over regular http instead of https. If anyone at all wanted/needed this functionality it can easily be deployed separately either using the code from the tomcat project or a product such as LambdaProbe.
  • Make the installer or the post-installer set the user credentials either to the same ones as the arcgis (SOM) service/windows account or better yet a new account. (this is logged under NIM049753 in the ESRI Bugs Online)
  • make the tomcat html manager only available from the localhost
  • replace Tomcat with something that is easier to embed and less developer oriented such as Jetty.

A combination of these is of course also possible.

Impact

So what can you do to (ab)use this situation? Well in one scenario it will allow anyone to destroy the web-applications hosted in the container; thus causing a Denial of Service for your web mapping clients.  The web-applications hosted here are the endpoints for SOAP, REST, WMS, WFS and KML services that are used by them.

In another scenario it will enable anyone to upload a web-application  that will turn your server into a warez (or worse) hosting machine.

In a last scenario will enable anyone to upload a web application that can cause major grief on your system. All it takes for to do this is some simple Java coding and packaging.

Advertisements

2 Responses to “ArcGIS Server java ed. exposes tomcat manager webapp with well know user credentials”


  1. 1 David Askov Friday 18 December 2009 at 22:11

    Regarding the default password – YIKES! Change it. That definitely should be in the post-install, or at least a defined step in the install docs. You shouldn’t have to hunt for a KB article.

    That said, ESRI’s recommended setup is that the ArcGIS Server is on your network, and a reverse proxy is set up from a web server in your DMZ (see KB article 35948). You only reverse proxy the paths you want, which should not include the Tomcat manager or the ArcGIS Server manager apps. If I understand correctly, the Tomcat and ArcGIS Server manager apps will only available over your LAN from users on your network. If so, DoS attacks would only come from inside your network, right?

    • 2 Mark Prins Sunday 20 December 2009 at 22:08

      Yes using reverse proxy would limit access to ‘your network’ (if you do it right), our network happens to be quite extensive (and our reverse proxy was set up wrong..).
      There is no need for the Tomcat manager to be there, but even if there were it should be limited to localhost access only; see http://www.unidata.ucar.edu/Projects/THREDDS/tech/reference/TomcatSecurity.html for hints on how to do this.


Comments are currently closed.




%d bloggers like this: