Die Log4j-Schwachstelle stellt ein Jahr nach der Offenlegung durch die Apache Software Foundation im vergangenen November weiterhin eine große Bedrohung für Unternehmen dar - obwohl die Anzahl der öffentlich bekannt gegebenen Angriffe, die auf den Fehler selbst abzielen, geringer war, als viele ursprünglich erwartet hatten.

Sicherheitsforscher sagen, dass ein hoher Prozentsatz der Systeme immer noch nicht gegen den Fehler gepatcht wurde, und Unternehmen stehen vor der Herausforderung, das Problem zu finden und zu beheben und dann zu verhindern, dass der Fehler erneut in die Umgebung eingeführt wird.

„Die Tatsache, dass Log4j in [fast] 64 % der Java-Anwendungen verwendet wird und nur 50 % davon auf eine vollständig gefixte Version aktualisiert wurden, bedeutet, dass Angreifer es weiterhin ins Visier nehmen werden“, sagt David Lindner, CISO bei Contrast Security. „Zumindest im Moment haben Angreifer weiterhin viel Spaß dabei, Wege zu finden, die sie über Log4j ausnutzen können.“

Mehrere Angriffe, aber weniger als erwartet

Der Log4j-Fehler (CVE-2021-44228), allgemein als Log4Shell bezeichnet, ist in der JNDI-Funktion (Java Naming and Directory Interface) von Log4j zum Speichern und Abrufen von Daten vorhanden. Es gibt entfernten Angreifern eine trivial einfache Möglichkeit, die Kontrolle über anfällige Systeme zu übernehmen – ein Problem, da Log4J in praktisch jeder Java-Anwendungsumgebung verwendet wird. Sicherheitsforscher betrachten es aufgrund seiner Verbreitung und der relativen Leichtigkeit, mit der Angreifer es ausnutzen können, als eine der bedeutendsten Schwachstellen der letzten Jahre.

Im vergangenen Jahr gab es zahlreiche Berichte über Bedrohungsakteure, die auf den Fehler abzielten, um sich einen ersten Zugang zu einem Zielnetzwerk zu verschaffen. An vielen dieser Angriffe waren von Nationalstaaten unterstützte APT-Gruppen (Advanced Persistent Threat) aus China, Nordkorea, dem Iran und anderen Ländern beteiligt. Im November warnte beispielsweise die US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) vor einer von der iranischen Regierung unterstützten APT-Gruppe, die die Log4j-Schwachstelle in einem ungepatchten VMware Horizon-Server ausnutzt Kryptomining-Software und Credential Harvester bereitstellen in einem Bundesnetz.

Die Warnung ähnelte der von Fortinet im März vor dem Einsatz des chinesischen Bedrohungsakteurs Deep Panda identischer Vektor eine Hintertür auf Zielsystemen einzusetzen und eine weitere von Ahn Labs über die nordkoreanische Lazarus-Gruppe Verteilen einer eigenen Hintertür in der gleichen Weise. Andere wie Microsoft haben ebenfalls berichtet, staatliche Akteure wie die iranische Phosphorgruppe und Chinas Hafnium-Bedrohungsakteur bei der Verwendung von Log4 zu beobachten Drop-Reverse-Shells auf infizierten Systemen.

Trotz solcher Berichte – und mehrerer anderer über finanziell motivierte Cyberkriminalitätsgruppen, die auf Log4j abzielen – ist die tatsächliche Anzahl öffentlich gemeldeter Kompromittierungen mit Log4 vergleichsweise gering geblieben, insbesondere im Vergleich zu Vorfällen mit Schwachstellen in Exchange Server wie z ProxyAnmeldung und ProxyShell. Laut Bob Huber, Chief Security Officer bei Tenable, waren Ausmaß und Umfang der gemeldeten Angriffe angesichts der Einfachheit der Schwachstelle und des Angriffspfads überraschend geringer als erwartet. „Erst vor kurzem haben wir einige signifikante Beweise für Targeting gesehen, wie durch die jüngsten nationalstaatlichen Aktivitäten von CISA festgestellt wurde“, sagt Huber.

Unverminderte Bedrohung

Das bedeutet jedoch nicht, dass die Bedrohung durch Log4j im vergangenen Jahr abgenommen hat, stellen Sicherheitsforscher fest.

Zum einen ist ein großer Prozentsatz der Unternehmen weiterhin so anfällig für die Bedrohung wie vor einem Jahr. Eine Analyse der Telemetrie im Zusammenhang mit dem Fehler, die Tenable kürzlich durchgeführt hat, zeigte 72 % der Organisationen waren anfällig an Log4j, Stand 1. Oktober. Tenable stellte fest, dass 28 % der Unternehmen weltweit den Fehler vollständig behoben haben. Aber Tenable stellte fest, dass Organisationen, die ihre Systeme saniert hatten, oft immer wieder auf Log4j stießen, wenn sie neue Assets zu ihren Umgebungen hinzufügten.

