Was Log4Shell war
Im Dezember 2021 wurde Log4Shell (CVE-2021-44228) öffentlich bekannt. Die Schwachstelle betraf bestimmte Versionen von Apache Log4j 2 Core, einer weit verbreiteten Java-Logging-Bibliothek. Die CVE-Bewertung lag bei CVSS 10,0.
Der technische Kern lag in JNDI-Lookup-Funktionen von Log4j. Unter betroffenen Versionen und Konfigurationen konnten vom Angreifer kontrollierbare Lognachrichten dazu führen, dass Log4j externe Namensauflösungen anstieß und nicht vertrauenswürdige Inhalte verarbeitete. Dadurch konnte unter den passenden Voraussetzungen Code auf dem betroffenen System ausgeführt werden.
Das ist nicht gleichbedeutend mit „jede Java-Anwendung war verwundbar“. Entscheidend waren unter anderem eine betroffene log4j-core-Version und die einschlägige Lookup-Funktionalität. Log4j 1, Log4net, Log4cxx und andere Logging-Bibliotheken sind nicht pauschal von dieser konkreten CVE betroffen.
Warum der Vorfall so viele Teams erreichte
Logging-Bibliotheken liegen häufig tief in Abhängigkeiten. Ein Team kann Log4j verwenden, ohne dass die Anwendung es direkt deklariert: Frameworks, Agenten, Serverprodukte oder eingebettete Komponenten bringen es transitiv mit. Dazu kommen Anwendungen, Appliances und Cloud-Dienste, deren Komponenten nicht vollständig im üblichen Quellcode-Inventar auftauchen.
Das machte die Reaktion zu einer Inventar- und Lieferkettenaufgabe. Ein Update des eigenen Anwendungscodes reichte nicht, wenn eine verwundbare Bibliothek in einem Container-Image, einem Agenten oder einem Drittprodukt steckte. Umgekehrt bedeutete die bloße Erwähnung von Java oder „Logging“ nicht automatisch, dass ein System betroffen war.
Was Betreiber tun sollten
- Erfassen Sie alle Java-Anwendungen, Container, Agents und Appliances – einschließlich transitiver Abhängigkeiten und vom Anbieter gelieferter Komponenten.
- Prüfen Sie die genaue Log4j-Core-Version und die aktuelle Apache- sowie Herstellerempfehlung. Nutzen Sie die freigegebenen Sicherheitsversionen Ihres Distributors oder Produktherstellers.
- Bauen Sie betroffene Artefakte neu und rollen Sie sie aus. Verifizieren Sie, dass auch laufende Prozesse tatsächlich die korrigierte Version verwenden.
- Prüfen Sie bei exponierten Systemen die verfügbaren Sicherheitsprotokolle und Herstellerhinweise auf frühere Ausnutzungsversuche. Ein Update entfernt keine bereits eingerichtete Persistenz.
- Dokumentieren Sie eine Notfallroutine für transitive Bibliotheken: SBOM, Besitzer, Update-Verantwortung, Rollout und Prüfung nach der Änderung.
Die architektonische Lehre reicht über Log4j hinaus. Logging ist ein sicherheitskritischer Eingabepfad, wenn externe Daten interpretiert oder in aktive Funktionen überführt werden. Bibliotheken sollten in ihrer Standardkonfiguration keine überraschenden Netzwerkzugriffe aus Logdaten auslösen.