Seit Anfang Woche warnt das Nationale Zentrum für Cybersicherheit (NCSC) vor der offenbar verheerenden Zero-Day-Lücke «Log4Shell» in der weit verbreiteten Java-Bibliothek «Log4J». Zuvor hatte das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) seinerseits sogar die höchste Warnstufe Rot ausgerufen, was nicht oft passiert.

Der Alarmismus ist offenbar berechtigt. Denn die Lücke wird bereits fleissig von Cyberkriminellen für Angriffe ausgenutzt. Dies berichten zumindest die Sicherheitsforscher von Check Point Research (CPR), der Forschungsabteilung von Check Point Software Technologies, in aktuellen Blog-Beiträgen.

So sind gemäss CPR in der Schweiz 40 Prozent aller von Check Point erfassten Firmen-Netzwerke bereits attackiert worden. Damit liegt unser Land genau im globalen Durchschnitt. Heftiger betroffen sind dagegen die Nachbarländer Deutschland und Österreich. Hier wurden bereits 45 Prozent respektive 46 Prozent aller Netze angegriffen.

Tatsächlich beobachtete CPR einen wahren Angriffs-Tsunami. Bereits 72 Stunden nach Bekanntwerden der ersten Angriffsversuche registrierte CPR 830'000 Attacken. Zudem stellen die Sicherheitsforscher ständig neue Exploit-Varianten fest. So zählte CPR nach 72 Stunden bereits 45 Angriffsvariationen und rechnet damit, dass mittlerweile 60 Varianten kursieren dürften.

«Es handelt sich um eine der schwerwiegendsten Sicherheitslücken der letzten Jahre, die sich wie ein Lauffeuer verbreitet», meint Lotem Finkelstein, Head of Threat Intelligence bei Check Point Software. «Zu einem bestimmten Zeitpunkt gab es über 100 Attacken in der Minute im Zusammenhang mit der Log4J-Schwachstelle», berichtet er weiter.

Zudem scheine es sich um eine evolutionäre Kampagne zu handeln, da in kürzester Zeit neue Varianten der ursprünglichen Attacke eingeführt wurden – über 60 an der Zahl. «Diese Vielfalt der Kombinationen, wie die Schwachstelle ausgenutzt werden kann, gibt dem Angreifer viele Möglichkeiten, neu eingeführte Schutzmassnahmen zu umgehen», gibt Finkelstein zu bedenken. Das bedeute, dass eine Schutzschicht nicht ausreiche und nur eine mehrschichtige Sicherheitsarchitektur eine widerstandsfähige Abwehr biete, so seine Schlussfolgerung.

Die Log4Shell-Lücke ist deshalb so gefährlich, weil der fehlerhafte Code sich der Java-Bibliothek Log4J befindet, die von zahlreichen kommerziellen Softwarepaketen benutzt wird. Tatsächlich soll die Bibliothek eigentlich bei allen grossen IT-Firmen in der einen oder anderen Form im Einsatz sein, also bei Amazon, Cloudflare, Google, IBM, Tesla, und Twitter.

Sie wird dabei in Applikationen gerne verwendet, weil damit protokolliert werden kann, wer mit dem Programm arbeitet und wer auf welche Server zugreift. Durch diese Verwaltungsfunktionen ist Log4J quasi der Türsteher zu unzähligen Applikationen und Systemen. Wer diesen manipulieren und umgehen kann, erhält somit ungehindert Zugang.

CPR-Virenjäger Finkelstein bestätigt dies: «Im Gegensatz zu anderen grossen IT-Angriffen, die eine oder eine begrenzte Anzahl von Software betreffen, ist Log4J im Grunde in jedes Java-basierte Produkt oder jeden Java-basierten Web-Dienst eingebettet», erklärt er.

Es sei zudem sehr schwierig, sie manuell zu beheben. «Sobald eine Untersuchung veröffentlicht worden war (in diesem Fall am vergangenen Freitag), wurde das Internet durchforstet, um die durch diesen Vorfall verwundbaren Oberflächen zu bestimmen», führt er weiter aus.

