Log4Shell-Webinar: Was Sie wissen müssen

Unabhängig davon, welche Rolle Sie in der Tech-Branche haben: Sie haben wahrscheinlich bereits von der allgegenwärtigen Log4Shell-Sicherheitslücke gehört oder waren schon mit ihr konfrontiert. Sie betrifft zahlreiche Java-Anwendungen. Um die neuesten Informationen zu dieser kritischen Zero-Day-Sicherheitslücke weiterzugeben, haben wir kürzlich ein Webinar veranstaltet, um alle auf den aktuellen Stand zu bringen.

In unserem Webinar Log4Shell: Was Sie wissen müssen sprachen Snyks Steve Kinman (Field CISO), Simon Maple (Field CTO) und Kirill Efimov (Security Research Team Lead) über die Log4Shell-Sicherheitslücke und Möglichkeiten, sie einzudämmen. Hier finden Sie eine kurze Zusammenfassung der wichtigsten Erkenntnisse aus der Diskussion.

Was ist Log4j?

Log4j ist eine beliebte Open-Source-Java-Bibliothek, die in Java-Anwendungen häufig für die Protokollierung verwendet wird. Das Logging-Framework nutzt den JNDI-Dienst des Java Development Kit (JDK), um zusätzliche Informationen aus der Anwendung abzurufen. Dadurch werden die Protokolldaten mit weiteren Metadaten angereichert und für Entwickler nützlicher. Viele beliebte Java-Anwendungsframeworks verwenden Log4j standardmäßig, darunter Apache Struts 2, Apache Solr und Apache Druid.

Protokollierung ist sehr wichtig. Java-Anwendungen protokollieren ständig Ereignisse, insbesondere Ausnahmen und Fehler, damit Entwickler nachvollziehen können, was passiert.

Die Log4Shell-Sicherheitslücke

Log4Shell ist die Bezeichnung für eine kritische und leicht ausnutzbare Sicherheitslücke in der Log4j2-Bibliothek. Die Sicherheitslücke (CVE-2021-44228) erhielt einen CVSS-Score von 10 – den höchstmöglichen Wert.

In Log4j wurde eine weitverbreitete, kritische und leicht ausnutzbare Zero-Day-Sicherheitslücke offengelegt. Dieser Angriffsvektor besteht seit fünf oder sechs Jahren. Da er sich sehr leicht ausnutzen lässt, kommt es zu einer großen Zahl von Angriffen, und die Lage entwickelt sich ständig weiter.

So funktioniert der Log4Shell-Exploit

JNDI (Java Naming and Directory Interface) ist ein Verzeichnisdienst, ähnlich wie LDAP. Mithilfe einer eindeutigen Kennung können Sie darüber Code oder Java-Objekte abrufen. Java-Anwendungen fragen häufig JNDI-Dienste nach Datenquellen oder anderen Informationen ab.

Das Log4j-Logging-Framework nutzt JNDI, um Variablen und weitere Informationen abzurufen und die protokollierten Daten anzureichern. Das Problem: Beim Protokollieren versucht Log4j möglicherweise, gefährliche Zeichenfolgen zur Laufzeit aufzulösen – darunter URLs zu nicht autorisierten JNDI-Diensten.

Das bedeutet, dass die Log4Shell-Sicherheitslücke es Angreifern ermöglichen könnte, eine Java-Anwendung dazu zu bringen, ihren eigenen JNDI-Dienst aufzurufen. Dazu nutzen sie den Logging-Dienst aus und lassen ihren Dienst mit einem schädlichen Objekt oder Code antworten. Dieser Angriff zur Remotecodeausführung (RCE) kann weitreichende Folgen haben.

Die größten Risiken von Log4Shell

