Das BSI nutzt die eigene vierstufige Skala für Cyber-Sicherheitswarnungen voll aus und hebt als aktuell einziges Produkt die Java-Bibliothek Log4j auf die höchste Warnstufe. Die Einschätzung beruhe auf der sehr weiten Verbreitung dieses Software-Elements und den damit verbundenen Auswirkungen auf unzählige weitere Produkte, teilte das BSI mit. Zudem könne die Schwachstelle relativ einfach ausgenutzt werden.

„Aktuell ist noch nicht bekannt, in welchen Produkten diese Bibliothek eingesetzt wird, was dazu führt, dass zum jetzigen Zeitpunkt noch nicht abgeschätzt werden kann, welche Produkte von der Schwachstelle betroffen sind“, teilte das BSI mit. Providern empfiehlt die Behörde: „Sofern die Hersteller Updates zur Verfügung stellen, sollten diese umgehend installiert werden“.

Sicherheitsexperten sehen in der Lücke vor allem perspektivisch eine Gefahr. So könnten böswillige Akteure Hintertüren in betroffene Systeme einbauen, um diese zu einem späteren Zeitpunkt zu übernehmen. Diese Übernahmen könnten erst Monate später erfolgen, wenn sie nicht mehr akut mit der Lücke in Verbindung gebracht würden.

Aktuell sei ein Wettlauf zwischen Hackern und Admins zu beobachten, erklärt Rüdiger Trost von der IT-Sicherheitsfirma F-Secure. Beide Seiten würden mit automatisierten Massenscans nach anfälligen Servern suchen. Noch sei gar nicht klar, wie verbreitet das Problem tatsächlich ist.

Dabei gibt es bereits ein Sicherheits-Update für die Java-Bibliothek Log4j. Das Problem ist nun, die Produkte zu identifizieren, die Log4j einsetzen. Denn die müssen individuell angepasst werden. Im Kern ist Log4j eine sogenannte Logging-Bibliothek. Sie wird eingesetzt, um im Server-Betrieb auftretende Ereignisse zu protokollieren. Das erleichtert etwa eine spätere Fehlersuche.

Die nun gefundene Sicherheitslücke kann völlig simpel dadurch aktiviert werden, dass eine ganz bestimmte Zeichenfolge in das Log gespeichert wird. Diese sehr geringe Hürde besorgt Experten und dürfte der bestimmende Grund für die Einstufung des BSI sein.

Zuerst betroffen waren Server des Online-Spiels „Minecraft“, bei denen das Problem am Donnerstag aufgefallen war. Aber das Problem ist viel größer. Die Bibliothek kommt in zahllosen Web-Anwendungen zum Einsatz, Schätzungen zufolge wird Log4j in 95 Prozent aller Java-Projekte verwendet. Den genauen Ablauf des Angriffs erläutert t3n-Entwicklungsredakteurin Kathrin Stoll hier.

Dabei zeigte sich recht schnell, dass sich das Problem nicht auf Web-Apps und reine Java-Anwendungen beschränkte. Betroffen ist offenbar jede Anwendung, die auf die Jogging-Bibliothek zurückgreift – und wenn es nur im Wege einer Abhängigkeit ist. Der CDN-Dienstleister Cloudflare stellte bei einem vollständigen Scan seiner Java Virtual Machines fest, dass seine Instanzen von „Elasticsearch, Logstash und Bitbucket“ verwundbar gewesen seien. Cloudflare hatte zudem schnell reagiert und für seine Kunden einen Mechanismus eingebaut, der Angriffe blockieren soll, dabei aber betont, dass sogar ein QR-Scanner oder ein kontaktloses Türschloss angegriffen werden könnten, wenn sie Java und Log4j benutzten.

Inzwischen wird Unmut darüber laut, dass eine so vitale Bibliothek ganz offenbar von zwei Entwicklern betreut wird, deren Arbeit ausschließlich per Github-Sponsoring honoriert wird. Das räumt die Apache-Foundation selbst ein.

Ralph Goers ist einer der beiden Entwickler. Er schreibt auf seiner Sponsorseite auf Github:

„Ich habe derzeit einen Vollzeitjob als Softwarearchitekt. In meiner Freizeit arbeite ich an Log4j und anderen Open-Source-Projekten und beschäftige mich daher mit den Themen, die mich am meisten interessieren. Ich habe schon immer davon geträumt, hauptberuflich an Open Source zu arbeiten und würde mich freuen, wenn Sie mich dabei unterstützen würden, dies zu ermöglichen.“

Mit bislang 46 Sponsoren, die zwischen fünf und maximal 50 US-Dollar pro Monat spenden, dürfte eine enthusiastische Betreuung nicht zu erwarten sein. Der zweite gelistete Entwickler, Gary Gregory, hat nicht einmal eine Sponsorseite. Er arbeitet hauptberuflich als Manager bei Rocket Software und listet auf seiner privaten Website ein halbes Dutzend Open-Source-Projekte, zu denen er beiträgt.

Damit dürfte eine zeitnahe und sorgfältige Pflege der Bibliothek in keinster Weise sichergestellt zu sein. Ähnliche Auswirkungen hatte eine mangelhafte Pflege zuletzt im Kontext der Heartbleed-Lücke in OpenSSL vor einigen Jahren gezeigt. Vorwürfe müssen sich natürlich auch kommerzielle Anbieter machen lassen, die ihre Lösungen auf kostenloser Software gründen, ohne zu deren Fundament beizutragen.