Ghostcat vulnerability affects most Tomcat releases

[Ariel Lira (sedici.unlp.edu.ar)]

Hi, recently a new Tomcat vulnerability called "ghostcat" came to light and affects almost all tomcat releases, and because of that all dspace installations. 

According to https://access.redhat.com/solutions/4851251 "The AJP protocol is enabled by default, with the AJP connector listening in TCP port 8009 and bound to IP address 0.0.0.0. A remote, unauthenticated/untrusted attacker could exploit this AJP configuration to read web application files from a server exposing the AJP port to untrusted clients. In instances where a poorly configured server allows file uploads, an attacker could upload malicious JavaServer Pages (JSP) code within a variety of file types to gain remote code execution (RCE).". 

In short: tomcat AJP connector may allow unwanted access to files and remote code execution (in particular scenarios) and it is exposed by default in most tomcat servers.

The bug was fixed in Apache Tomcat 9.0.31, 8.5.51, and 7.0.100, but if you can't upgrade or if does not exist an upgrade for your tomcat version, you can try at least some quick fixes:

1) disable AJP connector in server.xml (if you don't use a reverse proxy)

  <!-- <Connector protocol="AJP/1.3" port="8009" ...  /> -->

2) Bind AJP connector to localhost interface so it can only be accessed from the same host, or the one used by your reverse proxy:

 <Connector protocol="AJP/1.3" port="8009" address="localhost" .../>

3) filter/reject incoming traffic to port 8009 coming from the internet.

Any correction or additional fixes are welcome.  

Regards. 

[Mark H. Wood]

On Wed, Mar 04, 2020 at 06:48:40AM -0800, Ariel Lira (sedici.unlp.edu.ar) wrote:
> Hi, recently a new Tomcat vulnerability called "ghostcat" came to light and
> affects almost all tomcat releases, and because of that all dspace
> installations.
>
> According to https://access.redhat.com/solutions/4851251 "The AJP protocol
> is enabled by default, with the AJP connector listening in TCP port 8009
> and bound to IP address 0.0.0.0. A remote, unauthenticated/untrusted
> attacker could exploit this AJP configuration to read web application files
> from a server exposing the AJP port to untrusted clients. In instances

That may be true of the Red Hat packaging. Your distribution may be
different. Gentoo ships Tomcat with the AJP connector commented out.
The thing to do is check your own configuration to ensure that it is
set up the way you need it, and no more, as with any network service.

> where a poorly configured server allows file uploads, an attacker could
> upload malicious JavaServer Pages (JSP) code within a variety of file types
> to gain remote code execution (RCE).".
> In short: tomcat AJP connector may allow unwanted access to files and
> remote code execution (in particular scenarios) and it is exposed by
> default in most tomcat servers.
>
> The bug was fixed in Apache Tomcat 9.0.31, 8.5.51, and 7.0.100, but if you
> can't upgrade or if does not exist an upgrade for your tomcat version, you
> can try at least some quick fixes:
>
> 1) disable AJP connector in server.xml (if you don't use a reverse proxy)
>
> <!-- <Connector protocol="AJP/1.3" port="8009" ... /> -->
>
> 2) Bind AJP connector to localhost interface so it can only be accessed
> from the same host, or the one used by your reverse proxy:
>
> <Connector protocol="AJP/1.3" port="8009" address="localhost" .../>
>
> 3) filter/reject incoming traffic to port 8009 coming from the internet.
>
> Any correction or additional fixes are welcome.

Thank you for reporting this.

The fixed releases are not a drop-in fix. The fix is to secure the
AJP connection by default, but this requires coordination with the
proxy. If the connector's new 'secretRequired' property is set true
(and this is the default) then Tomcat and proxy must share a secret
which is configured with the connector's 'secret' property.

I tried this out and couldn't get Apache HTTPD to cooperate. I'm told
that the required proxy property was added in a version not yet
released.

So, for the time being, even with a fixed version of Tomcat you may
still need to take some of the steps given above, and additionally
disable the fix, if your proxy is not ready to use it.

I would say that the quick fixes are how Tomcat should be configured
anyway. AJP isn't meant to be public.

BTW do not set 'secret' unless you mean to use it. I found out the
hard way that Tomcat will check AJP traffic for the secret if it is
defined, regardless of the value of 'secretRequired'. Even if you set
'secret=""' it will check each request for an empty secret.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

[Ariel Lira]

Hi Mark, thanks for your feedback. 

That may be true of the Red Hat packaging.  Your distribution may be
different.  Gentoo ships Tomcat with the AJP connector commented out.

yes, several distros disable AJP by default, like ubuntu and debian. So in these OSes if AJP was not manually enabled, they may be safe. 

The fixed releases are not a drop-in fix.  The fix is to secure the
AJP connection by default, but this requires coordination with the
proxy.  If the connector's new 'secretRequired' property is set true
(and this is the default) then Tomcat and proxy must share a secret
which is configured with the connector's 'secret' property.

I tried this out and couldn't get Apache HTTPD to cooperate.  I'm told
that the required proxy property was added in a version not yet
released.

Neither me. According to  https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html "secret" parameters was added in apache 2.4.42, but I did not find any official packages with it, so "secret/secretRequired" workaround may not be available for some time.   

I suppose binding the AJP connector to localhost should be enough for most cases (where AJP is required).  

Regards

 

--

//---------------
Lic. Ariel Jorge Lira
SEDICI, Repositorio Institucional de la UNLP - http://sedici.unlp.edu.ar
CIC-DIGITAL, Repositorio de la Comisión de Investigaciones Científicas - https://digital.cic.gba.gob.ar

Calle 49 y 115 S/N Edificio ex-Liceo, Primer Piso  (ver mapa) 

Universidad Nacional de La Plata - Argentina