Deshalb ist Log4Shell brisant

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.