Die anhaltende Bedrohung: Warum kritische Schwachstellen wie Log4Shell und Spring4Shell weiterhin relevant sind

Als Entwickler jonglieren wir ständig mit Funktionen, Fehlerbehebungen und Deadlines. Dabei wird ein schwelendes Problem erstaunlich oft übersehen: In vielen Projekten kommen weiterhin verwundbare Versionen von Log4j und dem Spring Framework zum Einsatz. Obwohl die Schwachstellen Log4Shell und Spring4Shell großes Aufsehen erregt haben, laufen immer noch erschreckend viele Anwendungen mit diesen tickenden Zeitbomben. Das ist kein kleines Versehen, sondern ein erhebliches Risiko. Wir sind Entwickler aus Leidenschaft, doch zum Bauen gehört auch, für die Sicherheit unserer Konstruktionen zu sorgen. 

Das Dilemma der Entwickler

Als Entwickler müssen wir ständig abwägen, ob wir neue Funktionen bereitstellen oder bestehende Projekte und Features pflegen. Dieser Balanceakt erfordert viel Zeit und unsere volle Konzentration. Alle Abhängigkeiten jedes Projekts im Blick zu behalten und sie aktuell zu halten, kann sich wie ein Kampf gegen Windmühlen anfühlen – besonders, wenn der Druck groß ist, neue Funktionen zu liefern. Bei all dem Jonglieren können kritische Schwachstellen wie Log4Shell und Spring4Shell manchmal durchs Raster fallen – nicht aus Nachlässigkeit, sondern angesichts der schieren Menge an Aufgaben, die wir täglich bewältigen. Dabei muss uns bewusst sein, dass die Sicherheit spannender Anwendungen heute ein wesentlicher Bestandteil der Softwareentwicklung ist.

Der aktuelle Stand von Log4Shell

Erinnern Sie sich an Log4Shell? Diese schwerwiegende Schwachstelle in Apache Log4j wurde 2021 entdeckt. Sie ermöglichte es Angreifern, Code auf Ihrem Server auszuführen, indem sie eine speziell präparierte Zeichenfolge protokollierten. Ein Angreifer konnte eine JNDI-Abfrage über das LDAP-Protokoll nutzen, um eine vorkompilierte Klassendatei einzuschleusen und schädlichen Code auszuführen. Auch in neueren Java-Versionen konnte diese Schwachstelle durch Deserialisierungsangriffe Schaden anrichten. Die Angriffskomplexität dieser kritischen Schwachstelle gilt als sehr gering, wodurch die Bedrohung noch größer ist als üblich. Eine ausführliche Analyse des Problems finden Sie in unserem Blogbeitrag.

Mehr als 20 % der Unternehmen sind weiterhin durch Log4Shell gefährdet.

Viele Unternehmen nutzen heute noch in einem ihrer Projekte eine veraltete, verwundbare Version der Log4j-Bibliothek. Von allen Unternehmen, die ihren Produktivcode auf Schwachstellen überprüfen, haben 21 % weiterhin Projekte, die für Log4Shell anfällig sind. Das bedeutet, dass über 60.000 Projekte immer noch dem Risiko eines Angriffs durch eine Schwachstelle ausgesetzt sind, die vor mehr als zwei Jahren veröffentlicht und behoben wurde. Das ist enorm! Da diese Unternehmen bereits Sicherheitstools einsetzen und aktiv daran arbeiten, entdeckte Sicherheitsprobleme zu beheben, dürfte die tatsächliche Zahl verwundbarer Log4j-Versionen im Umlauf noch viel höher sein. Allein dieser Gedanke ist nicht nur beängstigend, sondern äußerst beunruhigend.

Spring4Shell in freier Wildbahn

Ein weiteres berüchtigtes Beispiel ist Spring4Shell, das im März 2022 bekannt wurde. Die Schwachstelle in spring-beans konnte ebenfalls die Ausführung von schädlichem Code aus der Ferne ermöglichen. Obwohl die Angriffskomplexität gering war und Exploits für bestimmte Fälle existierten, waren die Auswirkungen weniger schwerwiegend als bei Log4Shell. Weitere Informationen finden Sie im entsprechenden Blogbeitrag.

