peew.pw

Just a no nonsense infosec blog.

New Vulnerability, Same Old Tomcat: CVE-2017-12617

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.

Photo: https://www.cvedetails.com

Photo: https://www.cvedetails.com

Despite this scrutiny by security professionals, we continue to see more vulnerabilities discovered. A recent example of this is CVE-2017-12617, in which severs 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”.

Screenshot from 2017-10-08 23-15-09.png

2. Weaponizing the POC

Our next step was to take the POC and test it out on our environment. Our 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.

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/peewpw/metasploit-framework/blob/patch-1/modules/exploits/multi/http/tomcat_jsp_upload_bypass.rb
Announcing Peew.pw Modules!

The objective of these modules is to provide a training ground for learning exploit development!

In the hacking world, exploit dev is one of the most difficult areas to delve into. In my own search for learning resources I've found plenty of useful materials out there: white papers on theory, detailed descriptions of various types of memory corruption techniques, and even some comprehensive courses (if you're willing to shell out a bit of cash). Generally, these resources do a great job of explaining specific vulnerabilities and how to go about exploiting them. Some even provide a nice example of vulnerable software and walk you through its exploitation. These types of resources are essential to learning the basics of exploit development, and I'll try to provide a comprehensive list of them in a later post. However, when reading through books or papers it became increasingly difficult to find concrete examples of vulnerable software to exploit without floundering in the dark for hours. I constantly ran into the same questions:

  • What operating systems are affected?
  • Where can I find the correct vulnerable version of the software?
  • Am I on the right track to successfully exploit this?
  • What are the "gotchas" for this exploit that might be stumping me?

The peew.pw modules aim to give hands on practice at exploiting various classes of vulnerabilities while making sure these questions are answered along the way. The modules begin with simple, straightforward exploits aimed at beginner exploit devs and will progress through increasingly advanced scenarios and modern exploits. In each module, I'll strive to follow a relatively standard format. You can expect something like this:

  1. A thorough description of the vulnerability including its class (stack overflow vs heap overflow, etc).
  2. The necessary materials to carry out the exploit.
    1. links to vulnerable software
    2. specific information of affected operating systems / environment requirements
    3. any special conditions
  3. A technical walkthrough of the exploit from discovery of the vulnerability to successful exploitation.

Hopefully, this will enable the curious hacker to ease their way into becoming a competent exploit developer and will fill the gaps left by some of the other popular resources out there. Happy Hunting!

Chris Myers