In vielen Fällen – in der Tat 29 % – wurden Server, Webanwendungen, Container und andere Assets kurz nach der ersten Behebung für Log4j anfällig.

„Angenommen, Unternehmen bauen die Lösung in die linke Seite der Gleichung ein – während der Build-Pipeline für Software – sollten die Wiedereinführungsraten sinken“, sagt Huber. „Ein Großteil der Wiedereinführungs- und Änderungsrate hängt stark vom Software-Release-Zyklus einer Organisation ab.“

Auch trotz des fast allgegenwärtigen Bewusstseins des Fehlers innerhalb der Cybersicherheits-Community sind verwundbare Versionen von Log4j in vielen Organisationen aufgrund der Art und Weise, wie Anwendungen es verwenden, nach wie vor ärgerlich schwer zu finden. Einige Anwendungen könnten die Open-Source-Logging-Komponente als direkte Abhängigkeit in ihren Anwendungen verwenden, und in anderen Fällen könnte eine Anwendung Log4j als transitive Abhängigkeit verwenden – oder als Abhängigkeit einer anderen Abhängigkeit, sagt Brian Fox, CTO bei Sonatype.

„Da transitive Abhängigkeiten von Ihren direkten Abhängigkeitsentscheidungen eingeführt werden, sind sie Ihren Entwicklern möglicherweise nicht immer bekannt oder direkt sichtbar“, sagt Fox.

Als die Apache Foundation Log4Shell zum ersten Mal veröffentlichte, mussten Unternehmen in vielen Fällen Tausende von internen E-Mails versenden, Ergebnisse in Tabellenkalkulationen sammeln und Dateisysteme rekursiv scannen, sagt Fox. „Dies kostete Unternehmen wertvolle Zeit und Ressourcen, um die Komponente zu patchen, und verlängerte das Ausmaß der böswilligen Auswirkungen der Schwachstelle“, sagt er.

Daten aus dem Maven Central Java-Repository, das Sonatype verwaltet, zeigen dies 35 % der Log4-Downloads Derzeit gibt es weiterhin anfällige Versionen der Software. „Viele Unternehmen versuchen immer noch, ihr Softwareinventar aufzubauen, bevor sie überhaupt mit einer Reaktion beginnen können, und sind sich der Auswirkungen transitiver Abhängigkeiten nicht bewusst“, sagt Fox.

Aufgrund all der Probleme kam das Überprüfungsgremium des US-Heimatschutzministeriums Anfang dieses Jahres zu dem Schluss, dass Log4 ein endemisches Sicherheitsrisiko mit denen Organisationen jahrelang fertig werden müssen. Die Mitglieder des Vorstands bewerteten, dass anfällige Instanzen von Log4j noch viele Jahre in Systemen verbleiben und Unternehmen auf absehbare Zeit einem Angriffsrisiko aussetzen werden.

Das eine positive Ergebnis

Sicherheitsforscher, die den Fehler verfolgen, sagen, dass die positive Auswirkung von Log4j die erhöhte Aufmerksamkeit ist, die es auf Praktiken wie Software-Kompositionsanalyse und Software-Bill of Materials (SBOM) gelenkt hat. Die Herausforderungen, mit denen Organisationen konfrontiert sind, allein die Feststellung, ob sie anfällig sind oder wo die Schwachstelle in ihrer Umgebung bestehen könnte, hat zu einem besseren Verständnis der Notwendigkeit der Transparenz aller Komponenten in ihrer Codebasis geführt – insbesondere derer aus Open-Source- und Drittanbieterquellen.

„Die Untersuchung des Log4J-Problems hat die Notwendigkeit einer besseren Bescheinigung der Softwarelieferkette zusätzlich zu SBOMs bestätigt, die mit der Geschwindigkeit von DevOps Schritt halten“, sagt Matthew Rose, CISO bei ReversingLabs. „Anwendungssicherheits- und Architekturteams haben erkannt, dass es nicht ausreicht, nur nach Risiken in Teilen der Anwendung wie Quellcode, APIs oder Open-Source-Paketen zu suchen. Sie erkennen jetzt, dass ein vollständiges Verständnis der Anwendungsarchitektur genauso wichtig ist wie das Auffinden von SQLI- oder Cross-Site-Scripting-Bugs (XSS)“, sagt er.

• Coinsmart. Europas beste Bitcoin- und Krypto-Börse.Mehr Info
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://www.darkreading.com/application-security/one-year-later-log4shell-exposed-attack