CVE-2024-36401 in Open-Source GeoServer setzt Systeme der Remote-Code-Ausführung aus

In diesem Blog befassen wir uns mit CVE-2024-36401 - einer Sicherheitslücke, die in GeoServer gefunden wurde, einem Open-Source-Java-basierten Server, der häufig für die Bearbeitung und den Austausch von Geodaten verwendet wird. Diese Schwachstelle, die RCE (Remote Code Execution) durch nicht authentifizierte Benutzer ermöglichen könnte, unterstreicht, wie wichtig es ist, GeoServer-Bereitstellungen so schnell wie möglich zu patchen.

In unserer neuesten Sicherheitsanalyse untersuchen zwei OPSWAT diese Bedrohung:

• Eingehende Untersuchung der Angriffsvektoren des CVE
• Identifizierung von Sicherheitslücken, die Angreifer nutzen könnten, um GeoServer auszunutzen
• Simulieren, wie Angreifer GeoServer-Einsätze kompromittieren können

Wir werden auch erläutern, wie die SBOM-Technologie OPSWAT diese Schwachstelle aufspüren kann und wie Teams ihre Geodateninfrastruktur sichern können, bevor Angreifer zuschlagen.

GeoServer Übersicht

GeoServer ist ein Java-basierter Open-Source-Server für die Anzeige, Bearbeitung und den Austausch von Geodaten. Ursprünglich wurde GeoServer im Jahr 2001 von TOPP (The Open Planning Project) ins Leben gerufen und entwickelt, um das öffentliche Engagement in der Verwaltung und Stadtplanung durch den offenen Austausch von Geodaten zu verbessern. Mehr als zwei Jahrzehnte später ist GeoServer zu einer robusten Plattform gereift, die in der Lage ist, verschiedene Geodatenformate zu verarbeiten und mit unterschiedlichen Datenquellen zu integrieren.

GeoServer bietet Dienste, die auf den OGC-Standards (Open Geospatial Consortium) basieren, darunter:

• WFS (Web Feature Service) - Ermöglicht das Erstellen, Ändern und Austauschen von geografischen Informationen im Vektorformat über HTTP.
• WCS (Web Coverage Service) - Erleichtert den Zugang zu Rasterdaten (z. B. Satellitenbilder) für komplexe Modellierungen und Analysen.
• WMS (Web Map Service) - Bietet eine einfache HTTP-Schnittstelle für die Anforderung von Kartenbildern.

Hintergrund zu CVE-2024-36401

CVE-2024-36401 betrifft GeoServer-Versionen vor 2.25.2, 2.24.4 und 2.23.6. Er entsteht durch die unsichere Auswertung von Eigenschaftsnamen als XPath-Ausdrücke über mehrere OGC-Anfrageparameter. Angreifer können diese Schwachstelle ausnutzen, um RCE (Remote Code Execution) zu erzeugen, indem sie manipulierte Eingaben in eine Standard-GeoServer-Installation einschleusen.

Laut GitHub Security Advisories wird diese Sicherheitslücke mit einem CVSS v3.1-Wert von 9.8 (kritisch) bewertet.

GeoServer's einfache vs. komplexe Funktionen

GeoServer unterstützt sowohl einfache als auch komplexe Feature-Typen, um verschiedene Geodatenstrukturen, von flachen bis hin zu komplizierten, verschachtelten Datensätzen, zu unterstützen. Die fehlerhafte Handhabung von XPath-Ausdrücken in diesen Datentypen macht CVE-2024-36401 jedoch ausnutzbar.

Einfache Merkmale

Einfache Featuretypen stellen einfache Geodaten in einem flachen Format dar, bei dem jede Zeile in einer Datenbank einem Geomerkmal entspricht und jedes Attribut direkt auf ein XML-Element abgebildet wird.

Beispielsweise kann eine Tabelle, die Unternehmen mit Spalten wie ID, Name und Standort darstellt, leicht in einfache XML-Funktionen umgewandelt werden.

Komplexe Merkmale

Im Gegensatz dazu können komplexe Featuretypen kompliziertere Daten verarbeiten. Dieser Merkmalstyp unterstützt verschachtelte Eigenschaften und Beziehungen zwischen verschiedenen Datensätzen. Diese komplexen Schemata werden nicht automatisch generiert, sondern anhand von Gemeinschaftsstandards definiert, wie sie in der GeoServer-Erweiterung "Application Schema" beschrieben sind.

Beispiel:

Unter der vorherigen Tabelle companies fügen wir einen Fremdschlüssel hinzu gu_id zur Beschreibung der Beziehung zwischen einem Unternehmen und seiner entsprechenden geologischen Einheit:

Die Informationen zu den geologischen Einheiten werden separat in der Tabelle geologische Einheit:

