Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Der Patch wurde veröffentlicht. Das Ticket wurde geschlossen. Der Nachbericht wurde eingereicht. Und dennoch melden Scanner das Problem auch mehr als vier Jahre später immer noch. Hier geht es um die Kluft zwischen „gepatcht“ und nachweislich sicher – und darum, was Log4j tatsächlich über die zugrunde liegenden Systeme offenbart hat.
Nach einem schwerwiegenden Sicherheitsvorfall stellt sich eine ganz besondere Art der Erschöpfung ein. Der Wettlauf um die Bereitstellung von Patches, die Besprechungen mit der gesamten Belegschaft, die hektische Bestandsaufnahme der betroffenen Systeme und dann endlich der Moment, in dem jemand das Tracking-Ticket schließt und im Statusfeld „gelöst“ einträgt. Dieses Gefühl der Erleichterung ist echt. In vielen Fällen ist es jedoch auch etwas verfrüht.
Log4Shell – die im Dezember 2021 bekannt gewordene kritische Sicherheitslücke in der Apache-Log4j-Bibliothek, die die Ausführung von Remote-Code ermöglicht – ist nach wie vor das eindrucksvollste Beispiel der jüngeren Vergangenheit dafür, was passiert, wenn sich eine tief in das Java-Ökosystem eingebettete Komponente als allgegenwärtig und universell gefährlich erweist. Die Reaktion war enorm. Tausende von Organisationen installierten innerhalb weniger Tage Patches. Regierungsbehörden erließen Notfallanweisungen. Sicherheitsteams arbeiteten über das Wochenende hinweg.
Und doch ist das von Log4j aufgedeckte Java-Sicherheitsproblem noch nicht aus der Welt geschafft. Nicht die konkrete CVE, sondern die Umstände, die es erst möglich gemacht haben, und die verbleibende Unsicherheit, die auch nach der Installation von Patches weiterhin besteht. Diese Unsicherheit zu verstehen, ist die eigentliche Lehre, und sie gilt weit über eine einzelne Bibliothek hinaus.
Was „gepatcht“ eigentlich bedeutet
Wenn ein Unternehmen bekannt gibt, dass es Log4j gepatcht hat, geht aus dieser Aussage eine implizite Annahme hervor: dass jede Instanz der anfälligen Bibliothek identifiziert und aktualisiert wurde. In der Praxis lässt sich diese Annahme in komplexen Java-Umgebungen nur äußerst schwer überprüfen.
Java-Anwendungen werden als gepackte Artefakte ausgeliefert – JAR-Dateien, WAR-Dateien, „Fat JARs“, die mit Tools wie Maven Shade oder der integrierten Paketierungsfunktion von Spring Boot erstellt wurden. Diese Pakete bündeln ihre Abhängigkeiten bereits zum Zeitpunkt der Erstellung. Eine anfällige Version von Log4j taucht nicht einfach nur in Ihrem Abhängigkeitsmanifest auf; sie kann physisch in einer anderen JAR-Datei eingebettet sein, die sich wiederum in einer WAR-Datei befindet, die auf einem Anwendungsserver bereitgestellt wird, von dem Ihr Sicherheitsteam gar nicht wusste, dass dort Java läuft.
Um zu erfahren, wie Sie diese tief verwurzelten Abhängigkeiten systematisch identifizieren und beheben können, lesen Sie unseren umfassenden Leitfaden zur Behebung einer Log4j-Sicherheitslücke.
Dies ist kein Sonderfall. Im Zuge der Maßnahmen zur Bekämpfung von Log4Shell entdeckten Sicherheitsforscher anfällige Log4j-Instanzen, die vier- und fünfstufig tief in Unternehmenssoftware von Anbietern eingebettet waren, denen selbst nicht bewusst war, dass die Bibliothek vorhanden war. In den damaligen Leitlinien der CISA wurde betont, dass jede betroffene Ressource identifiziert werden müsse, und darauf hingewiesen, dass ein erstes Scannen allein nicht ausreiche, um eine vollständige Bestandsaufnahme zu gewährleisten. Das Problem war struktureller Natur.
Die Diskrepanz zwischen den Angaben im Abhängigkeitsmanifest und dem, was zur Laufzeit tatsächlich ausgeführt wird, ist keine nebensächliche Unstimmigkeit. Es handelt sich um ein grundlegendes Transparenzproblem im Java-Abhängigkeitsmanagement, das durch Log4Shell unübersehbar geworden ist.
Die Nachwirkungen eines schweren Vorfalls
Sicherheitsvorfälle von der Größenordnung wie bei Log4j lassen sich nicht vollständig beheben. Sie haben einen langen Nachhall – lange Zeiträume, in denen die Installation von Patches in den Systemen, an deren Überprüfung man gedacht hat, technisch zwar abgeschlossen ist, während anfällige Instanzen in den Systemen weiterbestehen, an die niemand mehr gedacht hat.
Die Langzeitauswirkungen von Log4j haben sich als ungewöhnlich hartnäckig erwiesen. Dies liegt zum Teil daran, dass Java eine ungewöhnlich „hartnäckige“ Laufzeitumgebung ist. Java-Anwendungen werden in Umgebungen eingesetzt, die nicht für häufige Updates ausgelegt sind: eingebettete Industriesysteme, veraltete Finanzplattformen, Software für medizinische Geräte sowie vom Anbieter bereitgestellte Unternehmensanwendungen, bei denen der Kunde keinen Einfluss auf den Build hat. Dabei handelt es sich nicht um obskure Kontexte. Sie machen einen erheblichen Teil der Java-Installationsbasis aus.
DEZEMBER 2021
CVE-2021-44228 wurde bekannt gegeben. Weltweit beginnen die Maßnahmen zur Bereitstellung von Notfall-Patches. Log4j 2.15.0 wurde veröffentlicht – später stellte sich heraus, dass es sich bei bestimmten Konfigurationen um eine unvollständige Korrektur handelte.
DEZEMBER 2021 – JANUAR 2022
Es folgen drei weitere CVEs, die alle im Dezember 2021 bekannt gegeben wurden: CVE-2021-45046, CVE-2021-45105 und CVE-22021-44832. Teams, die bereits auf Version 2.15.0 gepatcht haben, müssen erneut ein Patch installieren. Bei Bestandsaufnahmen werden unerwartete Instanzen in Anbietersoftware und eingebetteten Systemen entdeckt.
2022
Die CISA hat Log4Shell in ihren Katalog bekannter ausgenutzter Sicherheitslücken aufgenommen, und Angreifer haben diese Schwachstelle weiterhin neben neueren CVEs in ihre Standard-Toolkits integriert. Die Ausnutzung ungepatchter Altsysteme hielt an.
2023 – HEUTE
Auch Jahre nach der Bekanntgabe sind noch immer Scan- und Ausnutzungsaktivitäten im Zusammenhang mit Log4Shell zu beobachten; eine Langzeitstudie aus dem Jahr 2026 ergab, dass der entsprechende Datenverkehr bis Oktober 2025 anhielt. Eingebettete und von Anbietern bereitgestellte Java-Anwendungen stellen nach wie vor eine anhaltende Sicherheitslücke dar. In den offiziellen Nachverfolgungssystemen der meisten Organisationen gilt der Vorfall zwar als „behoben“ – in der Praxis ist dies jedoch nicht der Fall.
Diese Zeitleiste verdeutlicht etwas Wichtiges: Gravierende Sicherheitslücken machen keinen Halt vor dem Abschluss von Incident-Tickets. Sie bestehen in den Teilen der Infrastruktur fort, denen bei der ersten Reaktion am wenigsten Aufmerksamkeit geschenkt wurde: dem Altsystem, das die IT-Abteilung vergessen hatte, der Hersteller-Appliance, für die der Hersteller sechs Monate brauchte, um einen Patch herauszugeben, und dem containerisierten Dienst, der auf Basis eines alten Basis-Images neu erstellt wurde.
Wie Log4j die Diskussionen über interne Sicherheit verändert hat
Wenn Log4Shell über die Patches hinaus eine nachhaltige Auswirkung auf die Unternehmen hatte, dann war es diese: Es zwang dazu, sich einzugestehen, wie wenig die meisten Entwicklungsabteilungen tatsächlich über ihre eigene Software wussten.
Die Frage „Verwenden wir Log4j?“ erwies sich als viel schwieriger zu beantworten, als irgendjemand erwartet hatte, und diese Schwierigkeit war auf produktive Weise peinlich. Sicherheitsarchitekten beschreiben im Nachhinein oft dieselbe Erkenntnis. Sie dachten, sie hätten eine gute Bestandsaufnahme, weil sie ein Manifest hatten – aber ein Manifest ist eine Liste dessen, was man glaubt, installiert zu haben, und keine Liste dessen, was tatsächlich läuft.
Vor Log4Shell waren Software-Stücklisten (SBOMs) ein Nischenthema – etwas, worüber Compliance-Teams diskutierten, das für Entwicklungsteams jedoch keine Priorität hatte. Nach Log4Shell wurde das Thema SBOM zu einem festen Bestandteil der gängigen Sicherheitspraxis. Die im Mai 2021, also Monate vor der Bekanntgabe der Log4j-Sicherheitslücke, unterzeichnete Verordnung der US-Regierung zur Softwaresicherheit hatte SBOMs bereits als grundlegende Anforderung gefordert. Log4Shell hat gezeigt, warum diese Anforderung berechtigt war.
Im Gespräch ging es auch um die Frage der Zuständigkeit. In großen Organisationen lässt sich die Frage „Wer ist für die Abhängigkeiten dieser Anwendung verantwortlich?“ oft nicht eindeutig beantworten. Das Entwicklerteam, das die Anwendung erstellt hat, ist möglicherweise inzwischen nicht mehr im Unternehmen. Das Plattformteam betreibt die Infrastruktur. Das Sicherheitsteam kann die Schwachstelle melden, aber den Fix nicht einbinden. Log4j führte zu Situationen, in denen drei verschiedene Teams jeweils darauf warteten, dass die anderen handelten, während die Zeit davonlief.
Vertrauen und das Anbieterproblem
Log4Shell hat zudem etwas beschädigt, das sich schwerer quantifizieren lässt: das Vertrauen in von Anbietern bereitgestellte Software. Viele Unternehmen stellten fest, dass kommerzielle Anwendungen und Geräte, die sie erworben hatten und für die sie Supportverträge abschlossen, anfällige Log4j-Instanzen enthielten, die der Anbieter nicht offengelegt hatte und die er nicht innerhalb eines angemessenen Zeitraums beheben konnte. Die Unternehmen hatten keinen Einblick in den Inhalt dieser Produkte und verfügten über keinerlei Einflussmöglichkeiten, um die Reaktion des Anbieters zu beschleunigen.
Dies ist das Problem der Anbieterabhängigkeit in seiner krassesten Form. Wenn Sie eine Drittanbieteranwendung bereitstellen, übernehmen Sie deren gesamten Abhängigkeitsgraphen, einschließlich Komponenten, die Sie weder sehen noch aktualisieren noch ersetzen können. Für Sicherheitsteams bedeutet dies, dass sich Ihre Angriffsfläche über den von Ihren Entwicklern geschriebenen Code hinaus auf den von Ihren Anbietern geschriebenen Code, den von deren Anbietern geschriebenen Code und so weiter erstreckt.
DAS PROBLEM DER SICHTBARKEIT – EINFACH GESAGT
Die meisten Unternehmen wissen nicht genau, welche Komponenten in ihren Umgebungen laufen. Sie wissen zwar, was sie bereitgestellt haben, kennen aber nicht immer den genauen Inhalt der bereitgestellten Komponenten. Log4j hat diese Wissenslücke auf eine Weise zu einem schwerwiegenden Problem gemacht, das sich kaum noch rückgängig machen lässt.
Die allgemeine Lehre daraus: Log4j war kein Einzelfall
Es wäre bequem, Log4j als Ausnahmefall zu betrachten – als eine Katastrophe, wie sie nur einmal in zehn Jahren vorkommt und die durch eine ungewöhnlich gefährliche Funktion in einer ungewöhnlich weit verbreiteten Bibliothek verursacht wurde. Diese Sichtweise ist zwar vom Ausmaß her zutreffend, aber in ihrer Art irreführend. Die Umstände, die Log4Shell so schädlich gemacht haben, sind im Java-Ökosystem weit verbreitet und werden auch in Zukunft zu Vorfällen ähnlicher Art führen.
Das Java-Ökosystem verfügt über eine enorme Legacy-Fläche. Bibliotheken, die vor fünfzehn Jahren geschrieben wurden, als die Sicherheitspraktiken noch anders waren und die Bedrohungsmodelle enger gefasst waren, laufen auch heute noch in der Produktion. Einige sind direkte Abhängigkeiten von Anwendungen, die seit Jahren nicht mehr angefasst wurden. Andere sind transitive Abhängigkeiten von Frameworks, die sie längst integriert haben und keinen Grund gesehen haben, sie zu entfernen.
Im Gegensatz zu moderneren Paket-Ökosystemen lassen sich mit den Build-Tools von Java alle Komponenten problemlos in einem einzigen bereitstellbaren Artefakt bündeln. Das bedeutet, dass alter, anfälliger Code unsichtbar zusammen mit neuem Code weiterverbreitet wird, bis er durch einen Scanner oder einen Vorfall aufgedeckt wird. Die Stärke des Ökosystems (Abwärtskompatibilität, Stabilität, große Auswahl an Bibliotheken) ist gleichzeitig auch sein Sicherheitsrisiko.
An Kandidaten für das nächste Ereignis in der Größenordnung von Log4j mangelt es nicht. Der „StringSubstitutor“-Klasse (CVE-2022-42889, im Oktober 2022 bekannt gegeben) löste vergleichbare Besorgnis aus, da sie durch unsichere Variableninterpolation die Ausführung von Remote-Code ermöglichen könnte, auch wenn sich ihre tatsächliche Ausnutzbarkeit in der Praxis als weitaus begrenzter erwies als die von Log4Shell. Das breitere Apache-Commons-Ökosystem, verschiedene XML-Parsing-Bibliotheken sowie JNDI- und RMI-bezogene Hilfsprogramme – das sind genau die Komponenten, die schon seit langem in Java-Anwendungen zum Einsatz kommen, weniger Sicherheitsprüfungen unterzogen werden als neuere Bibliotheken und durchaus die nächste kritische CVE enthalten könnten.
Wie sich Teams anpassen
Als Reaktion auf die durch Log4j aufgedeckte Unsicherheit hat sich eine Reihe von Vorgehensweisen herausgebildet, die in Unternehmen, die Abhängigkeitsrisiken ernst nehmen, zunehmend zum Standard werden. Keine davon löst das Problem vollständig. Zusammen tragen sie jedoch zu einer deutlichen Verringerung der Unsicherheit bei.
01 Software-Stücklisten (SBOMs)
Teams erstellen im Rahmen des Build-Prozesses maschinenlesbare SBOMs. Durch den Einsatz von Tools wie Syft, CycloneDX oder dem Maven-SBOM-Plugin entsteht eine überprüfbare Aufzeichnung aller Komponenten eines Deployment-Artefakts, einschließlich transitiver Abhängigkeiten. SBOMs verhindern zwar keine Sicherheitslücken, ermöglichen aber eine Bestandsaufnahme. Wenn das nächste Log4j auftritt, können Unternehmen mit aktuellen SBOMs die Frage „Sind wir betroffen?“ innerhalb von Stunden statt Tagen beantworten.
02 Kontinuierliche Überprüfung der Abhängigkeiten in CI/CD
Zudem verlagern sie das Scannen auf Schwachstellen von periodischen Audits hin zu kontinuierlichen Integrationsprüfungen. Durch den Einsatz von Tools wie Grype, OWASP Dependency-Check oder Snyk wird der Ansatz von reaktiv auf präventiv umgestellt. Neue Schwachstellen in bestehenden Abhängigkeiten werden sofort aufgedeckt und nicht erst bei der nächsten vierteljährlichen Überprüfung. Die Herausforderung besteht darin, der „Alarm-Müdigkeit“ entgegenzuwirken; nicht jede gemeldete CVE ist im jeweiligen Kontext ausnutzbar, und undifferenzierte Scanner-Ergebnisse werden schnell ignoriert.
03 Laufzeitüberwachung und Verhaltenserkennung
Beim statischen Scan werden bekannte Schwachstellen in bekannten Komponenten erkannt. Versuche, Schwachstellen auszunutzen, die zum Zeitpunkt des Scans noch nicht bekannt waren, werden dabei nicht erfasst. Bei älteren Installationen, auf denen noch JDK 17 bis 23 läuft, bietet der Java Security Manager zwar begrenzte Kontrollmöglichkeiten, wurde jedoch bereits in Java 17 als veraltet markiert und in JDK 24 dauerhaft deaktiviert. Daher stützt sich der moderne Laufzeitschutz nun auf RASP-Agenten und die Überwachung auf Netzwerkebene hinsichtlich verdächtiger JNDI-Lookup-Muster – eine Erkennungsebene, die zur Laufzeit statt zur Kompilierungszeit aktiv ist.Dies ist besonders wertvoll für Altsysteme, bei denen sich statische Scans nur schwer nachrüsten lassen.
04 Eindeutige Zuständigkeiten und SLAs für die Fehlerbehebung
Die Zuständigkeitslücken, die in vielen Unternehmen die Reaktion auf Log4j verlangsamten, waren keine technischen Probleme, sondern Prozessprobleme. Durch die Festlegung klarer Zuständigkeiten für jede eingesetzte Anwendung – einschließlich Legacy-Dienste – und die Definition expliziter SLAs für die Behebung kritischer Sicherheitslücken (mit Eskalationswegen für den Fall, dass die Zuständigkeit unklar ist) wird die Frage „Wer behebt das?“ von einem wiederkehrenden Hindernis zu einem geregelten Prozess.
05 Erweiterter Sicherheitsschutz für Bibliotheken über den Standard-Support hinaus
Für Java-Anwendungen, die mit älteren Bibliotheksversionen laufen, die nicht mehr aktiv gepflegt werden, lautet die übliche Antwort „Upgrade“. Wenn Upgrades aufgrund von Einschränkungen seitens der Anbieter, regulatorischer Einfrierungen oder instabiler Altsysteme nicht realistisch sind, benötigen Teams eine Möglichkeit, Sicherheitspatches zu erhalten, ohne auf eine neue Hauptversion umzusteigen. Dienste wie TuxCares „Endless Lifecycle Support (ELS) for Libraries“ bieten zurückportierte Sicherheitskorrekturen für die abgedeckten Bibliotheksversionen und helfen Teams dabei, eine als stabil bekannte Konfiguration vor aktuellen Sicherheitslücken zu schützen, während sie eine längerfristige Migration planen. Dies ist eine Brücke, kein Endziel, aber eine sinnvolle Lösung, wenn die Alternative darin besteht, die Software ungepatcht zu betreiben, weil ein Upgrade erst in Monaten möglich ist.
Akzeptanz von verbleibender Unsicherheit
Es gibt eine Version dieses Gesprächs, die mit einer Checkliste endet: SBOMs implementieren, Scans einrichten, Zuständigkeiten festlegen, Support-Fenster verwalten. Befolgen Sie diese Schritte, und das Problem ist gelöst. Diese Version ist übersichtlicher als die Realität.
Die ehrliche Einschätzung lautet: Komplexe Softwaresysteme bergen eine Restunsicherheit, die sich nicht vollständig beseitigen, sondern nur bewältigen lässt. Sie werden keinen vollständigen Überblick über jede einzelne Abhängigkeit in Ihrer Umgebung erlangen. Sie werden nicht jede anfällige Bibliothek patchen können, bevor die nächste kritische CVE bekannt gegeben wird. Von Anbietern bereitgestellte Software wird weiterhin Komponenten enthalten, die Sie weder sehen noch kontrollieren können.
Sie können bewusst entscheiden, wo Sie in die Verringerung dieser Unsicherheit investieren, anstatt zuzulassen, dass sie sich unbemerkt anhäuft, bis ein Vorfall die Diskussion erzwingt. Log4j war unter anderem ein Auslöser, ein Moment, in dem die Kosten des unsichtbaren Abhängigkeitsrisikos unbestreitbar wurden.
Die Teams, die aus der Reaktion auf Log4Shell mit einer verbesserten Sicherheitslage hervorgingen, waren nicht diejenigen, die am schnellsten Patches installierten. Es waren diejenigen, die den Vorfall als Information über ihre eigenen Systeme betrachteten: Was wussten sie noch nicht, wo gab es Lücken in ihren Prozessen, welche Teile ihrer Infrastruktur hatten keinen klaren Verantwortlichen? Sie nutzten die Störung, um etwas aufzubauen, das beständiger ist als eine gepatchte JAR-Datei.
Diese Frage sollte bei jeder Sicherheitsüberprüfung nach dem Log4j-Vorfall im Mittelpunkt stehen. Es geht nie nur darum, ob Sie den Patch installiert haben, sondern auch darum, wie sicher Sie sich bei dieser Antwort sind – und was Sie gegen die Sicherheitslücke unternehmen.
Entdecken Sie den „Endless Lifecycle Support“ (ELS) von TuxCare für Bibliotheken →
