Ethical Tech Support

Ethical Tech Support

Apache Tomcat – WAR Backdoor

Apache Tomcat versions 7-9 contain a vulnerability within the WAR deployment setting which allows a malicious user to upload and deploy a JSP backdoor.  In this blog post, we will look at how an ethical hacker would go about enumerating and exploiting this vulnerability as well as patching and prevention.

In this scenario, Apache Tomcat 7.0.88 is hosted on a Windows 2012 server. (Tomcat login credentials remain default). An attacking machine running Kali linux uses tools such as nmap, msfvenom, and the metasploit framework to gain access to the server and upload a backdoor via a specially crafted jsp file. Follow along by creating a virtual environment including the tools listed.

  • Apache Tomcat 7.0.88 (Windows Server)
  • Linux Distro (Kali)
  • Nmap (Zenmap)
  • MsFvenom
  • Metasploit Framework

Looking at this from an ethical hacking standpoint, we likely already know the address of the target machine. With this information, nmap is used to further enumerate the target by scanning for open ports, running a traceroute, and taking a guess at what OS, services, and service versions are running. If you are not familiar with nmap (Zenmap) tool, you can find a quick start guide here: Evaluating System Security With Nmap

The portscan and banner grab shows an Apache server running on port 8080. By browsing to 10.10.10.95:8080 we can verify the server is up and what version of Tomcat is running.

Now that the version has been correctly identified we can check it for known exploits. A quick search results in: CVE-2017-12617 (1 Metasploit Module)

If we analyze how this exploit works, we can see that it relies on default credentials being set for Tomcat. If true, a reverse shell payload is crafted and deployed as a WAR file. Once the path is executed, a listener on the attacking machine receives the connection and provides a reverse shell.  Instead of compiling this exploit and running it against the target. Lets see if we can find the cpanel login and try it manually.

By clicking on Documentation located on the Tomcat homepage, we are able to come across the default path for the Tomcat Manager within the manual.

Browsing to the following address provides a login prompt: https://10.10.10.95:8080/manager/html

Clicking ok without providing credentials, leads to a 401 Unauthorized page that lucky for us, provides the default username and password. The default credentials can also be found by searching within the documentation.

Upon successfully logging into Tomcat Manager, we are greeted with an Application Manager page that provides the option to deploy WAR or jsp files.

At this point, msfvenom is used to create the malicious war file and then metasploit to set the payload and handler.

The file is then uploaded and deployed via the Application Manager . Once finished, browsing to the file destination will connect to the listener and pop a shell session. From here, an attacker would use methods to further elevate privileges and own the box resulting in a compromised server, loss of data, and even more severe consequences. We can see just how dangerous an attack like this can be and hopefully how important it is to change default account credentials.

*In order to prevent this exploit, stay on top of updates and never leave login credentials set to the device specific defaults. This is similar to how the Mirai botnet infected countless IoT devices .*

Sources:

  • https://tomcat.apache.org/security-7.html
  • https://github.com/mgeeky/tomcatWarDeployer
  • http://blog.opensecurityresearch.com/2012/09/manually-exploiting-tomcat-manager.html
  • https://www.youtube.com/watch?v=wF9CJ59D0tQ

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email