• caglararli@hotmail.com
  • 05386281520

How to reproduce Tomcat 9.0.0.M1 HTTP smuggling vulnerabilities?

Çağlar Arlı      -    24 Views

How to reproduce Tomcat 9.0.0.M1 HTTP smuggling vulnerabilities?

I'm trying to reproduce some of the Tomcat 9.x.x vulnerabilities from this list, in particular the HTTP smuggling vulnerabilities. However, so far I haven't been able to reproduce any of them. Currently I'm running Tomcat 9.0.0.M1 behind an nginx 1.22.0 reverse proxy on Ubuntu.

Can anyone here point me towards a resource that describes in more detail how to reproduce these vulnerabilities? Perhaps a specific version or configuration of nginx (or a different front-end reverse proxy) is necessary to reproduce them? So far, I've only found the same blurbs from the Tomcat advisory reposted on other sites, with no elaboration.

Attempt to reproduce HTTP smuggling with trailer header:

As mentioned above, I'm running Tomcat 9.x.x behind an nginx 1.22.0 reverse proxy. I have the proxy blocking all requests to /manager/* and /host-manager/* (it returns 404 for matching requests), and I'd like to try bypassing this block using HTTP request smuggling. If I'm able to view the login page for either manager portal (even without valid credentials), I would consider the exploit successful.

One of the smuggling exploits listed in the security advisory concerns trailer headers:

Tomcat did not correctly parse HTTP trailer headers. A specially crafted trailer header that exceeded the header size limit could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.

In $CATALINA_HOME/conf/server.xml, I checked that rejectIllegalHeader was set to false. I also checked that the maximum HTTP header length parameter was set to 2048.

Therefore, I crafted several HTTP/1.1 requests to / with a trailer header called X with lengths of 2047, 2048 and 2049, but I observed no abnormal behavior (the home page was returned without errors, and subsequent requests appeared unaffected). I also tried tacking HTTP requests onto the end of this header, in the hopes that the header (and request) might be truncated after 2048 characters, causing this smuggled request to "split off". But I did not find any indication that this trailer headers was being parsed in a dangerous way.

Has anyone managed to reproduce this vulnerability before, or does anyone have more specific information about the circumstances in which is presents itself?