Die Log4j-Sicherheitslücke und der Umgang mit den Folgen

Apaches Log4j war Ziel eines der bedeutendsten Cybervorfälle, die in jüngster Zeit bekannt wurden. Für Unternehmen, die sich der Schwachstelle immer noch nicht bewusst sind, ist es vermutlich bereits zu spät.

Kurz gesagt ist Log4j eine Software, die in bestimmten Versionen Schwachstellen aufweist. In erster Linie wird die Software als Logging-Framework verwendet, d.h. sie ermöglicht Entwicklern die Überwachung beziehungsweise Protokollierung digitaler Ereignisse auf einem Server. Diese Protokolle lassen sich anschließend von internen Teams daraufhin überprüfen, ob der Betrieb regulär abläuft oder es Anzeichen für ein anormales Verhalten gibt. Eine Software sollte vor Daten schützen, die online von nicht vertrauenswürdigen Benutzern eingebracht werden. Im aktuellen Fall gestattete ein Fehler nicht autorisierten Benutzern aber einen ersten Zugang, mit dem sie auf sensible Daten zugreifen und sogar die Server-Einstellungen manipulieren konnten. Ohne einen Patch kann ein Angreifer die Sicherheitslücke nutzen, um Serveranwendungen und angeschlossene Geräte zu übernehmen und Unternehmensnetzwerke zu infiltrieren. Es gibt bereits eine Reihe von Berichten über Malware, Ransomware und andere automatisierte Bedrohungen, die diese Sicherheitslücke aktiv ausnutzen. Betroffen ist praktisch jeder Aspekt eines Unternehmens, von den Datenbeständen bis hin zu KI-Anwendungen.

Die Log4j-Schwachstelle aus technischer Sicht

Aufgrund einer ungenauen Eingabevalidierung existiert die Log4j-Bibliothek auf einem beliebigen Server, auf den ein nicht vertrauenswürdiger Benutzer zugreifen könnte. Da die Entwickler davon ausgegangen sind, dass die an die Logs zurückgegebenen Daten als normaler Text gewertet würden, erfolgte keine weitere Eingabevalidierung. Auf diese Weise gelangten Eingaben nicht vertrauenswürdiger Benutzer in die Protokolle. Ein böswilliger Benutzer würde die Java Naming and Directory Interface (JNDI)-Suche aufnehmen, die in einem URL-Parameter auf einen verwalteten Setup-Server verweist. Der lokale Genalgorithmus kommuniziert mit dem Lightweight Directory Access Protocol (LDAP)-Server des Angreifers in der Verzeichnisbildung enthaltene Werte für den Beispielfaktor in der Java-Codebasis. Diese beiden Werte beinhalten die Java-Klasse des Angreifers, die dann in den Speicher geladen und von Log4j ausgeführt wird, womit die Codeausführung abgeschlossen wird. Indem sich ein Angreifer die anfällige Version der Software zunutze macht, kann er bösartige Befehle auf dem Remote-Server ausführen. 

Deshalb ist es bei der Entwicklung einer neuen Software ganz entscheidend, vorab eine Bedrohungsmodellierung durchzuführen, potenzielle Lücken zu identifizieren und Mechanismen wie etwa die Eingabevalidierung vorherzusagen. Fazit: Es handelt sich um eine hoch kritische Aufgabenstellung, die man keinesfalls vernachlässigen sollte, will man nicht in Situationen geraten wie die aktuelle.

Wer steckt hinter dem Log4j-Angriff?

Opportunistische Cyberkriminelle durchsuchen Unternehmen auf Shell-Schwachstellen. Zunächst wurde der Fehler bereits am 24. November verantwortungsvoll von Forschern der Apache-Stiftung gegenüber gemeldet. Dennoch scheint die Schwachstelle bereits ausgenutzt worden zu sein, bevor sie allgemein bekannt wurde. Experten haben zunächst hochkarätige Akteure aus dem Iran, Nordkorea und der Türkei mit der anfänglichen Ausnutzung der Sicherheitslücke in Verbindung gebracht, da der Fehler relativ einfach auszunutzen ist. In letzter Zeit haben wir jedoch beobachtet, wie verschiedene Gruppen von Cyberkriminellen bei der Ausnutzung der Schwachstelle zusammenarbeiten. So erhalten sie einen ersten Zugang zu VMware und bewegen sich dort in der typischen Seitwärtsbewegung fort, weil auch VMware-Produkte Log4j nutzen. Apache-Software ist allgegenwärtig und die Schwachstelle vergleichsweise einfach auszunutzen. Entsprechend hat sich so gut jede Art von Angreifer dieser Lücke bedient, um innerhalb einer Organisation Fuß zu fassen und davon in finanzieller Hinsicht zu profitieren – vom Script-Kiddie bis hin zu staatlich finanzierten Cybergangs.

Ist die Log4j-Sicherheitslücke einer verantwortungslosen Offenlegung zum Opfer gefallen?

