Schwerwiegende Log4j-2.16-Sicherheitslücke (CVE-2021-45105) entdeckt

Über Nacht wurde von Apache bekannt gegeben, dass Log4j Version 2.16 ebenfalls für einen Denial-of-Service-Angriff anfällig ist, der zum vollständigen Absturz der Anwendung führen kann. Der Schweregrad wird als hoch (7,5) eingestuft. Snyk sind derzeit keine ausgereiften PoCs oder Exploits bekannt, die im Umlauf sind. Die CVE-2021-45105 wurde vergeben, und Apache hat eine neue, korrigierte Version (2.17.1) veröffentlicht, auf die wir ein Upgrade empfehlen.

Das Research-Team von Snyk verfolgt die dynamische Situation rund um Log4j aufmerksam und wird weitere Details zu Sicherheitslücken bereitstellen, sobald sie uns vorliegen.

Sollte ich auf die neue Version aktualisieren?

Es ist immer wichtig, Sicherheitslücken in Ihren Anwendungen zu beseitigen. Da es jedoch mehrere davon in der Log4j-Bibliothek gab, sollten wir diese hier in den richtigen Zusammenhang stellen. Dabei handelt es sich um eine Denial-of-Service-Sicherheitslücke und nicht um die Ausführung beliebigen Codes wie bei den beiden vorherigen. Das potenzielle Risiko ist also geringer. Entscheidend ist hier die Ausnutzbarkeit. Die beiden vorherigen Sicherheitslücken ließen sich nachweislich sehr gut ausnutzen, wie ausgereifte und funktionsfähige Exploit-Beispiele belegten. Zwar besteht die Möglichkeit, dass diese neue Denial-of-Service-Sicherheitslücke ausgenutzt wird, doch lässt sich anhand der derzeit verfügbaren Daten zum Zeitpunkt der Veröffentlichung nicht einschätzen, wie einfach oder häufig das geschehen könnte.

Zusammengefasst: Wenn Sie diese Sicherheitslücke beheben können und dafür Zeit haben, sollten Sie auf Version 2.17.1 aktualisieren. Wichtiger ist jedoch, zunächst sicherzustellen, dass alle Ihre Log4j-Versionen mindestens 2.16.0 entsprechen, um das Risiko der Ausführung beliebigen Codes zu mindern. Aktualisieren Sie anschließend alle Versionen auf 2.17.1. Wenn Sie noch Dienste haben, die nicht aktualisiert wurden, ist es sinnvoll, direkt auf die neueste Version 2.17.1 zu wechseln, um alle kürzlich bekannt gewordenen Log4j-Probleme zu beheben.

Warum gibt es plötzlich so viele Log4j-Sicherheitslücken?

Wenn Sie sich fragen, warum es in dieser Bibliothek so viele rasche Offenlegungen und entsprechende Releases gibt: Es ist wichtig, den gesamten Kontext des Geschehens zu verstehen und nachzuvollziehen, warum neue Upgrades veröffentlicht wurden und möglicherweise weitere folgen.

1. Größere Aufmerksamkeit in der Community – Die anfängliche Offenlegung der kritischen Remote-Code-Ausführung in Log4j hat die gesamte Community auf dieses Projekt aufmerksam gemacht. Dadurch kommen nun dank der Arbeit der Java-Open-Source-Community viele Fehler ans Licht, die zuvor möglicherweise übersehen wurden. Diese Aufmerksamkeit schwappt auch auf ähnliche Projekte über – manchmal mit gemischten Ergebnissen, da bei dem Bemühen, potenzielle Sicherheitslücken offenzulegen, die Eile dem Konsens in der Community zuvorkommt.

2. Überhastete erste Sicherheitskorrektur – Auch wenn die genauen Ereignisse, die zur Offenlegung von CVE-2021-44228 geführt haben, noch untersucht werden, scheint das üblicherweise eingehaltene Verfahren zur verantwortungsvollen Offenlegung nicht strikt befolgt worden zu sein: Details zu dieser Sicherheitslücke gelangten an die Öffentlichkeit, bevor eine vollständige Korrektur bereitstand. Das Apache-Team musste so schnell wie möglich eine Korrektur veröffentlichen. Dabei wurden weitere Angriffsvektoren und Probleme identifiziert, was zu den nachfolgenden Releases führte.

3. Abwärtskompatibilität – Log4j ist eine zentrale Komponente des Java-Ökosystems. Jede neue Version muss abwärtskompatibel zu früheren Versionen sein, um unnötige Probleme zu vermeiden, die Nutzerinnen und Nutzer möglicherweise daran hindern, auf die neue, sichere Version zu aktualisieren. Dieser notwendige und vorsichtige Ansatz bedeutet leider, dass die Kernfunktionalität nicht grundlegend verändert werden kann. Daher könnten weitere Angriffsvektoren oder Umgehungsmöglichkeiten existieren, die zum Zeitpunkt der Veröffentlichung der Korrektur noch nicht bekannt waren und im Zuge der fortlaufenden Überprüfung der Bedrohungslage durch die Community aufgedeckt werden.

Was kann ich tun, um künftig besser darauf vorbereitet zu sein?

Angesichts des oben beschriebenen Kontexts ist es wahrscheinlich, dass in naher Zukunft weitere Sicherheitslücken und entsprechende Versions-Releases folgen. Nutzerinnen und Nutzer von Log4j und anderen Open-Source-Paketen sollten auf diesen Fall vorbereitet sein. Mit den folgenden Best Practices können Sie Ihr AppSec-Programm verbessern und Zero-Day-Ereignisse einfacher bewältigen:

• Scannen Sie Ihren Code täglich, um aktuelle Sicherheitslücken in verwaltetem und sogar nicht verwaltetem Code zu finden.

• Erstellen Sie eine SBOM, um Ihre Software-Supply-Chain im Blick zu behalten.

• Richten Sie automatisierte CI/CD-DevOps-Pipelines mit integrierter Anwendungssicherheit ein.

• Sorgen Sie nach Möglichkeit für einen guten Umgang mit Open Source, indem Sie auf neuere Paket-Releases aktualisieren. So lassen sich dringende Sicherheitskorrekturen leichter übernehmen und die Kompatibilität Ihres Projekts wird weniger beeinträchtigt.

Folgen Sie uns auf LinkedIn, Twitter oder Facebook, um über die neuesten Nachrichten zu Log4Shell und anderen kritischen Sicherheitslücken auf dem Laufenden zu bleiben.