Mit Hilfe dieser Tabellen können wir das Unternehmen einem sa:SamplingCompanydie eine verschachtelte gsml:GeologischeEinheit. Dieser Aufbau schafft ein komplexes Merkmal, da es sich um verschachtelte Typen und Beziehungen handelt, die durch Gemeinschaftsspezifikationen und nicht durch automatisch generierte Schemata definiert sind.

Diese Flexibilität ist für die Modellierung komplexer realer Szenarien unerlässlich, birgt aber auch Schwachstellen, da sie auf fortgeschrittene Verarbeitungstechniken wie die JXPath-Auswertung angewiesen ist, um die verschachtelten Strukturen effektiv zu verwalten.

Wie die Anfälligkeit entsteht

GeoServer ist so konzipiert, dass er die XPath-Auswertung zur Verarbeitung komplexer Feature-Typen (wie sie in Application Schema-Datenspeichern zu finden sind) verwendet. Aber aufgrund unsachgemäßer Handhabung wendet er die XPath-Auswertung fälschlicherweise auch auf einfache Merkmalstypen an. Dies schafft einen Angriffsvektor, weil:

1. GeoServer stützt sich auf die GeoTools-Bibliothek, um Eigenschaftsnamen während des Datenabrufs auszuwerten.
2. Die commons-jxpath Bibliothek, die für die Verarbeitung von XPath-Ausdrücken verwendet wird, fehlt eine ordnungsgemäße Validierung, wodurch beliebiger Code bei der Verarbeitung von XPath-Ausdrücken ausgeführt werden kann.
3. Dieser Fehler setzt alle GeoServer-Instanzen potenziellen RCE-Schwachstellen aus, da ein Angreifer eine bösartige Anfrage erstellen kann, die diese unsichere XPath-Ausführung ausnutzt, um den Server zu kontrollieren.

Überblick über den Exploitation-Workflow

• A POST Anfrage wird an den GetPropertyValue Vorgang. Dann versucht GeoServer, die Eigenschaft abzurufen (oder valueReference) für ein bestimmtes Merkmal.
• Wenn die angeforderte Eigenschaft in der Tabelle Feature Type Details vorhanden ist, verarbeitet GeoServer sie normal.

• Wenn die Eigenschaft jedoch nicht aufgeführt ist, greift GeoServer auf die commons-jxpath Bibliothek, um den Anfrageparameter als XPath-Ausdruck zu interpretieren.
• Seit commons-jxpath erlaubt die Ausführung von Java-Code direkt aus XPath. Dieser Fallback-Mechanismus ermöglicht es, vom Benutzer bereitgestellte Anforderungsparameter zur Remotecodeausführung auszunutzen. Einfach ausgedrückt: Ein Angreifer kann bösartigen Code einschleusen, um RCE zu erreichen.

Ausnutzung und Analyse von Schwachstellen

JXPath und die Java Execution Bridge

Die commons-jxpath Bibliothek, die gemeinhin als JXPath bezeichnet wird, ermöglicht die Navigation durch Java-Objektgraphen (JavaBeans, DOM-Objekte usw.) mit Hilfe der XPath-Syntax. Wenn Sie zum Beispiel ein einfaches Employee-Objekt mit Eigenschaften wie Name und Adresse haben, können Sie mit JXPath diese Eigenschaften abfragen, als wären sie Knoten in einem XML-Dokument.

Ausnutzung von Erweiterungsfunktionen

Neben den Standardfunktionen unterstützt JXPath auch Erweiterungsfunktionen, die eine Brücke zu Java bilden. Diese "Brücke zu Java" ist von entscheidender Bedeutung, da sie es beispielsweise ermöglicht, Java-Funktionen direkt in XPath-Abfragen aufzurufen:

Aufgrund der wenigen Einschränkungen, welche Java-Methoden über diese Brücke aufgerufen werden können, kann ein Angreifer die exec() Funktion (oder ähnliche Methoden), um beliebige Befehle auf dem Server auszuführen.

WFS GetPropertyValue

Der WFS von GeoServer ermöglicht den Benutzern die Abfrage und Bearbeitung von Geodaten. Unter normalen Bedingungen ist der WFS GetPropertyValue Operation würde einfach die angeforderte Eigenschaft in einer XML-Struktur zurückgeben.

Workflow-Analyse

1. Ein Angreifer sendet eine POST-Anfrage an /geoserver/wfs.
2. Der GeoServer untersucht das äußerste XML-Tag.wfs:GetPropertyValue-um zu bestimmen, welcher Vorgang ausgeführt werden soll.
3. GeoServer delegiert dann die Anfrageparameter an die entsprechende Methode in der WFS-Klasse. In diesem Szenario leitet der Dispatcher die Anfrage an die GetPropertyValue Methode.

