Is it possible to exploit the “Ghostcat” vulnerability (CNVD-2020-10487/CVE-2020-1938) indirectly over mod_proxy_ajp?
I was able to successfully test the proof-of-concept exploit (https://www.exploit-db.com/exploits/48143) when targeting my Tomcat’s AJP port. However, my tomcat instance is not directly externally accessible, but rather sits behind an Apache reverse proxy via mod_proxy_ajp. Am I safe from external Ghostcat attacks in this instance?
As a test for indirect exploitation, I sent an HTTP GET request targeting my Apache front-end which proxies to the Tomcat AJP port, and I set the following HTTP header:
req_attribute: javax.servlet.include.request_uri=/, javax.servlet.include.path_info=WEB-INF/web.xml, javax.servlet.include.servlet_path=/
I also tried variants of this header such as using semi-colons as a delimiter instead of commas, as well as having multiple req_attribute headers for each key,value pair on a separate line.
Fortunately, the body of the HTTP response did not dump my WEB-INF/web.xml file, therefore these indirect exploit attempts failed. Upon further inspection with tcpdump, I see that these req_attribute headers do not get encoded to AJP’s format of using a single byte (0x0a) to denote req_attribute. So it seems that the HTTP ASCII request headers do not translate into AJP’s binary request headers. Therefore I believe that the vulnerability is non-exploitable through HTTP requests that get passed to mod_proxy_ajp, is that correct? Or is there a clever way to craft an HTTP request that would make mod_proxy_ajp pass along the req_attribute headers in AJP’s binary format in order to indirectly exploit this vulnerability?