ISEC7 Digital Workplace Blog

Die Log4j-Schwachstelle verstehen (Log4Shell)

Geschrieben von Remi Keusseyan | 27.01.2022, 07:30:00

Hinweis der Redaktion, Oktober 2026: Dieser Beitrag erschien im Januar 2022 auf Englisch. Apache hat CVE-2021-44228 in Log4j 2.15.0 behoben und mehrere Folgeschwachstellen bis Version 2.17.1 im Dezember 2021 geschlossen; den aktuellen Stand zeigt die Sicherheitsseite von Apache Logging Services. CVE-2021-44228 steht seit dem 10. Dezember 2021 im Known Exploited Vulnerabilities Catalog der CISA, mit bekanntem Einsatz in Ransomware-Kampagnen. Ältere Anwendungen und Appliances, die noch eine betroffene Version mitbringen, bleiben damit ein Ziel. Log4j 1.x ist seit 2015 am Ende seines Lebenszyklus und erhält keine Korrekturen. Die GitHub-Liste betroffener Hersteller der CISA ist inzwischen archiviert und wird nicht mehr gepflegt.

Am 9. Dezember 2021 wurde eine Schwachstelle in Apache Log4j veröffentlicht, die später die Kennung CVE-2021-44228 erhielt. Angreifer können damit auf betroffenen Systemen aus der Ferne Code ausführen, also Remote Code Execution betreiben.

Wie wird die Schwachstelle ausgenutzt?

Exploit-Code mit dem Spitznamen Log4Shell war schnell öffentlich verfügbar, und die CISA und ihre Partner meldeten eine aktive, breite Ausnutzung; die Einzelheiten bündelt ihre Log4j-Handreichung. Sicherheitsfachleute zufolge lässt sich die Lücke nutzen, um Malware und Ransomware zu verbreiten, sensible Daten wie Kreditkarten-, Sozialversicherungs- und Gesundheitsdaten zu stehlen oder andere Angriffe auszuführen.

Was ist Log4j überhaupt?

Apache Log4j ist eine kostenlose, quelloffene Java-Bibliothek für das Logging, veröffentlicht unter der Apache License. Anwendungen protokollieren damit Ereignisse und geben Diagnosemeldungen an Administratoren und Nutzer weiter, etwa einen Logeintrag, dass ein Webserver nach einem Klick auf einen defekten Link den Fehler 404 zurückgegeben hat. Damit ist Log4j ein Grundbaustein in einer riesigen Zahl von Java-Anwendungen.

Welche Produkte sind betroffen?

Gefährdet sind Systeme mit Apache Log4j 2 in den Versionen 2.0-beta9 bis einschließlich 2.14.1, wenn sie Daten protokollieren, die ein Angreifer direkt oder indirekt beeinflussen kann. Aus dem Internet erreichbare Systeme sind die naheliegenden Ziele. Betroffen sein können aber auch interne Systeme, die weitergereichte Daten protokollieren. Logging ist eine Grundfunktion, und Log4j steckt in Unternehmens- und Open-Source-Software aller Art, in Webservern, E-Mail-Diensten und Cloud-Diensten; berichtet wurde unter anderem über Apple iCloud und Amazon Web Services (AWS). Weil auf AWS eine enorme Zahl von Diensten anderer Anbieter läuft, war die mögliche Angriffsfläche riesig.

Unsere Management- und Monitoring-Lösung ISEC7 SPHERE nutzte damals Log4j, war von der Schwachstelle aber nicht betroffen. Vorsorglich haben wir Log4j vollständig entfernt und durch Logback ersetzt.

Eine Liste betroffener Hersteller hat die CISA in einem GitHub-Repository gepflegt, das inzwischen archiviert ist.

Was ist jetzt zu tun?

  1. Falls noch nicht geschehen: Erfassen Sie die selbst entwickelte und zugekaufte Software in Ihrem Rechenzentrum sowie die genutzten Cloud- und SaaS-Dienste, und ermitteln Sie, welche davon betroffen sein könnten. In den meisten Fällen hat der Hersteller bereits informiert.
  2. Spielen Sie alle verfügbaren Patches der Hersteller ein. Gibt es noch keinen Patch, nutzen Sie bis dahin den vom Hersteller genannten Workaround. Gibt es auch den nicht, trennen Sie das betroffene System vom Internet, bis es gepatcht ist.
  3. Fragen Sie bei Cloud- und SaaS-Anbietern nach oder prüfen Sie deren Website, ob die Dienste sicher laufen.
  4. Stimmen Sie mit Ihren Herstellern Workarounds und aktualisierte Versionen ab, die die Schwachstelle beheben.

Selbst die unscheinbarste Bibliothek kann zum Einfallstor werden. Wie behalten Sie eine Umgebung mit Hunderten Servern und Tausenden Nutzern und Geräten im Griff, schützen sie vor vermeidbaren Angriffen und reagieren schnell, wenn eine neue CVE erscheint? Um das Patchen ging es in Sicherheitsvorfall: Patchen oder scheitern, um die Zeit nach einem Vorfall in Sicherheitsvorfall: Es kann jeden treffen. Einen vergleichbaren Fall aus demselben Jahr beschreibt unser Beitrag zur CISA-Notfallanweisung wegen VMware-Schwachstellen, und Lessons Learned from a Major Hack (Englisch) zeigt, wie Angriffe in der Praxis ablaufen.

Sie möchten wissen, welche Versionen in Ihrer Umgebung laufen und für welche Schwachstellen bekannt sind? ISEC7 SPHERE gleicht sie mit der National Vulnerability Database ab und meldet sich, sobald eine CVE bekannt wird. Sprechen Sie uns an, wenn Sie Ihre Infrastruktur weiter absichern wollen.