Das unmittelbare Risiko bei Log4Shell ist ein Angriff zur Remotecodeausführung. Durch das Einschleusen schädlichen Codes kann ein Angreifer Malware oder Ransomware installieren, einen Server oder eine Anwendung übernehmen, Daten exfiltrieren, die Datenintegrität oder Anwendungsverfügbarkeit beeinträchtigen oder andere Sicherheitsdienste deaktivieren.

Neben dem unmittelbaren Risiko eines Angriffs gibt es weitere Gefahren für anfällige Java-Anwendungen. Die Log4Shell-Sicherheitslücke kann auch zu Verstößen gegen regulatorische Vorgaben, zum Versagen von Cloud-Sicherheitskontrollen und der Sicherheit von SaaS-Anwendungen Drittanbieter sowie zu Verstößen gegen Compliance-Richtlinien führen.

Das größte Risiko besteht darin, dass Ihr Aufsichtsrat oder CEO fragt: „Sind wir betroffen?“ Wenn Sie darauf keine gute Antwort haben, ist das ein Risiko.

Die Log4Shell-Sicherheitslücke erkennen

Für Java-Entwicklungsteams bedeutet die Eindämmung von Log4Shell, herauszufinden, an welchen Stellen im Abhängigkeitsgraphen Log4j verwendet wird. Das kann schwierig sein: Wir haben festgestellt, dass 60,8 % der Snyk-Kunden Log4j als transitive Abhängigkeit nutzen. Das bedeutet, dass das Logging-Framework in einer anderen von ihnen verwendeten Open-Source-Bibliothek enthalten ist.

Ein besonders beunruhigender Aspekt dieser Sicherheitslücke für Sicherheitsteams ist, dass sie möglicherweise gar nicht wissen, ob Log4j überhaupt verwendet wird. Wenn Sie nicht wissen, womit Ihre Software tatsächlich erstellt wurde, wissen Sie möglicherweise auch nicht, ob Sie betroffen sind.

Mit Snyk können Sie Ihre Anwendungen auf Sicherheitslücken wie Log4Shell scannen – auch wenn sich diese in transitiven Abhängigkeiten befinden. So schützen Sie Ihre Software-Supply-Chain davor, Sicherheitsrisiken wie Log4Shell einzuführen. Snyk hat außerdem den Befehl snyk log4shell erstellt, mit dem Sie die Sicherheitslücke in Ihren nicht verwalteten und „shaded“ JAR-Dateien finden.

Den Log4Shell-Exploit eindämmen

Sobald Sie die verwendete Log4j-Version ermittelt haben, sollten Sie sicherstellen, dass es mindestens Version 2.17.1 ist. Kurz nach der Entdeckung der Zero-Day-Sicherheitslücke lautete die ursprüngliche Empfehlung, auf Version 2.15.0 zu aktualisieren, um Log4Shell zu beheben. Doch auch diese Version weist weitere Probleme auf.

Hinweis der Redaktion: Zum Zeitpunkt der Webinaraufzeichnung wurde ein Upgrade auf Version 2.16 empfohlen. Die Empfehlung wurde inzwischen auf Version 2.17.1 aktualisiert. Jeden Tag erfahren wir mehr über diese Sicherheitslücke. Besuchen Sie daher regelmäßig unsere Seite mit Informationen zur Log4Shell-Sicherheitslücke, um auf dem neuesten Stand zu bleiben.

Wenn Sie die Bibliothek nicht sofort aktualisieren können, sollten Sie die Ausnutzbarkeit von Log4Shell eindämmen. Eine ausführliche Anleitung zur Behebung finden Sie in unserem Log4Shell-Leitfaden zur Behebung, den wir angesichts der sich entwickelnden Lage laufend aktualisieren.

Diese Sicherheitslücke wird uns noch jahrelang beschäftigen. Dass es sich um eine Zero-Day-Sicherheitslücke handelt, ist ein Grund zur Sorge für die gesamte Branche. Sie wird immer wieder auftauchen, weil sie erneut ins Spiel gebracht wird oder in einer Abhängigkeit steckt, von der Sie nichts wissen.