Thought Leadership
Die Sicherheitsforscher von JFrog haben vor kurzem ein Problem in der H2-Datenbankkonsole aufgedeckt, für das ein kritisches CVE vergeben wurde – CVE-2021-42392. Dieses Problem hat die gleiche Ursache wie die kürzlich bekanntgewordene Log4Shell-Schwachstelle in Apache Log4j.
H2 ist eine weit verbreitete Open-Source-Java-SQL-Datenbank, die eine schlanke In-Memory-Lösung bietet, bei der die Daten nicht auf der Festplatte gespeichert werden müssen. Dies macht sie zu einer beliebten Datenspeicherlösung für verschiedene Projekte, von Webplattformen wie Spring Boot bis zu IoT-Plattformen wie ThingWorks. Das Paket com.h2database:h2 gehört zu den 50 beliebtesten Maven-Paketen mit fast 7000 Artefakt-Abhängigkeiten.
Obwohl es sich um ein kritisches Problem mit einer ähnlichen Ursache handelt, dürfte CVE-2021-42392 nicht so weit verbreitet sein wie Log4Shell (CVE-2021-44228). Im Gegensatz zu Log4Shell hat diese Sicherheitsanfälligkeit einen „direkten” Wirkungsbereich. Das bedeutet, dass in der Regel der Server, der die erste Anfrage verarbeitet (die H2-Konsole), der Server ist, der von RCE (Remote Component Environment) betroffen ist. Dies ist im Vergleich zu Log4Shell weniger schwerwiegend, da die anfälligen Server leichter zu finden sein sollten.
Bei vielen Anbietern läuft zwar die H2-Datenbank, aber nicht die H2-Konsole. Obwohl es neben der Konsole noch andere Vektoren gibt, um dieses Problem auszunutzen, sind diese anderen Vektoren kontextabhängig und weniger wahrscheinlich für entfernte Angreifer zugänglich. Wenn man jedoch eine H2-Konsole betreibt, die im LAN zugänglich ist, ist dieses Problem äußerst kritisch (unauthentifizierte Code-Ausführung aus der Ferne) und es bedarf einer sofortigen Aktualisierung der H2-Datenbank auf die Version 2.0.206 (oder höher).
Die Sicherheitsforscher haben außerdem festgestellt, dass viele Entwickler-Tools auf die H2-Datenbank zurückgreifen und insbesondere die H2-Konsole offenlegen. Der jüngste Trend zu Supply-Chain-Angriffen auf Entwickler, z. B. durch bösartige Pakete in beliebten Repositories, unterstreicht die Bedeutung von sicheren Entwickler-Tools für alle Anwendungsfälle. Es ist zu hoffen, dass viele von H2 abhängigen Entwickler-Tools nach Anwendung dieses Fixes ebenfalls sicherer werden.
Eine der wichtigsten Erkenntnisse aus dem Vorfall mit der Log4Shell-Schwachstelle war, dass es aufgrund der weit verbreiteten Verwendung von JNDI (Java Naming and Directory Interface) zwangsläufig mehr Pakete gibt, die von der gleichen Ursache wie Log4Shell betroffen sind – der Akzeptanz beliebiger JNDI-Lookup-URLs. Daher haben die Forscher von JFrog ihr automatisiertes Framework zur Erkennung von Schwachstellen so angepasst, dass es die Funktion javax.naming.Context.lookup als gefährliche Funktion berücksichtigt.
Grundursache der Schwachstelle – JNDI-Remote Class Loading
Kurz gesagt ist die Grundursache ähnlich wie bei Log4Shell – mehrere Codepfade im H2-Datenbank-Framework leiten ungefilterte, vom Angreifer kontrollierte URLs an die Funktion javax.naming.Context.lookup weiter, was das Laden einer entfernten Codebasis (auch bekannt als Java Code Injection oder Remote Code Execution) ermöglicht.
Überprüfung auf Anfälligkeit für CVE-2021-42392
Netzwerkadministratoren können ihre lokalen Subnetze nach offenen Instanzen der H2-Konsole scannen, alle gefundenen Server sind höchstwahrscheinlich angreifbar. Wie bereits erwähnt, gibt es noch andere Angriffsmöglichkeiten, aber eine Ausnutzung aus der Ferne ist sehr viel unwahrscheinlicher. In jedem Fall sollte die H2-Datenbank aktualisiert werden.
Entdeckung von CVE-2021-42392
Das Problem kann über eine Datenflussanalyse (DFA) entdeckt werden, wenn die in Java integrierten HttpServlet.doGet/doPost-Methoden als Benutzereingabequelle (insbesondere das erste req-Argument) und die oben erwähnte javax.naming.Context.lookup-Methode (die JNDI-Lookup durchführt) als gefährliche Funktion/Senke definiert werden.
Was ist die vorgeschlagene Lösung für CVE-2021-42392?
Die Empfehlung für alle Benutzer der H2-Datenbank lautet, auf die Version 2.0.206 zu aktualisieren, auch wenn sie nicht direkt die H2-Konsole verwenden. Der Grund dafür ist, dass es andere Angriffsvektoren gibt, deren Ausnutzbarkeit möglicherweise schwer festzustellen ist. Version 2.0.206 behebt CVE-2021-42392, indem sie JNDI-URLs darauf beschränkt, nur das (lokale) Java-Protokoll zu verwenden, wodurch alle entfernten LDAP/RMI-Abfragen verweigert werden. Dies ist vergleichbar mit der in Log4j 2.17.0 vorgenommenen Korrektur.
Entschärfung von CVE-2021-42392
Die beste Lösung für diese Schwachstelle ist ein Upgrade der H2-Datenbank. Für Anbieter, die derzeit nicht in der Lage sind, H2 zu aktualisieren, gibt es folgende Abhilfemöglichkeit:
Ähnlich wie bei der Log4Shell-Schwachstelle enthalten neuere Versionen von Java die Abschwächung trustURLCodebase, die es nicht zulässt, dass Remote-Codebases arglos über JNDI geladen werden. Anbieter sollten ihre Java-Version (JRE/JDK) aktualisieren, um diese Abschwächung zu aktivieren. Der Research der Forscher von JFrog zeigt die Ursache des Problems auf und basierend darauf wurde die oben erwähnte korrigierte Version der H2-Datenbank, 2.0.206, erstellt. Noch wichtiger ist es jetzt, auf eine korrigierte Version von H2 zu aktualisieren, da einige Angreifer die frühere Entdeckung gesehen haben könnten und schon seit einiger Zeit ähnliche Angriffsvektoren verwenden.
Schlussfolgerung
Die dringende Empfehlung lautet, die H2-Datenbank auf die neueste Version zu aktualisieren, um eine mögliche Ausnutzung von CVE-2021-42392 zu vermeiden. Soweit bekannt, ist CVE-2021-42392 die erste JNDI-bezogene nicht authentifizierte RCE-Schwachstelle, die seit Log4Shell veröffentlicht wurde, aber es wird vermutlich nicht die letzte sein.
https://jfrog.com/de/
