Forscher des chinesischen Unternehmens Chaitin Tech haben es identifiziert () Im , eine Open-Source-Implementierung der Technologien Java Servlet, JavaServer Pages, Java Expression Language und Java WebSocket. Die Schwachstelle erhält den Codenamen Ghostcat und einen kritischen Schweregrad (9.8 CVSS). Das Problem ermöglicht es in der Standardkonfiguration, durch Senden einer Anfrage an Netzwerkport 8009 den Inhalt beliebiger Dateien aus dem Webanwendungsverzeichnis zu lesen, einschließlich Dateien mit Einstellungen und Anwendungsquellcodes.
Die Sicherheitslücke ermöglicht es auch, andere Dateien in den Anwendungscode zu importieren, wodurch die Codeausführung auf dem Server organisiert werden kann, wenn die Anwendung das Hochladen von Dateien auf den Server zulässt (ein Angreifer kann beispielsweise ein JSP-Skript unter dem Deckmantel eines hochladen). Bild über das Bild-Upload-Formular hochladen). Ein Angriff kann durch Senden einer Anfrage an einen Netzwerkport mit einem AJP-Handler erfolgen. Nach vorläufigen Angaben online Mehr als 1.2 Millionen Hosts akzeptieren Anfragen über das AJP-Protokoll.
Die Sicherheitslücke besteht im AJP-Protokoll und Implementierungsfehler. Zusätzlich zur Annahme von Verbindungen über HTTP (Port 8080) ermöglicht Apache Tomcat standardmäßig den Zugriff auf eine Webanwendung über das AJP-Protokoll (, Port 8009), ein leistungsoptimiertes binäres Äquivalent von HTTP, das häufig beim Erstellen eines Clusters von Tomcat-Servern oder zur Beschleunigung der Kommunikation mit Tomcat auf einem Reverse-Proxy oder Load Balancer verwendet wird.
AJP bietet eine Standardfunktion für den Zugriff auf Dateien auf dem Server, die auch zum Abrufen nicht offenlegungspflichtiger Dateien genutzt werden kann. Eigentlich sollte AJP nur vertrauenswürdigen Servern zugänglich sein, aber tatsächlich bestand die Standardkonfiguration von Tomcat darin, den Handler auf allen Netzwerkschnittstellen auszuführen und Anfragen ohne Authentifizierung zu akzeptieren. Der Zugriff ist auf alle Webanwendungsdateien möglich, einschließlich der Inhalte von WEB-INF, META-INF und allen anderen Verzeichnissen, die durch den Aufruf ServletContext.getResourceAsStream() angegeben werden. Mit AJP können Sie außerdem jede Datei in den zugänglichen Verzeichnissen der Webanwendung als JSP-Skript verwenden.
Das Problem tritt seit der Veröffentlichung des Zweigs von Tomcat 13.x vor 6 Jahren auf. Außer direkt Tomcat-Problem und Produkte, die es verwenden, wie Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP) sowie eigenständige Webanwendungen, die es verwenden . Ähnliche Sicherheitslücke (CVE-2020-1745) im Webserver Wird im Wildfly-Anwendungsserver verwendet. In 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 domain.xml aktiviert. In Spring Boot ist die AJP-Unterstützung standardmäßig deaktiviert. Mehr als ein Dutzend funktionierende Exploit-Beispiele wurden von verschiedenen Gruppen vorbereitet (
,
,
,
,
,
,
,
,
,
,
).
Sicherheitslücke in Tomcat-Releases behoben , и (Wartungszweig 6.x ). Sie können das Erscheinen von Updates in Distributionen auf diesen Seiten verfolgen: , , , , , . Um dieses Problem zu umgehen, können Sie den Tomcat AJP Connector-Dienst deaktivieren (binden Sie den Überwachungs-Socket an localhost oder kommentieren Sie die Zeile mit Connector port = „8009“ aus), wenn er nicht benötigt wird, oder authentifizierter Zugriff mithilfe der Attribute „secret“ und „address“, wenn der Dienst zur Interaktion mit anderen Servern und Proxys basierend auf mod_jk und mod_proxy_ajp verwendet wird (mod_cluster unterstützt keine Authentifizierung).
Source: opennet.ru