Indem das Snyk-Team diese Schwachstelle im April 2022 mit einem neuen Exploit auf Glassfish ausweitete, zeigte es, wie bedeutend sie ist und dass sie in vielen weiteren Fällen außerhalb des ursprünglichen Exploits für Tomcat missbraucht werden kann.

Wie bei Log4Shell haben wir festgestellt, dass Spring4Shell auch heute noch in freier Wildbahn auftritt. Etwa 35 % der Unternehmen haben Spring4Shell weiterhin in einem ihrer Projekte. Auch wenn das Risiko eines Spring4Shell-Angriffs nicht so groß war wie bei Log4Shell, zeigte das Snyk-Team eine Reihe möglicher Angriffe auf, indem es Glassfish untersuchte und einen Proof of Concept (POC) für einen Exploit entwickelte. Das beweist, dass auch scheinbar weniger große Gefahren zu erheblichen Sicherheitslücken führen können. Dass bisher kein Exploit veröffentlicht wurde, bedeutet nicht, dass eine Anwendung nicht über eine Schwachstelle angegriffen werden kann!

Darüber hinaus zeigt sich, dass viele Spring-Anwendungen von älteren, veralteten Framework-Versionen abhängen und die Aktualisierung und Wartung bestehender Anwendungen als unwichtig gelten. Tief im Inneren wissen wir jedoch, dass dies eine tickende Zeitbombe ist, die jederzeit explodieren kann.

Ein Weckruf an alle, die Anwendungen warten

Kommen wir gleich zur Sache. Wir alle kennen das Gefühl des Stolzes, wenn unser Code endlich reibungslos läuft. Als Letztes möchten wir dann wieder Hand anlegen – schon gar nicht wegen etwas vermeintlich Banalem wie der Aktualisierung von Bibliotheken. Doch Log4Shell und Spring4Shell beheben sich nicht von selbst. Und ehrlich gesagt handelt es sich dabei nicht um kleine Fehler, die wir ignorieren können. Es sind klaffende Löcher in den Schutzmauern unserer Anwendung. Wenn es in Ihrer Softwarelandschaft noch Schwachstellen wie Log4Shell oder Spring4Shell gibt, sind Sie unnötigerweise schwerwiegenden Angriffen ausgesetzt!

Snyk hilft Ihnen dabei, Sicherheitsschwachstellen in Anwendungen zu erkennen und zu beheben. Die Lösung lässt sich auf verschiedene Weise in Entwicklungs-Workflows integrieren, etwa über Git-Repositories, die Befehlszeilenschnittstelle (CLI) oder vorhandene Continuous-Integration-Pipelines (CI). So können Entwickler Sicherheitsrisiken früh im Entwicklungszyklus erkennen, bevor daraus größere Probleme entstehen. Die Registrierung ist kostenlos und ermöglicht den sofortigen Zugriff auf die Funktionen. Der eigentliche Mehrwert liegt jedoch darin, wie die entdeckten Schwachstellen nach ihrer Identifizierung verwaltet und behoben werden.

Wir müssen hier Verantwortung übernehmen. Es geht nicht nur darum, schnell einen Patch zu finden oder auf eine einfache Aktualisierung zu hoffen. Manchmal müssen wir die schwierige Entscheidung treffen, eine verwundbare Bibliothek zu entfernen oder zu ersetzen. Ja, das kann uns etwas ausbremsen und gehört nicht zu den spannendsten Aufgaben. Aber es ist entscheidend. Es geht darum, sicherzustellen, dass unser Code nicht nur heute, sondern langfristig robust ist.

Warten wir also nicht darauf, dass jemand anderes diese Probleme behebt. Mit den richtigen Tools können wir Schwachstellen frühzeitig erkennen – aber handeln müssen wir selbst. Es liegt an uns, unsere Abwehr zu stärken, die Schwachstellen zu beheben und unsere Anwendungen zuverlässig zu schützen. Legen wir los – nicht nur als Programmierer, sondern als Menschen, die für ihre Arbeit einstehen und dafür sorgen, dass sie so sicher wie möglich ist.