New Vulnerability, Same Old Tomcat: CVE-2017-12617
October 30, 2017 | Posted in Red Teams by Chris Myers, Barrett Adams
Tomcat has been a staple target for penetration testers and malicious actors for years. With ample opportunities to exploit security misconfigurations in the management GUI (tomcat:tomcat….) or technical vulnerabilities, it’s no wonder attackers continue to pay attention to the platform. On top of these issues, Apache Tomcat is often running as a System service, elevating its allure even further.
Despite this scrutiny by security professionals, we continue to see more vulnerabilities discovered. A recent example of this is CVE-2017-12617, in which servers with PUTs enabled are subject to arbitrary JSP file uploads via specially crafted requests. This vulnerability allows an attacker to gain potentially privileged remote code execution on the system. The initial POC can be found here: https://bz.apache.org/bugzilla/show_bug.cgi?id=61542. Since this exploit is fairly straightforward and can give us remote code execution on our engagements, we decided to test it out, then weaponize it in the form of a Metasploit module :)
1. The Vulnerable Environment
We first needed a vulnerable version of Tomcat running on a Windows server to test the POC. This was fairly straightforward to set up and a quick trip to the Apache Tomcat archives armed us with a vulnerable version (7.0.81). Our setup is as follows: Windows Server 212 R2 (Amazon AMI), Apache Tomcat 7.0.81, “readonly” initialization variable set to “false”.
2. Weaponizing the POC
Our next step was to take the POC and test it out on our environment. Are we actually working with a legitimate set-up?
A 201 Response from our POC request to /1.jsp/ results in the jsp code executing server side, outputting "hello" to the browser.
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 :)
Using our metasploit module to upload a jsp shell to a vulnerable Tomcat version via a PUT request. The module can be found here: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/http/tomcat_jsp_upload_bypass.rb