Besteht die Gefahr, dass ein Wurm die Log4j-Schwachstelle ausnutzt?

https://network-king.net/wp-content/uploads/2021/12/shutterstock_669987499-769x414.jpg

Nach Ansicht von Tom Kellermann, Leiter der Cybersicherheitsstrategie bei VMware, ist die Möglichkeit, die Log4j-Schwachstelle mit einem Wurm auszunutzen, das schlimmste denkbare Szenario für die Cybersicherheit zu Beginn des Jahres. „Einer der verheerendsten [Würmer] der frühen 2000er Jahre war Code Red„, so Kellermann gegenüber ZDNet. „Seitdem haben wir keine so weitreichenden globalen Auswirkungen mehr gesehen.“

Die Möglichkeit eines Wurms hat in der Cybersicherheits-Community für viel Gesprächsstoff gesorgt. Nach Ansicht des Cybersecurity-Experten Marcus Hutchins sind solche Befürchtungen übertrieben, denn „ein Wurm bräuchte eine neue Ausnutzungstechnik, um aus der Sicherheitslücke einen echten Nutzen zu ziehen. Erstens gibt es bereits eine Massenausnutzung (man kann das gesamte Internet von einem Server aus verbreiten). Zweitens erfordert die Entwicklung von Würmern Zeit und Geschick, aber die meisten Angreifer arbeiten gegen die Uhr (Patching und andere Angreifer)“, schrieb Hutchins auf Twitter.

 Jake Williams, CTO von BreachQuest, ist derweil der Meinung, dass zwar jemand einen Wurm entwickeln könnte, der Log4Shell ausnutzt, es aber unwahrscheinlich ist, dass er mit WannaCry, NotPetya oder früheren Würmern vergleichbar ist, die Prozesse auf Systemebene ausnutzen.

Angriffe, die auf der Log4j-Schwachstelle basieren, gehen weiter, und Cybersecurity-Experten warnen, dass kein Ende in Sicht ist. Jüngste Hinweise deuten darauf hin, dass Angreifer versuchen, die Schwachstelle auszunutzen, um die von Amazon Web-Service-Konten verwendeten Schlüssel offenzulegen. Es gibt auch Anzeichen dafür, dass Angreifer versuchen, die Schwachstelle auszunutzen, um Fernzugriffstools in den Netzwerken der Opfer zu installieren, möglicherweise Cobalt Strike, ein Schlüsselwerkzeug für viele Ransomware-Angriffe.

Es gibt Hunderte von Software- und Netzwerkprodukten, die weiterhin anfällig sind – und noch nicht für alle gibt es Patches oder Umgehungslösungen. „Wir haben seit dem Höchststand am 1. Dezember keinen signifikanten Rückgang der Exploit-Versuche festgestellt, und diese Sonden und Exploits kommen aus einer weltweit verteilten Infrastruktur“, sagt Sean Gallagher von Sophos. Am Dienstag, den 21. Dezember, stellte das Unternehmen fest, dass die meisten Angriffe aus China und Russland kamen. Nur eine einzige Domain, die mit einer russischen Kryptowährungs-Mining-Organisation in Verbindung gebracht wird, war für 11 % der bisher registrierten Angriffe verantwortlich. Die Angriffsfläche ist also immer noch außerordentlich groß. Experten sorgen sich, wie lange Unternehmen brauchen werden, um auf das größte Cybersicherheitsproblem seit Jahren zu reagieren.

DevSecOps-Experten fragen sich, ob dies endlich der lang erwartete Wendepunkt in der Cybersicherheit ist. Möglicherweise, denn immerhin ist diese ganze Cybersicherheitspanik schon fast eine jährliche Tradition geworden. Im Dezember letzten Jahres gab es Berichte über eine weitere massive Sicherheitskrise mit der SolarWinds-Panne, die nach wie vor ein Angriffsvektor ist. Davor, im Januar 2018, sorgte ein anderes weitreichendes Cybersicherheitsproblem für Schlagzeilen: die Sicherheitslücken Meltdown und Spectre.

Bislang haben wir jedoch gesehen, dass Unternehmen sich schwertun, die Dringlichkeit von DevSecOps zu verstehen.

Erschwerend kommt hinzu, dass einige Unternehmen – darunter einige große IT-Softwareanbieter – immer noch untersuchen, ob die anfällige Version der Bibliothek in ihren Produkten vorhanden ist. Das ist nicht neu: Ein detaillierter Post-Mortem-Bericht über die Datenpanne bei Equifax im Jahr 2017 wies auf ein ähnliches Szenario wie jetzt hin, als die IT-Teams des Kreditbüros ihre Systeme nach einer weiteren Java-Schwachstelle durchsuchten – aber Angreifer sie früher fanden.

Und es sind nicht nur IT-Produkte und -Dienstleister, die sich Sorgen machen müssen. Die FDA hat davor gewarnt, dass die Schwachstelle in Log4j in verschiedenen Branchen „weit verbreitet ist und aktiv ausgenutzt wird“, sagte aber, dass ihr keine bestätigten Zwischenfälle bekannt sind, die medizinische Geräte betreffen. „Hersteller sollten prüfen, ob sie von der Schwachstelle betroffen sind, dann das Risiko einschätzen und Abhilfemaßnahmen entwickeln“, so die FDA. „Da es sich um ein fortlaufendes und sich weiterentwickelndes Problem handelt, empfehlen wir auch eine kontinuierliche Überwachung und Reaktion, um sicherzustellen, dass die Medizinprodukte angemessen geschützt sind.“ Die Herausforderung für Krankenhäuser und Gerätehersteller besteht nun darin, die Auswirkungen der Log4j-Schwachstelle auf ihren jeweiligen Gerätebestand zu bewerten.

Zur Unterstützung der Sicherheitsteams von Anbietern und Anwendern hat die US Cybersecurity and Infrastructure Agency ein Open-Source-Scan-Tool veröffentlicht, mit dem Unternehmen und Behörden Log4j-Instanzen auf ihren Systemen finden können. Und die Apache Software Foundation ist unermüdlich auf der Suche nach Lösungen. Die Aktualisierung von Log4j 2.17.0 ist die dritte seit dem Auftauchen von Log4Shell und dem Beginn der Sicherheitslücke. In den Versionen 2.15.0 und 2.16.0 wurden Fehler bei der Remotecodeausführung behoben. Es behebt eine neue Schwachstelle, die letzte Woche gemeldet wurde und Denial-of-Service-Angriffe gegen anfällige Instanzen des Java-Logging-Frameworks ermöglicht.

Die beste Antwort ist ganz klar: Beheben oder entschärfen Sie Ihre eigenen Systeme jetzt!

FacebookTwitterLinkedIn