Yep! Our proof of concept code and test environment both look to be in order. So, now to build a metasploit module and take advantage of some of the more useful payloads the framework has to offer.

Being a Tomcat vulnerability, we decided to start with an existing Tomcat module, exploit/multi/http/tomcat_mgr_upload and tweak it to our needs. But, as it turns out that one does a ton of stuff we don’t need! The next approach was to take an existing JSP module, adobe_robohelper_authbypass, and go from there. This turned out to be much more fruitful (fruitier?). With just a few changes and some simplifications, we managed to get a working module to upload our choice of JSP command shell to a vulnerable Tomcat instance. You can grab the full module on our github (we’ve also made a pull request to the master branch).

**UPDATE** Our pull request was accepted! You can now find the module in the official repository: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/http/tomcat_jsp_upload_bypass.rb.

In the end, we turned a new Tomcat POC into a convenient Metasploit module that will upload and execute a JSP shell and includes a checker function to determine if a given instance is vulnerable (this will also clean itself up from the system).

3. Profit :)

You might be thinking that this vulnerability is only going to show up once in a blue moon, given the relatively restrictive configuration prerequisites. And, you’d be correct... You will probably not encounter this vulnerable setup very often on engagements. So why take the time to make a Metasploit module for it? Having a module like this takes the hassle out of determining if a Tomcat instance is vulnerable to a less common exploit like this. Now, we can easily run this check against all identified Tomcats in the background on pentests. If any come back as vulnerable, there is a good chance we have System level access and a new way into the Windows Domain! We hope you enjoy and profit on your own engagements as well :)