Die Log4J-Bibliothek ist unter anderem auch deshalb weit verbreitet, weil sie quelloffen ist. So kann sie gratis bezogen und ohne Lizenzgebühren genutzt werden. Hieraus aber zu schliessen, dass Open-Source-Softwarekomponenten grundsätzlich schlecht oder zukünftig zu meiden seien, wäre ein Fehler. Vielmehr offenbare die Zero-Day-Sicherheitslücke in der Log4J-Java-Bibliothek ein grundsätzliches Problem von Dev-Ops-Prozessen in Unternehmen, gibt der Westschweizer IT-Sicherheits-Spezialist Kudelski Security zu bedenken. Die Firmen würden vielmehr noch zu wenig auf End-to-End-Security setzen etwa im Rahmen eines «Secure by Design»-Ansatzes, wird moniert.

«Das Hauptproblem ist nicht, dass die Log4j-Bibliothek aus einem Open-Source-Projekt stammt, das nur von einem oder zwei Programmierern als Teilzeitprojekt betrieben wird. In der Tat finden sich in kommerzieller Software ähnlich viele Zero-Day-Lücken wie in Open-Source-Lösungen. Das eigentliche Problem ist das mangelnde Sicherheitsbewusstsein der Programmierer und Unternehmen, das in vielen Fällen immer noch vorherrscht», findet Tony de Bos, Vice President for Services EMEA bei Kudelski Security.

Die Sicherheitslücke mache deutlich, dass Entwickler oft blindlings Bibliotheken verwendeten, ohne alle verfügbaren Optionen sorgfältig zu prüfen, fügt de Bos an. «Ein sicherheitsbewusster Entwickler hätte beim Lesen der Dokumentation wahrscheinlich die JNDI-Abfrage deaktiviert, wenn die Software diese Funktion nicht nutzt, und so die Angriffsfläche verringert», doppelt er nach. «Ich empfehle, dass Unternehmen idealerweise ein Repository von Bibliotheken unterhalten, die als Teil eines sicheren Dev-Ops-Prozesses und als Teil der grundlegenden IT-Sicherheitsstrategie des Unternehmens als sicher gelten. Zum Standard aller Entwicklungsprozesse gehört dann, dass die Programmierer alle in einem Softwareentwicklungsprojekt verwendeten Bibliotheken kontinuierlich auf ihre Zulässigkeit anhand dieses Repositorys überprüfen», rät de Bos folglich.

Bevor aber darüber sinniert wird, wie künftig Lücken vom Schlage einer Log4Shell verhindert werden können, dürfte es betroffene und bedrohte Firmen eher interessieren, welche Gegenmassnahmen derzeit zu ergreifen sind.

Generell muss die Sicherheitslücke schnell geschlossen werden. Das bedeutet, dass die Hersteller von Softwareprodukten, die die Bibliothek Log4j verwenden, schnell Sicherheitsupdates ihrer Applikationen und Dienste herausgeben müssen. In vielen Fällen ist dies schon passiert, oder die Hersteller arbeiten noch fieberhaft an Updates.

Einen sehr guten Leitfaden, wie auf Log4Shell zu reagieren ist, hat übrigens das Swiss Government Computer Emergency Response Team, das beim NCSC angesiedelt ist, herausgegeben. Das helvetische CERT zeigt hier nicht nur eine Liste von empfohlenen Aktionen auf, es hat auch die Angriffsmöglichkeiten über die Schwachstelle gut visualisiert (siehe Grafik).

Eine schnelle Abhilfe ist allerdings nicht in Aussicht. «Sicher ist: Diese Schwachstelle wird uns aufgrund der Komplexität ihrer Behebung und der Einfachheit, mit der sie ausgenutzt werden kann, jahrelang begleiten», glaubt Finkelstein von CPR.

«Es sei denn, Unternehmen und Dienste ergreifen sofort Massnahmen, um Angriffe auf ihre Produkte durch die Implementierung eines wirksamen Schutzes zu verhindern. Besonders in der Urlaubszeit, wenn IT-Sicherheitsabteilungen langsamer arbeiten, ist das wichtig», fügt er an.