Forscher des chinesischen Unternehmens Chaitin Tech haben entdeckt, () bei , eine Open-Source-Implementierung der Technologien Java Servlet, JavaServer Pages, Java Expression Language und Java WebSocket. Die Sicherheitsanfälligkeit trägt den Codenamen Ghostcat und wird als kritisch eingestuft (9.8 CVSS). Das Problem ermöglicht es, in der Standardkonfiguration über das Senden einer Anfrage an den Netzwerkport 8009 den Inhalt beliebiger Dateien im Verzeichnis der Webanwendung zu lesen, einschließlich Konfigurationsdateien und des Quellcodes der Anwendung.
Die Sicherheitsanfälligkeit ermöglicht auch das Importieren anderer Dateien in den Anwendungscode, was die Ausführung von Code auf dem Server ermöglicht, wenn die Anwendung das Hochladen von Dateien auf den Server zulässt (z.B. kann ein Angreifer ein JSP-Skript als Bilddatei über ein Upload-Formular hochladen). Ein Angriff kann erfolgen, wenn eine Anfrage an den Netzwerkport mit dem AJP-Handler gesendet werden kann. Vorläufigen Informationen zufolge gibt es im Internet mehr als 1,2 Millionen Hosts, die Anfragen über das AJP-Protokoll akzeptieren.
Die Sicherheitsanfälligkeit ist im AJP-Protokoll vorhanden, und Implementierungsfehler. Neben dem Empfang von Verbindungen über HTTP (Port 8080) erlaubt Apache Tomcat standardmäßig den Zugriff auf Webanwendungen über das Protokoll AJP (, Port 8009), welches eine optimierte binäre Alternative zu HTTP ist, die in der Regel zur Erreichung höherer Leistungsfähigkeit verwendet wird, insbesondere beim Erstellen eines Clusters aus Tomcat-Servern oder zur Beschleunigung der Interaktion mit Tomcat über einen Reverse-Proxy oder Lastenausgleich.
AJP bietet eine integrierte Funktion zum Zugreifen auf Dateien auf dem Server, die beispielsweise zum Abrufen von nicht öffentlich zugänglichen Dateien verwendet werden kann. Es wird erwartet, dass der Zugang zu AJP nur für vertrauenswürdige Server geöffnet ist, jedoch wurde in der Standardkonfiguration von Tomcat der Handler auf allen Netzwerkinterfaces gestartet und Anfragen wurden ohne Authentifizierung angenommen. Der Zugang zu allen Dateien der Webanwendung ist möglich, einschließlich der Inhalte von WEB-INF, META-INF und anderen Verzeichnissen, die über den Aufruf ServletContext.getResourceAsStream() bereitgestellt werden. AJP ermöglicht auch die Verwendung beliebiger Dateien in den für die Webanwendung verfügbaren Verzeichnissen als JSP-Skript.
Das Problem trat erstmals mit der vor 13 Jahren veröffentlichten Tomcat 6.x-Version auf. Neben Tomcat selbst betrifft das Problem auch Produkte wie den Red Hat JBoss Web Server (JWS), die JBoss Enterprise Application Platform (EAP) sowie eigenständige Webanwendungen, die . Eine ähnliche Sicherheitsanfälligkeit (CVE-2020-1745) im Webserver , der im Wildfly-Anwendungsserver verwendet wird. Im JBoss und Wildfly ist das AJP-Protokoll standardmäßig nur in den Profilen standalone-full-ha.xml, standalone-ha.xml und ha/full-ha in der domain.xml aktiviert. In Spring Boot ist die AJP-Unterstützung standardmäßig deaktiviert. Derzeit haben verschiedene Gruppen mehr als ein Dutzend funktionsfähiger Exploit-Beispiele bereitgestellt (
,
,
,
,
,
,
,
,
,
,
).
Die Sicherheitsanfälligkeit wurde in den Tomcat-Versionen , und (Wartung der 6.x-Version ). Informationen über Updates in den Distributionen können auf diesen Seiten verfolgt werden: , , , , , . Als vorübergehende Maßnahme zur Sicherung kann der Tomcat AJP Connector-Service deaktiviert werden (indem der Listener-Socket an localhost gebunden oder die Zeile mit Connector port = "8009" kommentiert wird), wenn er nicht benötigt wird, oder authentifizierter Zugriff mittels der Attribute „secret“ und „address“, wenn der Dienst zur Interaktion mit anderen Servern und Proxy-Servern auf Basis von mod_jk und mod_proxy_ajp verwendet wird (mod_cluster unterstützt keine Authentifizierung).
Quelle: opennet.ru
