Lernen aus dem Log4j-Brand
Mo, 13. Dezember 2021, Ralf Hersel
Hinweis: Das ist ein Meinungsartikel.
Ihr habt es gelesen: Eine kritische Schwachstelle in der weit verbreiteten Java-Bibliothek Log4j führt nach Einschätzung des Bundesamts für Sicherheit in der Informationstechnik (BSI) zu einer extrem kritischen Bedrohungslage. Das BSI hat daher seine bestehende Cyber-Sicherheitswarnung auf die Warnstufe Rot hochgestuft. Ursächlich für diese Einschätzung ist die sehr weite Verbreitung des betroffenen Produkts und die damit verbundenen Auswirkungen auf unzählige weitere Produkte. Die Schwachstelle ist zudem trivial ausnutzbar, ein Proof-of-Concept ist öffentlich verfügbar. Eine erfolgreiche Ausnutzung der Schwachstelle ermöglicht eine vollständige Übernahme des betroffenen Systems. Dem BSI sind welt- und deutschlandweite Massen-Scans sowie versuchte Kompromittierungen bekannt. Auch erste erfolgreiche Kompromittierungen werden öffentlich gemeldet.
Die Schwachstelle wurde mindestens seit dem 1. Dezember 2021 aktiv ausgenutzt. Am 6. Dezember wurde die Lücke mit Version 2.15.0 von Log4j geschlossen. Wie lange es dauern wird, bis alle Diensteanbieter ihre Systeme aktualisiert haben, ist nicht bekannt. Die Liste der betroffenen Diensteanbieter ist lang, sehr lang.
Die eigentliche Schwachstelle besteht meiner Meinung nach nicht in der Reaktion des Projektteams, sondern in der Tatsache, dass es viele systemkritische Open-Source-Programme gibt, deren Projekte nicht darauf ausgelegt sind, schnell und umfassend auf Bedrohungen zu reagieren. Oft handelt es sich um einige wenige Mitarbeitende, die eine wichtige Komponente in ihrer Freizeit unentgeltlich pflegen.
Bildquelle: xkcd
Open-Source-Software wie Log4j oder GnuPG und viele weitere werden von kleinen Programmierer-Teams entworfen und gepflegt, die dafür meist nicht bezahlt werden. Solche Komponenten werden gerne als kostengünstige Lösung von grossen Unternehmen, Organisationen und Behörden übernommen, nicht zuletzt, weil sie als de-facto Standard gelten.
Für solche kritischen, aber unzureichend ausgestatteten Projekte wird ein Sovereign Tech Fund benötigt, der mehrere Aufgaben erfüllen könnte:
- Identifikation der systemkritischen FLOSS-Komponenten
- Einzug von Unterstützungsleistungen von Unternehmen, Organisationen und Behörden
- Sicherstellen der professionellen Weiterentwicklung und Wartung dieser Komponenten
Quellen:
https://logging.apache.org/log4j/2.x/changes-report.html#a2.15.0
https://github.com/apache/logging-log4j2
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
