Deconstructing Apache Tomcat JSP Upload Remote Code Execution (CVE-2017-12615)
Here at the Application and Threat Intelligence Research Center, we explore security threats to better understand how they work so we can replicate them for use with our BreakingPoint security test solution. Let’s take a deeper look into the Apache Tomcat JSP Upload vulnerability, which allows attackers to upload arbitrary files to the Tomcat application server by using the HTTP PUT method. This vulnerability is due to the DefaultServlet readonly parameter being configured to false in conf/web.xml. When any request file’s extension is .jsp or /.jspx, Tomcat will use DefaultServlet to handle it. By uploading a .JSP file to the Tomcat Application Server, an attacker can execute malicious code on the remote machine.
Set up Metasploit multi handler and use jsp_shel_reverse_tcp as the payload
Proof of Concept (POC)
This PoC will generate a JSP reverse tcp shell using msfvenom, and use an HTTP PUT method to upload it to the Tomcat server. Here, we use the /sh4.jsp/ in HTTP put request. Tomcat will create a JSP web shell called sh4.jsp in the server. After successfully uploaded the shell, use an HTTP GET request to get the jsp web shell file and get the reverse shell in Metasploit listener.
To provide valuable strikes to our customers, we offer this exploit in our Ixia BreakingPoint system. The strike will try to use an HTTP PUT method to upload a non-malicious jsp file to the Tomcat server. After running the strike, it will generate a pcap like this:
The strike uploads a JSP file with a random name. In this example, it is BvGhDVR.jsp. This strike is deployed in our upcoming ATI release.
Leverage Subscription Service to Stay Ahead of Attacks
The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.