CVE-2025-24813: Apache Tomcat Partial PUT RCE
Eine kritische Sicherheitslücke in Apache Tomcat ermöglicht die nicht authentifizierte Remotecodeausführung mit nur zwei HTTP-Anfragen. Der Angriff nutzt die teilweise PUT-Funktion von Tomcat aus, um ein serialisiertes Java-Objekt hochzuladen und dann über eine GET-Anfrage eine Deserialisierung auszulösen. CVSS 9.8. Betrifft Tomcat 9, 10 und 11 mit Standardkonfiguration.
CVE-2025-24813AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HWas ist CVE-2025-24813?
Apache Tomcat unterstützt „partielles PUT“ – eine HTTP-Funktion, die es Clients ermöglicht, große Dateien in Segmenten mithilfe von Content-Range-Headern hochzuladen. Tomcat speichert diese Teil-Uploads als temporäre Dateien in einem Arbeitsverzeichnis. Die Sicherheitslücke entsteht durch zwei Fehler in dieser Implementierung:
- Der temporäre Dateiname wird vom Upload-URL-Pfad abgeleitet, der teilweise vom Angreifer kontrolliert wird
- Wenn der Java-Sitzungspersistenzmechanismus aktiviert ist (Speichern von Sitzungen in Dateien), kann Tomcat jede Datei im Arbeitsverzeichnis deserialisieren, die die Erweiterung
.sessionhat
Ein Angreifer kann diese Schwachstellen kombinieren, um ein bösartiges serialisiertes Java-Objekt, getarnt als teilweiser Upload, hochzuladen und dann dessen Deserialisierung auszulösen, indem er eine URL anfordert, die Tomcat als Sitzungssuche interpretiert.
🚨 Öffentlicher PoC innerhalb von 30 Stunden
Ein funktionierender Exploit wurde etwa 30 Stunden nach der Veröffentlichung von CVE-2025-24813 auf GitHub veröffentlicht. Der Zwei-Anfragen-Angriff lässt sich ganz einfach automatisieren, und innerhalb weniger Tage wurden massenhafte Ausnutzungskampagnen beobachtet. Jeder ungepatchte, mit dem Internet verbundene Tomcat-Server mit Standardkonfiguration sollte als gefährdet betrachtet werden.
Betroffene Versionen
Voraussetzungen für RCE: Beide Bedingungen müssen wahr sein:
- Beim Standard-Servlet ist das Schreiben aktiviert (
readonly=false) – NICHT die Standardeinstellung; muss explizit konfiguriert werden - Dateibasierte Sitzungspersistenz ist konfiguriert – ODER teilweise PUT-Schreibvorgänge landen in einem Pfad, auf den durch Deserialisierung zugegriffen werden kann
Hinweis zu den Voraussetzungen: Einige Quellen berichteten ursprünglich, dass die Voraussetzungen streng waren. Eine reale Analyse zeigte jedoch, dass bestimmte gängige Tomcat-Konfigurationen (einschließlich einiger Anwendungsserver-Distributionen) beide Bedingungen erfüllen. Unabhängig vom Patch – der CVSS-Score spiegelt die Worst-Case-Bedingungen wider.
Der Two-Request-Angriff
# Request 1: Upload malicious serialized object as partial PUT PUT /.xxxxx HTTP/1.1 Host: target.com Content-Type: application/octet-stream Content-Range: bytes 0-1233/1234 Content-Length: 1234 [serialized Java gadget chain payload — e.g., Commons Collections] # Tomcat stores this as a temp file in work directory # File name derived from URL: .xxxxx → stored as partial upload # Request 2: Trigger deserialization via session lookup GET /.xxxxx HTTP/1.1 Host: target.com Cookie: JSESSIONID=.xxxxx # Tomcat looks up session file matching the session ID # Finds attacker's file → deserializes it → RCE
Warum Tomcat ein hochwertiges Ziel ist
Apache Tomcat ist einer der am weitesten verbreiteten Java-Anwendungsserver weltweit und wird verwendet in:
- Enterprise Java-Webanwendungen
- Spring Boot-Anwendungen werden als WAR-Dateien bereitgestellt
- Legacy-J2EE-Anwendungen
- Interne HR-, ERP- und Geschäftsanwendungen
- Cloud-native Mikroservices
Ein RCE in Tomcat bedeutet oft Zugriff auf Datenbankanmeldeinformationen, interne APIs und sensible Geschäftsdaten, die von den darauf ausgeführten Anwendungen gespeichert werden.
Erkennung
# Check Tomcat version /opt/tomcat/bin/version.sh # or check catalina.jar manifest unzip -p /opt/tomcat/lib/catalina.jar META-INF/MANIFEST.MF | grep Implementation-Version # Check for suspicious partial PUT uploads in access logs grep 'PUT' /opt/tomcat/logs/localhost_access_log.* | grep -v '200\|201\|204' grep 'PUT.*Content-Range' /opt/tomcat/logs/localhost_access_log.* # Check for unusual files in Tomcat work directory find /opt/tomcat/work -name "*.session" -newer /opt/tomcat/conf/server.xml find /opt/tomcat/work -type f -newer /opt/tomcat/conf/server.xml # Check if default servlet write is enabled grep -r "readonly" /opt/tomcat/conf/web.xml /opt/tomcat/webapps/
Abhilfe
- Sofort patchen: Upgrade auf Tomcat 9.0.99+, 10.1.35+ oder 11.0.3+
- Standard-Servlet-Schreiben deaktivieren (falls nicht erforderlich):
<servlet> <servlet-name>default</servlet-name> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class> <init-param> <param-name>readonly</param-name> <param-value>true</param-value> <!-- Ensure this is true --> </init-param> </servlet> - Dateibasierte Sitzungspersistenz deaktivieren: Zur In-Memory- oder Datenbanksitzungspersistenz wechseln
- WAF-Regeln bereitstellen: HTTP-PUT-Anfragen mit
Content-Range-Headern blockieren, wenn sie nicht benötigt werden - Java-Deserialisierungsfilter verwenden: Konfigurieren Sie Java 9+-Serialisierungsfilter, um deserialisierbare Klassen einzuschränken
KENSAI-Erkennungsfähigkeit
- Tomcat-Versionserkennung: KENSAI erfasst Apache Tomcat-Versionen anhand von HTTP-Headern, Fehlerseiten und Standardpfaden in allen mit dem Internet verbundenen Assets
- Sichere Ausnutzungsprobe: Bestätigt die Ausnutzbarkeit von CVE-2025-24813, ohne Payloads auszuführen
- Konfigurationsprüfung: Überprüft das Vorhandensein eines schreibaktivierten Standardservlets und einer dateibasierten Sitzungspersistenz
- Interne Erkennung: Findet Tomcat-Instanzen, die in internen Netzwerken ausgeführt werden, über Agenten- oder Netzwerkscans
- Automatisierte erneute Tests: Bestätigt die Patch-Anwendung nach der Behebung
Finden Sie Ihre exponierten Tomcat-Server, bevor es Angreifer tun
KENSAI identifiziert jede Apache Tomcat-Instanz in Ihrer Umgebung und testet sie auf CVE-2025-24813 und andere kritische Schwachstellen im Java-Anwendungsserver.
Nach Tomcat-Schwachstellen suchen →