Am 09./10.12.2021 wurde CVE-2021-44228 öffentlich, bekannt als Log4Shell. CVSS-3.1-Basiswert: 10.0 (kritisch). Betroffen war Apache Log4j 2.0-beta9 bis 2.14.1, genauer das Artefakt log4j-core.

Ursache: Log4j ersetzte Lookup-Ausdrücke nicht nur in der Konfiguration, sondern auch in Log-Nachrichten und deren Parametern. Über JNDI-Funktionen konnte ein Lookup Daten von einem entfernten Verzeichnisdienst abrufen. Landete ein angreiferkontrollierter Text im Log, etwa ein HTTP-Header, konnten Angreifer unter bestimmten Bedingungen Code nachladen und ausführen (RCE). Weil fast jede Anwendung Request-Daten loggt und log4j-core oft transitiv in Produkten steckte, war die Angriffsfläche riesig.

CVE	Kern	behoben in
CVE-2021-44228	Log4Shell, 2.0-beta9 bis 2.14.1	2.15.0 (Fix unvollständig)
CVE-2021-45046	Fix in 2.15.0 unvollständig	2.16.0
CVE-2021-45105	Denial of Service, betrifft noch 2.16.0	2.17.0
CVE-2021-44832	betrifft noch 2.17.0	2.17.1

Empfohlene Mindestversion ist 2.17.1 (Java 8+), für Java 7 2.12.4, für Java 6 2.3.2. Heute nutzt du die aktuelle 2.x-Version. Log4j 1.x ist von dieser CVE nicht betroffen, aber seit 2015 End of Life und gehört ohnehin ersetzt. Die damaligen Notmaßnahmen (JndiLookup-Klasse aus dem Klassenpfad entfernen, log4j2.formatMsgNoLookups=true) waren Übergangslösungen; die Systemeigenschaft half nicht in allen Fällen. Dauerhaft hilft nur das Update.

Lernfragen für deine Umgebung:

Welche Java- und Log4j-Versionen laufen in der Umgebung?
Welche Anwendungen nutzen Log4j direkt oder indirekt (transitiv, Fat-JAR, Container-Image, Fremdprodukt)?
Welche Systeme sind internetexponiert?
Wer ist für das Patchen verantwortlich?
Wie schnell kann ein Notfall-Update ausgerollt werden?
Welche Logs zeigen verdächtige JNDI- oder Lookup-Aktivitäten?
Wann muss isoliert statt nur gepatcht werden?
Welche Daten könnten betroffen sein?
Wann besteht eine mögliche Meldepflicht?

Erkennung: Versionen inventarisieren; Request-Header und Logs nach Lookup-Ausdrücken der Form ${jndi:…} und verschachtelten Varianten durchsuchen; ausgehende Verbindungen von Servern prüfen.
Test im Lab: Versionsprüfung und Scanner gegen eigene Lab-Artefakte, keine Ausnutzung.
Fix und Verifikation: Update, Neubau, Rollout; Version im laufenden Artefakt und per Rescan bestätigen.
Betrieb: SBOM pflegen, ausgehenden Verkehr begrenzen, Alarme auf Lookup-Muster.

Versionen nie als Text vergleichen: "2.9.1".compareTo("2.14.1") ist positiv, obwohl 2.9.1 älter ist. Und 2.0-beta9 sowie 2.0-rc2 liegen vor 2.0, aber im betroffenen Bereich.

Java Lernpfad von den Grundlagen zur sicheren professionellen Entwicklung.

Anmelden