1. Innerhalb der Klasse DefaultWebFeatureService20 (WFS) wird diese GetPropertyValue Methode leitet die Parameter des Benutzers an einen Handler mit demselben Namen weiter.
2. Der Handler ist run() Methode erhält die Anfrage, einschließlich der kritischen valueReference Parameter, der vom Benutzer gesteuert wird.

1. Während der run() Methode ruft der GeoServer die referenzWert und ruft seine evaluate() Funktion.

1. Wenn valueReference nicht mit den vordefinierten Eigenschaften von GeoServer übereinstimmt, setzt GeoServer sie standardmäßig auf den FeaturePropertyAccessor, die Folgendes interpretiert valueReference als XPath-Ausdruck.

1. Die get() Methode in FeaturePropertyAccessor verwendet commons-jxpath um die XPath-Abfrage auszuführen. Hier wird der Benutzer valueReference wird direkt in den xpath-Parameter ohne Validierung übergeben. Über JXPathContext.newContext()initialisiert der GeoServer eine Umgebung für XPath-Abfragen und führt diese dann über iteratePointers().

Da JXPath Erweiterungsfunktionen unterstützt, können Angreifer bösartigen Code in den XPath-Ausdruck einfügen und so die Ausführung von beliebigem Code auf der GeoServer-Instanz auslösen.

Diese Kette von Ereignissen zeigt, wie unsicher der Umgang mit dem valueReference Parameter kann zu RCE führen, was eine ernsthafte Sicherheitsbedrohung für anfällige GeoServer-Einsätze darstellt.

Simulation des Angriffs

Um diese Ausnutzung in einem realen Szenario zu simulieren, haben unsere OPSWAT GeoServer auf einem lokalen Windows-Rechner installiert. Beim Zugriff auf GeoServer wurde die folgende Oberfläche angezeigt.

Sobald der Server läuft, kann ein Angreifer die Sicherheitslücke ausnutzen, indem er eine POST-Anfrage mit einem bösartigen XPath-Ausdruck über valueReference zum Endpunkt /geoserver/wfs.

Ergebnis: Nachdem die Anfrage gesendet wurde, führt der bösartige XPath-Ausdruck einen Systembefehl aus und löst den Start der Calculator-Anwendung aus.

Abhilfemaßnahmen und Empfehlungen

Eine einfache Schwachstelle kann sich zu einem Angriff auf die Software-Lieferkette ausweiten, insbesondere bei Projekten, die auf Open-Source-Software wie GeoServer basieren. DieOPSWAT SBOM-Technologie (Software Bill of Materials) hilft bei der Identifizierung von Schwachstellen wie CVE-2024-36401 in Ihrer Codebasis.

Dieses Beispiel zeigt, wie OPSWAT SBOM:

1. Erkennt die von Sicherheitslücken betroffenen Softwarekomponenten.
2. Bewertet und stuft den Schweregrad der Sicherheitslücke ein - hier sind die GeoServer CVEs als "kritisch" gekennzeichnet.
3. Identifiziert die betroffene Version.
4. Empfiehlt die korrigierte Version, damit die Entwicklungsteams umgehend Patches einspielen oder Abhilfemaßnahmen ergreifen können.

Weitere empfohlene Schritte

1. Aktualisieren Sie GeoServer: Aktualisieren Sie auf die GeoServer-Versionen 2.25.2, 2.24.4 oder 2.23.6 (oder höher), in denen die Sicherheitslücke gepatcht ist.
2. Audit-Abhängigkeiten: Verwenden Sie regelmäßig Tools wie OPSWAT SBOM, um veraltete Bibliotheken zu identifizieren (z. B., commons-jxpath) in Ihrer Umgebung.
3. Beschränken Sie den Zugang: Setzen Sie GeoServer hinter Firewalls oder Authentifizierungsschichten ein, um die Angriffsfläche zu minimieren.
4. Überwachen Sie Sicherheitshinweise: Behalten Sie die offiziellen GeoServer-Versionshinweise und CVE-Datenbanken im Auge, um über neue Patches auf dem Laufenden zu bleiben.

Über OPSWAT SBOM

OPSWAT SBOM unterstützt die gängigsten Programmiersprachen und bietet Software-Entwicklungsteams Einblick in Open-Source-Bibliotheken von Drittanbietern, deren Abhängigkeiten und die neuesten verfügbaren Versionen für Upgrades. Entwickler können OPSWAT SBOM in ihren Quellcode und in Containerdienste wie GitHub, BitBucket, GitLab, Amazon ECR, DockerHub und andere integrieren. Erfahren Sie mehr über SBOM.

Sprechen Sie noch heute mit einem Experten, um zu erfahren, wie Sie die OPSWAT und -Lösungen in Ihre bestehende Infrastruktur und Arbeitsabläufe integrieren können: