Sicherheitsanfälligkeit in Apache Tomcat, die das Einfügen von JSP-Code und den Zugriff auf Dateien von Webanwendungen ermöglicht

Forscher des chinesischen Unternehmens Chaitin Tech haben festgestellt, eine Schwachstelle (CVE-2020-1938) bei Apache Tomcat, eine Open-Source-Implementierung der Technologien Java Servlet, JavaServer Pages, Java Expression Language und Java WebSocket. Der Schwachstelle wurde der Codename Ghostcat zugewiesen und sie hat ein kritisches Gefahrenlevel (9.8 CVSS). Das Problem ermöglicht es, in der Standardkonfiguration über das Senden einer Anfrage an den Netzwerkport 8009 Inhalte beliebiger Dateien aus dem Verzeichnis der Webanwendung zu lesen, einschließlich der Konfigurationsdateien und des Quellcodes der Anwendung.

Die Schwachstelle ermöglicht es zudem, andere Dateien in den Anwendungscode zu importieren, was die Ausführung von Code auf dem Server ermöglicht, wenn die Anwendung das Hochladen von Dateien auf den Server erlaubt (zum Beispiel könnte ein Angreifer ein JSP-Skript unter dem Vorwand eines Bildes über ein Upload-Formular hochladen). Der Angriff kann erfolgen, wenn eine Anfrage an den Netzwerkport mit dem AJP-Handler gesendet werden kann. Vorläufigen Daten zufolge wurden in den Netzwerken mehr als 1,2 Millionen Hosts gefunden, die Anfragen über das AJP-Protokoll annehmen. Die Schwachstelle ist im AJP-Protokoll vorhanden und

nicht durch einen Fehler in der Implementierung verursacht. Neben der Annahme von Verbindungen über HTTP (Port 8080) ist in Apache Tomcat standardmäßig der Zugriff auf die Webanwendung über das AJP-Protokoll erlaubt ( Apache Jserv Protocol, Port 8009), das eine für höhere Leistung optimierte binäre Version von HTTP ist, die normalerweise beim Erstellen eines Clusters von Tomcat-Servern oder zur Beschleunigung der Interaktion mit Tomcat über einen Reverse-Proxy oder Load-Balancer verwendet wird.AJP bietet eine integrierte Funktion für den Zugriff auf Dateien auf dem Server, die unter anderem für den Erhalt von Dateien genutzt werden kann, die nicht offengelegt werden sollen. Man nimmt an, dass der Zugang zu AJP nur für vertrauenswürdige Server geöffnet ist, aber in der Praxis wurde in der Standardkonfiguration von Tomcat der Handler auf allen Netzwerkinterfaces ausgeführt, und Anfragen wurden ohne Authentifizierung angenommen. Der Zugriff auf beliebige Dateien der Webanwendung ist möglich, einschließlich Inhalte von WEB-INF, META-INF und anderen Verzeichnissen, die über den Aufruf von ServletContext.getResourceAsStream() bereitgestellt werden. AJP ermöglicht es auch, jede Datei in den für die Webanwendung verfügbaren Verzeichnissen als JSP-Skript zu verwenden.

Das Problem tritt seit der vor 13 Jahren veröffentlichten Version Tomcat 6.x auf. Neben Tomcat selbst betrifft das Problem

Das Problem tritt seit dem vor 13 Jahren veröffentlichten Tomcat 6.x auf. Neben Tomcat selbst betrifft das Problem betroffen und nutzt Produkte wie den Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP) sowie selbstständige Webanwendungen, die Spring Boot. Eine ähnliche Schwachstelle (CVE-2020-1745) ungefähr im Webserver Undertow, der im Anwendungsserver Wildfly verwendet wird. In JBoss und Wildfly ist das AJP-Protokoll standardmäßig nur in den standalone-full-ha.xml-, standalone-ha.xml- und ha/full-ha-Profilen in domain.xml aktiviert. In Spring Boot ist die AJP-Unterstützung standardmäßig deaktiviert. Derzeit haben verschiedene Gruppen mehr als ein Dutzend funktionierender Exploit-Beispiele vorbereitet (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Die Schwachstelle wurde in den Tomcat-Versionen 9.0.31, 8.5.51 und 7.0.100 (Support für den Branch 6.x wurde eingestellt). Informationen über das Erscheinen von Updates in den Distributionen finden Sie auf diesen Seiten: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Als vorübergehende Schutzmaßnahme kann der Tomcat AJP Connector-Dienst deaktiviert werden (den Listener-Socket an localhost binden oder die Zeile mit Connector port = "8009" auskommentieren), wenn er nicht benötigt wird, oder angepasst werden authentifizierter Zugriff mithilfe der Attribute "secret" und "address", wenn der Dienst zur Interaktion mit anderen Servern und Proxys auf Basis von mod_jk und mod_proxy_ajp verwendet wird (mod_cluster unterstützt keine Authentifizierung).

Quelle: opennet.ru