undefined | Better HN

0 pointssjones6713y ago0 comments

The exploit PoC that is doing the rounds works on full tomcat, not embedded tomcat, so if your example vulnerable application is using embedded tomcat that exploit won't work on it without being tweaked.

I've looked at it today as well, for most of the day. Embedded tomcat doesn't have a webapps directory, whereas the full version of tomcat does, so the PoC writes the webshell to webapps/<APP>/tomcatwar.jsp and that is served up then.

I'm on OSX and I found the temp directory that is created for the embedded tomcat at runtime but there's nothing deployed there, so I can't figure out where to write the webshell to or if it is even possible. I looked at the process with lsof and just followed the trail to find the directory but it's not working.

Anyway, embedded tomcat IS vulnerable, just not sure if it is exploitable.

To check if it is vulnerable you can do run the following curl command: curl "http://localhost:8080/?class.module.classLoader.URLs%5B0%5D=..."

If this returns status:400 then it is vulnerable, if not then it is not. If you have an app deployed to a different context path (so /my-webapp) then you'd need to run: curl "http://localhost:8080/my-webapp?class.module.classLoader.URL..."

I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this.

I'm sure there's other gadgets that can be used to exploit this, the example we saw was using tomcat to write a webshell.

0 comments

tru3_power3y ago

I just came to the same conclusion after some debugging. On embedded tomcat there is no access to resources and thus the popular PoC floating around doesn’t work. I left off for the night exploring getters/setters on the URL object returned on the URLs[0] call. On Java 11 there were some interesting getters/setters I want to explore. Let me know if you find a working PoC. Fun stuff!

richbell3y ago

> I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this.

Wouldn't any method annotation like @PostMapping be vulnerable? The vulnerability is in how Spring loads the beans, so in theory any endpoint that loads a bean would trigger the exploit regardless of method.

j / k navigate · click thread line to collapse