Die verantwortungsvolle Offenlegung ist eines der Schlüsselkonzepte der Cybersicherheit. Trotzdem ließe sich argumentieren, dass die Berichterstattung über Log4j dazu geführt hat, dass noch weit mehr Cyberkriminelle von der Schwachstelle tatsächlich Gebrauch gemacht haben. Wie schon gesagt, es handelt sich um ein relativ simpel auszunutzende Schwachstelle, und die ständige Berichterstattung und mediale Aufmerksamkeit haben ein Übriges dazu getan. Während Firmen kaum die Gelegenheit hatten, die Schwachstelle schnell genug zu beheben, konnten  Cyberkriminelle sich einen nicht un unterschätzenden Vorsprung verschaffen.

Ein wiederkehrendes Problem… Nachdem ein Proof of Concept zur Ausnutzung der Schwachstelle veröffentlicht wurde, gab Apache zwar einen Patch heraus, allerdings war die Schwachstelle da bereits öffentlich bekannt. Weltweit begannen Cyberkriminelle, sämtliche Netzwerke nach anfälligen Systemen zu durchsuchen und sich an der Ausnutzung der Schwachstelle zu versuchen. Durch die andauernde mediale Berichterstattung wurden immer mehr technische Details bekannt. Auch das hat dazu beigetragen, dass die Schwachstelle sich noch leichter ausnutzen ließ. Auch eine verantwortungsvolle Offenlegung ist also nicht ohne Risiko.

Was kann man tun, um sich besser zu schützen

Derzeit haben so gut wie alle Unternehmen ein Problem damit, anfällige Ressourcen überhaupt erst zu identifizieren und entsprechend zu schützen. Das ist nichts Außergewöhnliches, denn etliche Firmen haben Schwierigkeiten, anfällige Systeme in eine Umgebung zu erkennen. Nicht selten mangelt es an geeigneten Software- oder Inventarlisten, die Auskunft über Schwachstellen, Viren und die allgemeine Bedrohungslage geben können. Verfügt ein Unternehmen an dieser Stelle nicht über entsprechende Mechanismen, sollte es sich zwingend mit einem Managed Service Provider zusammentun, der die notwendigen Mechanismen bereitstellen kann, um potenzielle Ausnutzungsversuche zu erkennen. Zusätzlich gilt es sämtliche Software-Anwendungen zu identifizieren, die ebenfalls die anfälligen Apache-Bibliotheken nutzen und alle von Drittanbietern veröffentlichten Patches einzuspielen. Unternehmen, die unterschiedliche Versionen von Log4j verwenden oder die eine Software nutzen, welche diese Bibliothek enthält, müssen eine Bibliotheksprüfung potenziell betroffener Anwendungen auf ungewöhnliches Verhalten hin durchführen.

Cyberkriminelle sind Opportunisten und nehmen jede sich bietende Gelegenheit wahr. Firmen  müssen davon ausgehen, dass es jederzeit zu einem Sicherheitsverstoß kommen kann, und  sie sollten die Protokolle auf betroffene Anwendungen oder ungewöhnliche Aktivitäten hin überprüfen. Ist das der Fall, empfehlen wir, Early Response Experten hinzuzuziehen. Sie sind in der Lage, die Bedrohung zu isolieren, einzudämmen und schlußendlich zu beseitigen sowie die Systeme weiderherzustellen. Auch wenn es wie eine Binsenweisheit klingt: Will man Cyberkriminellen einen Schritt voraus sein, kommt man nicht umhin die gesamte Software auf die jeweils sicherste Version zu aktualisieren.

Was es in Zukunft zu beachten gilt

Wenn Sie nicht über die finanziellen Mittel verfügen, sich ein internes Cybersicherheitsteam zu leisten oder Ihre Kristallkugel gerade verlegt haben, wird es nahezu unmöglich, eine derartige Sicherheitslücke vorherzusehen und zu verhindern. 

Deshalb empfehlen wir, sich auf die Schwachstellen zu konzentrieren, die sich aufgrund menschlicher Fehler wie Gewohnheiten, Abläufe oder Firmenkultur hartnäckig halten. Ein Zero-Trust-Modell einzuziehen ist der beste Weg, um einen Vorfall wie Log4j zu verhindern, bevor er auftritt. Im Zeitalter hybrider Arbeitsumgebungen, werden Unternehmen weiterhin in hohem Maße auf VPNs und SaaS angewiesen sein. Und Angreifer werden nicht zögern, diese für sich auszunutzen.

Für 2022 gehen wir deshalb stark davon aus, dass diese Gemengelage zu weiteren Angriffen auf die Lieferketten führen wird. Alles, was es braucht, um ein Unternehmen oder sogar eine Nation in die Knie zu zwingen, ist ein simpler Klick auf einen Link in einer Phishing-E-Mail, gerichtet an einen Mitarbeiter eines Softwareunternehmens. Angreifer verschaffen sich so Zutritt zur Netzwerkumgebung und können sich dort frei bewegen, bis sie den richtigen Ablageort für den Einsatz der Malware finden. Angesichts der Tatsache, dass kritische Infrastrukturen auf OT angewiesen sind, werden 2022 wahrscheinlich mehr Schwachstellen in einer betrieblichen Technologieumgebung ins Bewusstsein rücken. Betrachtet man die Auswirkungen solcher Angriffe im Jahr 2021, werden kritische Infrastukturen eines der Hauptziele nicht zuletzt nationalstaatlich finanzierter Angreifer werden.

Autor: Christos Betsios, Cyber Operations Officer, Obrela Security Industries

www.obrela.de