Log4Shell-Schwachstelle: Was wir bisher wissen

Kurz vor den Weihnachtsfeiertagen, erschüttert eine kritische Sicherheitslücke in einer Apache-Codebibliothek namens Log4j 2 Unternehmen und insbesondere Administratoren, Entwickler sowie Sicherheitsexperten auf der ganzen Welt. Denn Log4j ist eine weitverbreitete, auf Java basierende Open-Source-Protokollierungsbibliothek, die Bestandteil sehr vieler Produkte, Dienste und Java-Komponenten ist. Durch die Log4Shell genannte Lücke ist die vollständige Übernahme von Servern möglich. Deswegen überrascht es nicht, dass die Schwere der Schwachstelle den Höchstwert 10 auf der CVSS-Skala erhält. Auch das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) hat für Log4Shell eine Cybersicherheitswarnung der Stufe Rot veröffentlicht.

Mittlerweile gibt es nicht nur einen Proof-of-Concept, sondern bereits reale Angriffe auf Unternehmen und Organisationen. Tatsächlich findet derzeit ein Wettlauf statt zwischen Angreifern und Verteidigern. Während Hacker auf der einen Seite internetweite Scans durchführen, um anfällige Systeme zu identifizieren und Schwachstellen auszunutzen, versuchen Sicherheitsexperten auf der anderen Seite schnellstmöglich verwundbare Systeme zu aktualisieren und Schutzmaßnahmen umzusetzen. Software-Entwickler allerorts arbeiten fieberhaft an der Überprüfung ihrer Anwendungen und Codebibliotheken auf Abhängigkeiten von den anfälligen Versionen der log4j-Bibliothek.

Was ist Log4Shell?

Die als CVE-2021-44228 indizierte Schwachstelle in den Log4j-Versionen 2.0 bis 2.14.1 ist eine RCE-Schwachstelle (Remote Code Execution), die es einem Angreifer ermöglicht, Code seiner Wahl auf einem betroffenen Server aus der Ferne auszuführen. Sollte der Angreifer in das lokale Netzwerk gelangen, können auch interne Systeme, die nicht mit dem Internet verbunden sind, übernommen werden. Letztendlich bedeutet eine RCE-Schwachstelle, dass ein Angreifer keinen physischen Zugriff benötigt, um beliebigen Code auszuführen, der ihm die vollständige Kontrolle über betroffene Systeme verschafft und den Diebstahl sensibler Daten ermöglicht.

Zeitleiste

Diese Zeitleiste stellt die Ereignisse im Zusammenhang mit der kritischen Log4Shell Sicherheitslücke chronologisch dar:

November: Die CVE-ID für die Schwachstelle wird reserviert.
Dezember: Der erste bekannte Exploit der Schwachstelle wird in freier Wildbahn entdeckt.
Dezember: Die CVE-ID wird veröffentlicht und ein Patch erscheint, um die Sicherheitslücke zu schließen. Das BSI stuft seine Warnmeldung auf Orange hoch.
Dezember: Um 14:24 Uhr MEZ erhält das ESET-Modul zum Schutz vor Netzwerkangriffen ein Erkennungs-Update für diese Schwachstelle. Das BSI stuft seine Warnung auf Rot hoch.

Erkennung

ESET hat eine Erkennung für Exploits dieser Sicherheitslücke veröffentlicht. Diese Exploits können sowohl im eingehenden als auch im ausgehenden Datenverkehr auf Windows-Systemen vorhanden sein. Angreifer, die versuchen, sich von solchen Systemen auszubreiten, werden somit blockiert. Die Erkennung von Exploit-Versuchen wurde mit den folgenden Erkennungsnamen ausgerollt:

JAVA/Exploit.CVE-2021-44228
JAVA/Exploit.CVE-2021-44228.B

Schadensbegrenzungsmaßnahmen

Um sich vor Exploits zu schützen, ist es wichtig, alle betroffenen Versionen der Bibliothek zu finden. Beginnen Sie damit, eine priorisierte Liste der zu durchsuchenden Systeme zu erstellen und sie der Reihe nach zu evaluieren. Der knifflige Teil kann darin bestehen, anfällige Versionen auszuspähen, die in Java Archive-Archiven (JAR) als transitive Abhängigkeiten existieren.

Hier sind einige grundlegende Skripte, die Sie verwenden können (und die Sie an Ihre Systeme anpassen sollten):

Log4j auf Systemen (Linux und Windows) erkennen

Dieses auf GitHub verfügbare Skript sucht in jedem .jar-Archiv auf Ihrem System nach der fehlerhaften Datei JndiLookup.class.

Linux

sudo grep -r --include "*.jar" JndiLookup.class /

Windows

findstr /s /i /c:"JndiLookup.class" C:\*.jar

Angriffsversuche auf die Schwachstelle in Ihren Logs (Linux) erkennen

Dieses Skript sucht nach Angriffsversuchen in unkomprimierten Dateien im Linux-Protokollverzeichnis /var/log und allen seinen Unterverzeichnissen:

Grep

sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log

Zgrep

sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+

Ergebnisse aufzeichnen

Nachdem Sie Skripte oder Erkennungstools ausgeführt haben, notieren Sie die Ergebnisse, um eine vollständige Audit-Dokumentation all Ihrer Systeme zu erstellen. Hierbei sollte festgestellt werden, ob Sie Log4j auf einem System gefunden haben und ob in den Protokollen Angriffsversuche entdeckt wurden.

Wechseln Sie zur neuesten Version von Log4j

Die anfälligen Versionen von Log4j 2 sind alle Log4j-Core-Versionen von 2.0-beta9 bis 2.14.1. Beachten Sie, dass diese Bibliothek nicht mit log4j-api verwechselt werden darf, die von dieser Sicherheitsanfälligkeit nicht betroffen ist. Das beste Mittel besteht darin, Ihre Abhängigkeiten zu aktualisieren, um die neueste Version zu verwenden, die 2.15.0 ist.

Obwohl die Versionen 1.x von Log4j von dieser speziellen Sicherheitsanfälligkeit nicht betroffen sind, weisen sie andere Sicherheitslücken auf. Konkrete Pläne sollten vorliegen, um auf die neueste Version der Bibliothek zu migrieren. Tatsächlich ist jetzt wie immer ein guter Zeitpunkt, um diese Pläne voranzutreiben.