Einführung
Es ist etwas mehr als ein Jahr her, dass die berüchtigte log4j-Schwachstelle öffentlich bekannt wurde und die Sicherheitsteams angesichts der bevorstehenden Feiertage in einen Patching-Rausch versetzte. Die als Log4Shell bezeichnete Schwachstelle ist eine kritische Schwachstelle für Remotecodeausführung (RCE) in der Apache log4j-Protokollierungsbibliothek. Sie ermöglicht es einem Angreifer, eine Anfrage mit einer Nutzlast zu senden, die, wenn sie von einer anfälligen Version von log4j protokolliert wird, zu einer Remotecodeausführung auf dem Host führt. Darüber hinaus wird die Nutzlast mit den Rechten des Benutzers ausgeführt, der den Dienst ausführt (ein weiterer Grund, Dienste nicht als `root` auszuführen).
Die Schwachstelle wurde mit dem höchstmöglichen CVSS-Score von 10 bewertet, und die Anwender wurden aufgefordert, die anfälligen Systeme sofort zu patchen und zu aktualisieren. Die Allgegenwärtigkeit der log4j-Bibliothek, die in einer Vielzahl von Tools und Produktenverwendet wird , hatdie Schwere der Sicherheitslücke noch verstärkt.
Seit dem Bekanntwerden dieser Sicherheitslücke wurde viel über sie geschrieben, einschließlich unseres ersten Blicks auf die Sicherheitslücke. Hier ist unsere Untersuchung darüber, wie sich die Abhilfemaßnahmen für Log4Shell im Laufe der Zeit entwickelt haben.
Messung der Reaktion des Internets auf Log4Shell
Auf Censys wollten wir besser verstehen, wie das Internet als Ganzes auf diese Sicherheitslücke reagiert. Um dies zu messen, haben wir eine Untergruppe von Software identifiziert , die auf Censys sichtbar ist und deren Versionen wir erkennen und einem Status zuordnen konnten, ob sie wahrscheinlich "anfällig" oder "nicht anfällig" für Log4Shell ist. Insbesondere haben wir Hosts untersucht, auf denen die Software Metabase, Neo4j, Solr, Pagerduty und Unifi läuft. Die folgende Analyse stellt nicht jedes Gerät dar, das für Log4Shell anfällig ist, sondern nur das, was wir bei unseren passiven Scans von Geräten mit Internetanschluss sehen können.
Die unmittelbare Folgezeit
Sie erkennen diese Grafik vielleicht, wenn Sie unseren State of the Internet Report 2022 gelesen haben (und falls nicht, können Sie Ihr Exemplar hier erhalten). Wie im Bericht beschrieben, wurden die Patches nach dem Bekanntwerden der Sicherheitslücke schnell aufgespielt, und die Zahl der Geräte, auf denen Software läuft, die anscheinend für Log4Shell anfällig ist, ging von Dezember 2021, als die Sicherheitslücke bekannt wurde, bis Januar 2022 um 34 % zurück. Wir waren jedoch neugierig, wie lange dieses Gefühl der Dringlichkeit anhalten würde.
Ein Jahr später
Von Dezember 2021 bis Dezember 2022 beobachtete Censys einen Rückgang von 78 % bei den Hosts, auf denen anscheinend Software läuft, die für Log4Shell anfällig ist.
Während der allgemeine Trend, dass die Zahl der anfälligen Versionen abnimmt, vielversprechend ist, ist es besorgniserregend, dass immer noch über 23.000 Hosts auf Censys sichtbar sind, die anfällig zu sein scheinen. Im Dezember 2022 wies Wired darauf hin, dass chinesische und iranische staatlich gesponserte Akteure diese CVE weiterhin ausnutzen. Die Ausnutzungsversuche sind wahrscheinlich auch nicht auf staatlich gesponserte Akteure beschränkt. Zum Zeitpunkt dieses Beitrags identifiziert GreyNoise 327 Hosts, die anscheinend aktiv nach der log4j-Schwachstelle suchen.
Anfälligkeit nach Autonomem System und Land
Bei der Untersuchung der 10 wichtigsten autonomen Systeme, in denen log4j im Dezember 2022 anfällig zu sein scheint, ist es nicht überraschend, dass zwei AS, die Amazon gehören, die Liste anführen, da Amazon einer der größten Besitzer von Internet-Immobilien ist, sowohl in Bezug auf die Anzahl der Hosts als auch der Dienste. Andere beliebte Cloud-Anbieter, darunter Digital Ocean, Microsoft, OVH, Google und Alibaba, sind ebenfalls auf dieser Liste zu finden.
Ähnlich wie bei der Beobachtung, dass Amazon eine große Anzahl von Diensten hat, die wahrscheinlich für Log4Shell anfällig sind, ist es nicht überraschend, dass die USA die Liste der Länder anführt, in denen wir die meisten Dienste beobachten, die wahrscheinlich anfällig sind. Wenn jedoch die Verteilung der Länder, in denen wir anfällige log4j-Versionen beobachten, die Verteilung der Länder mit den meisten globalen Diensten widerspiegeln würde, würden wir nicht erwarten, dass Brasilien so weit oben auf dieser Liste steht.
Schlussfolgerung
Obwohl die Sicherheitsgemeinschaft vor einem Jahr zusammenkam, um die log4j-Schwachstelle zu patchen und zu beheben, die als "die wohl schwerwiegendste Schwachstelle aller Zeiten" bezeichnet wurde, wird sie weiterhin ausgenutzt und ist nach wie vor ein wertvolles Werkzeug im Werkzeugkasten von Bedrohungsakteuren. Eine nicht unerhebliche Anzahl von Hosts ist nach wie vor anfällig für Angriffe. Der beste Zeitpunkt, um log4j zu patchen, war vor einem Jahr, aber wenn Sie eine verwundbare Version verwenden, ist der zweitbeste Zeitpunkt jetzt.
Censys ASM-Kunden haben Zugang zu Risiken für die in diesem Beitrag besprochene Software.
