tomcatWarDeployer: Apache Tomcat auto WAR deployment & pwning penetration testing tool
Apache Tomcat auto WAR deployment & pwning penetration testing tool.
What is it?
This is a penetration testing tool intended to leverage Apache Tomcat credentials in order to automatically generate and deploy JSP Backdoor, as well as invoke it afterward and provide a nice shell (either via web gui, listening port binded on a remote machine or as a reverse tcp payload connecting back to the adversary).
In practice, it generates JSP backdoor WAR package on-the-fly and deploys it at the Apache Tomcat Manager Application, using valid HTTP Authentication credentials that pentester provided (or custom ones, in the end, we all love tomcat:tomcat ).
- 31.08.18: Added support for CSRF and JSESSIONID handling in Tomcat 7+ versions and for CVE-2007-1860 – you can check how it works automatically out-of-the-box on PentesterLab
git clone https://github.com/mgeeky/tomcatWarDeployer.git
sample usage on Kevgir 1 VM by canyoupwn.me running at 192.168.56.100:8080 :
The program will set-up a local listener for reverse-shell connection on the 192.168.56.102:4449 host (localhost) as in the example above. Then, after invoking JSP Backdoor it will automatically connect with the local listener, resulting in the shell being popped up. One can also skip -H parameter in order to go with bind shell functionality, whereas rather than setting local listener – the program will go and connect with remotely listening bind-shell. Finally, the above invocation will result in the following JSP application accessible remotely via WEB:
As one can see, there is password needlijked for leveraging deployed backdoor, preventing thus unauthenticated access during a conducted assessment.
Summing up, a user has spawned Web application providing WEB backdoor, authenticated via POST ‘password’ parameter that can be specified by a user or randomly generated by the program. Then, the application upon receiving X-Pass header in the invocation phase spawned a reverse connection to our netcat handler. The HTTP header is being requested here in order to prevent user refreshing WEB GUI and keep trying to bind or reverse connect. Also, this makes use of authentication to reach that code.
Copyright (C) 2018 mgeeky