Description:
When using the Apache JServ Protocol (AJP), care must be taken when
trusting incoming connections to Apache Tomcat. Tomcat treats AJP
connections as having higher trust than, for example, a similar HTTP
connection. If such connections are available to an attacker, they
can be exploited in ways that may be surprising. In Apache Tomcat
9.0.0.M1 to 9.0.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99, Tomcat
shipped with an AJP Connector enabled by default that listened on
all configured IP addresses. It was expected (and recommended in the
security guide) that this Connector would be disabled if not
required. This vulnerability report identified a mechanism that
allowed: – returning arbitrary files from anywhere in the web
application – processing any file in the web application as a JSP.
Further, if the web application allowed file upload and stored those
files within the web application (or the attacker was able to
control the content of the web application by some other means) then
this, along with the ability to process a file as a JSP, made remote
code execution possible. It is important to note that mitigation is
only required if an AJP port is accessible to untrusted users. Users
wishing to take a defence-in-depth approach and block the vector
that permits returning arbitrary files and execution as JSP may
upgrade to Apache Tomcat 9.0.31, 8.5.51 or 7.0.100 or later. A
number of changes were made to the default AJP Connector
configuration in 9.0.31 to harden the default configuration. It is
likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 or later
will need to make small changes to their configurations.
—————-
When enumerating, we can across port 8009 that seemed to be running Apache Jserv, protocol v1.3.
Using the search feature in Metasploit, we get one hit for Jserv
Checking options, we see there are some default options. We want to update the RHOSTS and RPORT options to our target. From here we are going to exploit
