Sicherheitsempfehlungen
Für einen sicheren Betrieb von MapEdit empfehlen wir, mindestens die folgenden Sicherheitsmaßnahmen umzusetzen:
- Verwenden Sie eine aktuelle und unterstützte MapEdit-Version und installieren Sie verfügbare MapEdit-Sicherheitsupdates zeitnah.
- Halten Sie das Betriebssystem sowie alle eingesetzten Systemkomponenten aktuell und installieren Sie verfügbare Sicherheitsupdates zeitnah.
- Verwenden Sie auf allen Servern gültige und vertrauenswürdige TLS-/SSL-Zertifikate.
- Beschränken Sie die Firewall-Freigaben auf die für den Betrieb notwendigen Ports und Verbindungen, beispielsweise HTTPS über Port 443.
- Aktivieren Sie den SecureMode in MapEdit Core 25.1.x oder höher. Ab MapEdit Core 26.1 ist der SecureMode standardmäßig aktiviert.
- Beschränken Sie im AppBuilder die Datenbankberechtigungen (z. B. Lesen und Schreiben) für jede Benutzergruppe auf die tatsächlich benötigten Berechtigungen.
- Verwenden Sie für den Zugriff von MapEdit auf PostgreSQL oder Oracle einen separaten Datenbankbenutzer mit minimal erforderlichen Berechtigungen für die jeweilige MapEdit-Datenbankverbindung.
- Beschränken Sie im AppBuilder die Funktionsberechtigungen jeder Benutzergruppe auf die tatsächlich benötigten Funktionen. Dies betrifft beispielsweise Funktionen zum Hochladen von Dateien.
- Aktivieren Sie eine serverseitige Validierung zulässiger Dateitypen und MIME-Typen, um das Hochladen nicht erlaubter oder ausführbarer Inhalte zu verhindern.
- Schützen Sie den Zugriff auf den TileServer durch ein Passwort und deaktivieren Sie die URL-Übergabe, sofern diese nicht benötigt wird.
- Nutzen Sie nach Möglichkeit die Authentifizierung über Microsoft Entra ID. Bei Verwendung der MapEdit-Benutzerauthentifizierung sollten sichere Passwörter verwendet werden. Sofern verfügbar, sollte zusätzlich eine Mehrfaktor-Authentifizierung (MFA) aktiviert werden, beispielsweise bei MapEdit Mobile.
- Vergeben Sie Benutzerkonten und Berechtigungen nach dem Least-Privilege-Prinzip. Benutzer sollten ausschließlich die Berechtigungen erhalten, die sie für ihre Aufgaben benötigen.
- Überprüfen Sie Benutzerkonten, Gruppen und zugewiesene Berechtigungen regelmäßig und entfernen Sie nicht mehr benötigte Konten und Berechtigungen.
MapEdit verwendet für die Authentifizierung ein zufälliges Token mit 128 Bit (32 Hexadezimalzeichen). Abhängig von der IT-Infrastruktur und dem Schutzbedarf Ihrer Umgebung empfehlen wir zusätzliche Sicherheitsmaßnahmen. Dazu können beispielsweise ein VPN-Zugang, die Einschränkung des Netzwerkzugriffs, IP-Allowlisting oder weitere kundenspezifische Zugriffsbeschränkungen gehören. Die Auswahl und Konfiguration dieser Maßnahmen sollte gemeinsam mit Ihrer zuständigen IT- bzw. IT-Security-Abteilung erfolgen.
Bekannte Sicherheitswarnungen
CVE-2025-43949 MapEdit Mobile / Core
22.04.2025 Bei einem Sicherheitstest wurde festgestellt das eine SQL-Injection möglich ist. Dies betrifft die REST-API bzw. Anwendung MapEdit Core auf dem MapEdit Server der Version 24.2 oder älter.
The MapEdit REST endpoint data/<datasource>/query executes an SQL query based on user provided parameters. This allows arbitrary SQL queries to be executed on the underlying databases (PostgreSQL and Oracle).
Handlungsempfehlungen
Installation von MapEdit 25.1 oder höher und Aktivierung des sicheren MapEdit Modus MapEdit.SecureMode=true im WildFly.
CVE-2021-44228 Log4j
13.12.2021 Das Bundesministerium für Sicherheit in der Informationstechnologie (BSI) hat am 11.12.2021 eine Warnung herausgegeben, dass die Java-Bibliothek Log4j durch eine Remote Execute Lücke bedroht ist.
https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html
Hinweise
Wir nutzen Log4j in Verbindung mit Apache Tomcat und unseren Produkten MuM MapEdit TileServer und MuM MapEdit Mobile (bis zur Version 20.x).
Laut den derzeit uns vorliegenden Informationen z.B. Infos von Cloudflare ist die dabei von uns genutzte Log4j Version 1.2.17 nicht betroffen, da es dort die angegriffene Funktionalität noch nicht gibt (sondern erst Versionen ab 2.0). Zudem sind wir nicht betroffen sind, weil wir nicht die Konfiguration mit dem JMSAppender (wie beim BSI verlinkt) nutzen.
siehe Seite 3 unten, Update 2 in dieser PDF:
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=6
In Verbindung mit WildFly wird Log4j von MapEdit TileServer, MapEdit Mobile und MapEdit Portal gar nicht genutzt, sondern die interne Protokollierung verwendet. Damit tritt diese Sicherheitslücke bei unseren Produkten in Verbindung mit dem Applikationsserver WildFly nicht auf.
Noch eine wichtige Ergänzung und Unterscheidung bei der Analyse dazu bei WildFly Installationen:
- Der WildFly stellt die log4j-api-2.14.1.jar bereit, um Anwendungen die gegen log4j programmiert wurden, die Nutzung des integrierten Loggings über diese API zu erlauben.
- Problematisch in Zusammenhang mit diesem Sicherheitsproblem wäre die log4j-core-2.14.1.jar, welche die eigentliche Implementierung des Loggings zur Verfügung stellt und die ursächliche Klasse JndiLookup bereitstellt. Diese wird allerdings beim WildFly nicht mit ausgeliefert, da er ein eigenes Logging-Modul von IBM verwendet.
Hier geht es wirklich nur darum, die abstrakte API bereitzustellen und dann intern auf das eigene Logging umzuleiten. In der module.xml im selben Verzeichnis sieht man das auch, da dort auf das interne Modul org.jboss.logmanager.log4j2 verwiesen wird.
Bei Apache Tomcat verwenden wir in Verbindung mit unseren MapEdit Produkten die ältere, nicht betroffene Log4j Version 1.2.x. Werden demnächst im Rahmen der Softwarepflege trotzdem eine Aktualisierung auf eine Log4j2 durchführen.
Sollten Sie im Internet z.B. MuM MapEdit Mobile in einer älteren Version (Release 20.x oder älter) betreiben, empfehlen wir bei Sicherheitsfragen wie bisher auch, immer ein Update auf die aktuellsten Versionen des Betriebssystems, sowie aller dort installierten Komponenten. Bei z.B. MuM MapEdit Mobile eben ein Update auf das aktuellste MapEdit Release und damit die Umstellung von Tomcat auf WildFly.
Oracle Datenbanken
Auch Oracle hat reagiert und entsprechende Warnung publiziert.
Bitte beachten Sie dass die Datenbank Server nur über die Applikationen erreicht werden können und somit die Kommunikation mit der Datenbank komplett selber steuern und auch nur für angemeldete Benutzer freigegeben haben. Dh. die Wahrscheinlichkeit einen Angriffspunkt hier zu bieten ist wesentlich geringer, als die in Verbindung mit einem Web/Applikationsserver.
Wichtig für uns ist hier, dass die Oracle Datenbank Produkte nicht betroffen sind.
Oracle products not requiring patches
The following products were previously listed as "Under Investigation". Oracle has completed its review and, at this point in time, believe that the following products are not affected by vulnerability CVE-2021-44228:
....
Oracle Database [Product ID 5]
....
Allerdings steht auch in der Liste:
Oracle products with patches pending
Oracle has determined that the following Oracle products are vulnerable and do not currently have patches available for CVE-2021-44228:
....
Oracle Spatial and Graph [Product ID 619]
....
Bedeutet, es gibt aktuell keinen Patch von Oracle für die Spatial and Graph Erweiterung. Wir vermuten dass diese Möglichkeit an dem dort mit im Produkt enthaltenen Kartenserver und weniger an den Spatial Erweiterungen der Datenbank liegen könnte.