"In einer Aufsehen erregenden Angriffswelle wurden im Dezember 2021 aufgrund einer Sicherheitslücke in Log4j weltweit zehntausende Server Opfer von Cyberangriffen. Die Schwachstellen hatte in dem sogenannten Zero-Day-Exploit eine bisher unbekannte Spionagegruppe…“
Moment mal… das habe ich doch schon einmal geschrieben. Fast wörtlich gleich. Im März diesen Jahres. Nur mit Microsoft Exchange statt Log4j. Damals gab es im Nachhinein einiges an Häme: Mit bestimmten Technologien wäre das nicht passiert, Administratoren seien zu langsam.
Nun, diesmal sind leider die „bestimmten Technologien“ betroffen. Heute wie damals gibt es Angriffe, schon bevor der Patch überhaupt bei vielen betroffenen Produkten zur Verfügung steht – der Administrator hat also gar keine Chance, ausreichend schnell zu reagieren. Das Ausmaß der Angriffswelle ist aktuell noch gar nicht abzusehen. „The Internet is on fire“ titelt etwa das Wired Magazine.
Anstatt sich gegenseitig mit Häme zu überschütten und wieder geradezu religiös die angebliche Überlegenheit bestimmter Technologien herauszuheben, wäre es besser, sich damit zu beschäftigen, wie man solche Angriffswellen zukünftig verhindern kann. Die IT-Sicherheit muss endlich zu einer zielorientierten Fehlerkultur kommen. Menschen machen Fehler, das ist ein nicht zu ändernder Fakt. Es bringt wenig, wenn man jetzt die Entwickler von Log4j für einen „katastrophalen Design-Fehler“ bestrafen will – wie es manche Fachmedien fordern.
„Bei Fehlern trösten, bei riskantem Verhalten coachen, bei Vorsatz diskussionslos bestrafen“ – das sind die Grundaussagen von Just Culture, der aus meiner Sicht einzig sinnvollem Fehlerkultur. Wir von DriveLock haben dieses Konzept verinnerlicht und bringen es auch in unserer Software ein und mit unserer Software zum Kunden.
Was bedeutet das für den Log4j-Hack: die Log4j-Entwickler haben einen Fehler gemacht. Ganz bestimmt nicht mit Vorsatz. Es gilt jetzt, die Ursachen zu finden, warum genau dieser Fehler gemacht wurde und nicht herauszufinden, wer ihn gemacht hat. Das ist Aufgabe der Log4j-Community – „bei Fehlern trösten“.
Das riskante Verhalten legen in diesem Fall die Applikationsbetreiber an den Tag. Offenbar sind Server nicht hinreichend geschützt. Mit einer entsprechenden Endpoint Protection Lösung – sprich Application Whitelisting und Application Behavior Control – wären die Angreifer gar nicht weit gekommen.
Unsere Techniker haben sich dazu Gedanken gemacht und nützliche Informationen unten zusammengefasst – „bei riskantem Verhalten coachen“.
Beim letzten Mal hatte ich geschlossen mit „Die nächste Sicherheitslücke kommt bestimmt. … Applikationskontrolle mit Application Whitelisting verhindert solche Worst Case-Szenarien.“ Das gilt unverändert.
Was ist Log4j?
Log4j steht für Logging for Java und ist eine Protokollierungsbibliothek für Anwendungen, die in Java geschrieben sind. Die Bibliothek erlaubt Java-Anwendungen bei deren Ausführung Anwendungsmeldungen und Fehler in ein Logfile zu schreiben. Sie ist sehr weit verbreitet.
Wo wird log4j eingesetzt und was ist alles betroffen?
Log4j wird in allen Betriebssystemen eingesetzt. Betroffen sind Client-Server Architekturen, die von außen so beeinflusst werden können, dass ein benutzerdefinierter Text in das Logfile geschrieben wird. Zum Beispiel könnte das der Benutzername in einer Login-Maske einer Server-Anwendung sein. Log4j steckt auch in vielen Netzwerk- und Systemkomponenten.
Wenn Sie wissen möchten, welche Anwendungen betroffen sind, können Sie sich im Internet informieren, z.B. in dieser Liste: https://github.com/authomize/Log4j-log4shell-affected
Welche Gefahr geht von der bekannt gewordenen Schwachstelle Log4Shell aus?
In der zugrundeliegenden Log4j-Funktionalität wurde eine Schwachstelle mit dem Namen CVE-2021-44228 entdeckt, die Log4Shell genannt wird. Angreifer erhalten durch das Ausnutzen der Lücke die Möglichkeit, beliebigen Java Code nachzuladen und damit Schadcode auszuführen. Da es keinen einheitlichen Patch geben kann und die Lücke bereits aktiv ausgenutzt wird, gilt sie als klassischer Zero Day-Exploit. Typische, sich daraus ergebende Angriffszwecke könnten Ransomware-Attacken sein, bei denen Daten gegen Lösegeld verschlüsselt werden. Ebenso könnte der befallene Rechner in ein Bot-Netz integriert werden oder zum Schürfen von Kryptowährungen missbraucht werden.
Was müssen Unternehmen jetzt tun?
Oberste Priorität ist zu prüfen, welche Komponenten im Unternehmen überhaupt betroffen sind. Hier sollten Unternehmen auf jeden Fall die Information der Softwarehersteller zur Log4j-Sicherheitslücke konsultieren und alle verfügbaren Patches sofort einspielen. Fangen Sie mit den Systemen an, die aus dem Internet erreichbar sind!
Welche Vorkehrungen könnten Unternehmen zukünftig treffen?
Die Log4j Sicherheitslücke unterscheidet sich von anderen Sicherheitslücken dadurch, dass es sich hier nicht um einen Fehler in der Software handelt - denn alles funktioniert genauso wie spezifiziert. Insofern kann man hier von einem kollektiven Versagen sprechen. Weder den Entwicklern, noch den Anwendern der Bibliothek war die Ausnutzbarkeit dieses Features bewusst.
Ein präventiver Schutz gegen derartige Fehler ist prinzipiell nicht möglich. Jedoch kann der mögliche Schaden durch Endpoint Protection Software – in diesem Fall Application Whitelisting – zum großen Teil eingedämmt werden. Klassische Antivirus-Software wird in diesem Fall in der Regel nicht ausreichen, um die speziell für das Opfer erstellte Malware zu erkennen und zu stoppen.
Was verhindert Endpoint Protection?
Die grundsätzliche Schwierigkeit bei der Verhinderung von Cyberangriffen besteht darin, dass der potenziell Betroffene erst nach dem Angriff weiß, wie dieser genau aussieht. Es genügt nicht, sich auf einen bestimmten Angriff vorzubereiten. Es müssen allgemeine Schutzmaßnahmen ergriffen werden, die Cyberangriffen die Grundlage entziehen.
Eine wichtige Schutzmaßnahme besteht dabei darin, einzuschränken, wie eine Software kommunizieren kann. Schon wenige einfache Firewall-Regeln stellen sicher, dass ein Programm nur mit den Computern kommunizieren kann, mit denen es kommunizieren soll.
Auf ähnliche Weise sorgt Application Whitelisting dafür, dass nur bestimmte Anwendungen überhaupt ausgeführt werden dürfen. Die von den Tätern eingeschleuste Malware oder Ransomware ist nicht dabei. Bei DriveLock reichen hier – wie bei der Firewall – schon wenige Regeln, um die Sicherheit zu gewährleisten.
Darüber hinaus sorgt Anwendungsverhaltenskontrolle (Application Behavior Control) dafür, dass eine Anwendung – auch wenn sie bereits übernommen wurde – keine schädlichen Aktionen ausführen kann, wie beispielsweise der Zugriff auf Dateien oder der Start anderer Programme. Application Behavior Control folgt wie bei einer Firewall dem Ansatz, einem Programm das zu erlauben was es braucht und alles andere zu verbieten, und ist somit die dritte Schutzebene im beschriebenen Beispiel. Nur mit mehreren, aufeinander abgestimmten Schutzebenen werden solche Angriffe sicher verhindert.
Achtung vor SPAM-Mails - Security Awareness stärken
Aufmerksamkeitsstarke Themen wie Log4j bringen gerne Trittbrettfahrer auf die Spur, die mit SPAM-Mails das Informationsbedürfnis zum Thema ausnutzen, um mit angeblichen nützlichen Informationen bzgl. Log4j bzw. Log4Shell zu helfen. Diese dienen oftmals dem Zweck des Phishings. Eine regelmäßige Schulung aller Mitarbeiter zu diesem Thema, zum Beispiel über das DriveLock Security Awareness Modul, sorgt dafür, das das entsprechende Wissen vorhanden ist, auf solche SPAM-Mails nicht hereinzufallen.
DriveLock
