Ghostcat, die Sicherheitsanfälligkeit in Tomcat, die Code ersetzen kann

Ghostcat

Forscher von Chaitin Tech, China, freigelassen Informationen über eine neue Entdeckung, wie sie identifiziert haben eine Sicherheitslücke im beliebten Servlet-Container (Java Servlet, JavaServer Pages, Java Expression Language und Java WebSocket) Apache Tomcat (bereits als CVE-2020-1938 aufgeführt).

Diese Sicherheitslücke Ihnen wurde der Codename "Ghostcat" zugewiesen. und einen kritischen Schweregrad (9.8 CVSS). Das Problem ermöglicht in der Standardkonfiguration das Senden einer Anfrage über den Netzwerkanschluss 8009 um den Inhalt einer Datei im Webanwendungsverzeichnis zu lesen, einschließlich Anwendungsquellcodes und Konfigurationsdateien.

Durch die Sicherheitsanfälligkeit können auch andere Dateien in den Anwendungscode importiert werdenZulassen Code-Ausführung organisieren auf dem Server, wenn die Anwendung das Hochladen von Dateien auf den Server ermöglicht.

Zum Beispiel, ob die Website-Anwendung es Benutzern ermöglicht, Dateien hochzuladen, Ein Angreifer kann angreifen erste Eine Datei mit JSP-Skriptcode auf dem Server bösartig (die hochgeladene Datei selbst kann ein beliebiger Dateityp sein, z. B. Bilder, Nur-Text-Dateien usw. und fügen Sie dann die hochgeladene Datei hinzu, indem Sie die Sicherheitsanfälligkeit ausnutzen von Ghostcat, was letztendlich zur Ausführung von Remotecode führen kann.

Es wird auch erwähnt, dass ein Angriff ausgeführt werden kann, wenn es möglich ist, eine Anforderung mit einem AJP-Treiber an einen Netzwerkport zu senden. Nach vorläufigen Angaben, das Netzwerk gefunden Mehr als 1.2 Millionen Hosts akzeptieren Anforderungen mithilfe des AJP-Protokolls.

Die Sicherheitsanfälligkeit ist im AJP-Protokoll vorhanden und es wird nicht durch einen Implementierungsfehler verursacht.

Zusätzlich zum Akzeptieren von HTTP-Verbindungen (Port 8080) in Apache Tomcat standardmäßig es ist möglich zuzugreifen zur Webanwendung unter Verwendung des AJP-Protokolls (Apache Jserv Protocol, Port 8009), ein binäres Analogon von HTTP, das für eine höhere Leistung optimiert ist und im Allgemeinen beim Erstellen eines Clusters von Tomcat-Servern oder zur Beschleunigung der Interaktion 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 verwendet werden können, einschließlich des Empfangs von Dateien, die nicht offengelegt werden müssen.

Es versteht sich, dass der Zugang zu AJP steht nur vertrauenswürdigen Bediensteten offenTatsächlich wurde der Treiber in der Standardkonfiguration von Tomcat auf allen Netzwerkschnittstellen gestartet und Anforderungen wurden ohne Authentifizierung akzeptiert.

Der Zugriff auf jede Datei in der Webanwendung ist möglich, einschließlich des Inhalts von WEB-INF, META-INF und aller anderen Verzeichnisse, die über den Aufruf von ServletContext.getResourceAsStream () zurückgegeben werden. Mit AJP können Sie auch jede Datei in Verzeichnissen verwenden, die einer Webanwendung als JSP-Skript zur Verfügung stehen.

Das Problem ist offensichtlich, seit der Tomcat 6.x-Zweig vor 13 Jahren veröffentlicht wurde. Neben Tomcat selbst, Das Problem betrifft auch die Produkte, die es verwendenB. Red Hat JBoss-Webserver (JWS), JBoss Enterprise Application Platform (EAP) sowie eigenständige Webanwendungen, die Spring Boot verwenden.

auch Eine ähnliche Sicherheitslücke wurde gefunden (CVE-2020-1745) auf dem Undertow-Webserver wird auf dem Wildfly-Anwendungsserver verwendet. Derzeit haben verschiedene Gruppen mehr als ein Dutzend Arbeitsbeispiele für Exploits vorbereitet.

Apache Tomcat hat die Versionen 9.0.31, 8.5.51 und 7.0.100 offiziell veröffentlicht um diese Sicherheitsanfälligkeit zu beheben. Um diese Sicherheitsanfälligkeit korrekt zu behebenmüssen Sie zunächst feststellen, ob der Tomcat AJP Connector-Dienst in Ihrer Serverumgebung verwendet wird:

  • Wenn kein Cluster oder Reverse Proxy verwendet wird, kann grundsätzlich festgestellt werden, dass AJP nicht verwendet wird.
  •  Wenn nicht, müssen Sie herausfinden, ob der Cluster- oder Reverse-Server mit dem Tomcat AJP Connect-Dienst kommuniziert

Es wird auch erwähnt, dass Updates sind jetzt in den verschiedenen Linux-Distributionen verfügbar wie: Debian, Ubuntu, RHEL, Fedora, SUSE.

Um dieses Problem zu umgehen, können Sie den Tomcat AJP Connector-Dienst deaktivieren (den Listening-Socket an localhost binden oder die Zeile mit Connector-Port = »8009 ″ auskommentieren), falls dies nicht erforderlich ist, oder den authentifizierten Zugriff konfigurieren.

Wenn Sie mehr darüber erfahren möchten, können Sie sich beraten den folgenden Link. 


Hinterlasse einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert mit *

*

*

  1. Verantwortlich für die Daten: Miguel Ángel Gatón
  2. Zweck der Daten: Kontrolle von SPAM, Kommentarverwaltung.
  3. Legitimation: Ihre Zustimmung
  4. Übermittlung der Daten: Die Daten werden nur durch gesetzliche Verpflichtung an Dritte weitergegeben.
  5. Datenspeicherung: Von Occentus Networks (EU) gehostete Datenbank
  6. Rechte: Sie können Ihre Informationen jederzeit einschränken, wiederherstellen und löschen.