Log4j-Sicherheitslücke Wie löscht man ein brennendes Internet?

IT-Fachleute sind wegen der Log4j-Sicherheitslücke alarmiert, erste Angriffe laufen bereits. Welche Folgen hat das für Nutzer? Wie ließe sich so etwas verhindern? Antworten auf die wichtigsten Fragen.
Mainboard (Symbolbild): »Es werden jetzt so viele Hintertüren aufgemacht wie möglich«

Mainboard (Symbolbild): »Es werden jetzt so viele Hintertüren aufgemacht wie möglich«

Foto: Songsak Paname / iStockphoto / Getty Images

Dieser Artikel gehört zum Angebot von SPIEGEL+. Sie können ihn auch ohne Abonnement lesen, weil er Ihnen geschenkt wurde.

Ein kleines Stück Software mit dem Namen Log4j ist für kriminelle Hacker zum möglichen Einfallstor in Computersysteme in aller Welt geworden: Am Freitag wurde eine trivial auszunutzende, aber schwerwiegende Sicherheitslücke in Log4j bekannt, seither liefern sich Angreifer und Verteidiger einen Wettlauf.

Die Liste derer, die Log4j einsetzen und damit potenzielle Ziele sind, ist lang und umfasst Unternehmen wie Apple, Google, Tesla und Amazon, aber auch mehrere deutsche Bundesbehörden. »Das Internet steht gerade in Flammen«, fasste es Adam Meyers von der IT-Sicherheitsfirma CrowdStrike zusammen.

Die wichtigsten Fragen und Antworten dazu im Überblick:

Was ist dieses Log4j überhaupt?

Das hauptsächlich von zwei Freiwilligen gepflegte Open-Source-Werkzeug wird benutzt, um zu protokollieren, was innerhalb einer Java-Anwendung passiert. Vereinfacht gesagt: IT-Abteilungen beobachten mithilfe von Log4j, was in verschiedenen auf der Java-Technik basierenden Programmen auf ihren Servern passiert, um zum Beispiel Fehler zu identifizieren. Die Version 1.0 wurde vor knapp 21 Jahren  veröffentlicht, seither ist Log4j zu einem De-facto-Standard für diese »Logging« genannte Beobachtung geworden.

Was ist die nun entdeckte Schwachstelle?

Bestimmte Zeichenfolgen werden von Log4j sozusagen durchgewunken. Sie können Befehle enthalten, die dann auf dem Server ausgeführt werden. Das ermöglicht dem Angreifer, den Server aus der Ferne zu übernehmen. Im Extremfall genügte es, die Zeichenkette in ein Chatfenster im Spiel »Minecraft« einzugeben, um sich in den jeweiligen Server zu hacken.

Das Ganze ist so einfach, dass das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Warnstufe Rot ausgerufen hat, für eine »extrem kritische IT-Sicherheitslage«, denn »diese kritische Schwachstelle hat demnach möglicherweise Auswirkungen auf alle aus dem Internet erreichbaren Java-Anwendungen, die mithilfe von Log4j Teile der Nutzeranfragen protokollieren«. Die Schwachstelle selbst wird Log4shell genannt.

Was können User tun, und was müssen sie befürchten?

Die kurze Antwort: wenig und vieles. Die etwas längere: Die US-Cybersicherheitsbehörde CISA warnt, dass möglicherweise auch Geräte von Endnutzerinnen und -nutzern wie zum Beispiel Router verwundbar sein könnten. Details dazu wurden nicht genannt, daher ist zunächst unklar, ob es für diese Geräte Updates geben wird und wenn ja, ob Verbraucherinnen und Verbraucher sie selbst einspielen können und sollten. Die meiste Arbeit haben mit Log4shell die IT-Abteilungen in Unternehmen und Behörden.

Aber die Auswirkungen erfolgreicher Server-Kompromittierungen oder auch nur notwendiger Vorsichtsmaßnahmen könnten sehr viele Menschen zu spüren bekommen. Sei es, weil eine Behörde bestimmte Online-Services vorübergehend abschaltet oder weil jemand einen Unternehmensserver kapert und dort gespeicherte Daten abgreift, von dort aus Schadsoftware verteilt oder sich tiefer in das Netzwerk der betroffenen Einrichtung vorarbeitet, um dieses irgendwann mit einer Ransomware lahmzulegen. Erste Beispiele für Auswirkungen auf den Alltag der Menschen gibt es bereits. So mussten Teile der Telematikinfrastruktur vom Netz genommen werden , »zum Schutz von Patientendaten«. Patienten und Praxen könnten daher derzeit Probleme mit den Krankenversichertenkarten haben.

Was muss in den IT-Abteilungen von Unternehmen und Behörden passieren?

Das BSI empfiehlt hier  unter anderem dringend eine Bestandsaufnahme, welche Systeme Log4j nutzen, die Abschaltung nicht zwingend benötigter verwundbarer Systeme, ein Update von Log4j auf die aktuelle Version 2.15.0 beziehungsweise die Änderung bestimmter Einstellungen dort, wo ein Update nicht ohne Weiteres möglich ist. Und für den Fall der Fälle »die Protokollierung aller eingehenden und ausgehenden Verbindungen, um im Nachgang eine Kompromittierung leichter feststellen zu können«.

Welche Angriffe finden bereits statt?

Bisher weiß das BSI von Berichten »über weltweite Massenscans und versuchte Kompromittierungen. Es gibt bereits erste Meldungen über erfolgreiche Kompromittierungen (bislang unter anderem mit Kryptominer).« Übersetzt: Angreifer durchsuchen das Internet automatisiert und großflächig nach Servern und Anwendungen, die Log4j benutzen und verwundbar sind. Die ersten erkannten Angriffe bestanden darin, dass auf einem Server ein Programm installiert wurde, das sich die Rechenleistung des Servers zunutze macht, um Kryptowährungen zu schürfen. F-Secure hat mittlerweile aber auch schon Ransomware-Angriffe über Log4shell beobachtet.

Rüdiger Trost von F-Secure zufolge werden raffiniertere Täter aber nicht direkt zuschlagen, sondern die Sicherheitslücke nur zur Vorbereitung des eigentlichen Angriffs nutzen. Sie könnten versuchen, sich auf einem Server unbemerkt einzunisten, sich von dort vorzuarbeiten und die Kontrolle über größere Teile eines Netzwerks zu übernehmen.

Weil professionelle Täter ihre Ziele aus so einer Position heraus mitunter monatelang beobachten, wird der tatsächliche Schaden durch Log4j auch erst viel später erkennbar sein. »Es werden jetzt so viele Hintertüren aufgemacht wie möglich«, vermutet Trost im Telefonat mit dem SPIEGEL. Er rechnet zudem damit, dass jemand einen Wurm entwickeln wird, der sich über die Lücke von selbst verbreitet, zum Beispiel für den Aufbau eines Botnetzes. F-Secure, sagt er, muss auch bereits zur Incidence Response ausrücken, bestimmte Kunden wurden also schon angegriffen und können das allein nicht mehr bewältigen.

Ist so etwas zum ersten Mal passiert?

Nein, 2014 gab es eine Art Präzedenzfall, der unter dem Namen Heartbleed bekannt wurde. Auch da war es eine erst nach 27 Monaten entdeckte Schwachstelle in der weitverbreiteten Open-Source-Softwarekomponente OpenSSL zur Absicherung von Internetverbindungen, die Millionen von Webservern betraf. Ein deutscher Student hatte den entsprechenden Code geschrieben, bei der Abnahme fiel der Fehler nicht auf – damit war er nach dem nächsten Update von OpenSSL in der Welt.

Wo liegt das grundsätzliche Problem?

Vorneweg: Open-Source-Software ist an sich kein Problem, im Gegenteil. Liegt der Quellcode offen, können Fachleute ihn überprüfen und Fehler melden. Das ist bei proprietärer Software, deren Code nicht ohne Weiteres einsehbar ist, schwieriger. Aber Open-Source-Projekte werden häufig von Freiwilligen übernommen und mitunter nur in deren Freizeit gepflegt. Im besten Fall bekommen die Freiwilligen hin und wieder Spenden, aber die entsprechen selten dem Anspruch an ihre Arbeit und dem Aufwand. Menschliche Fehler wie im Fall von Log4j oder OpenSSL rutschen deshalb eher mal durch. Es fehlen die professionellen Strukturen von Unternehmen, in denen unter anderem Sicherheitschecks regelmäßig und nach bestimmten Vorgaben durchgeführt werden, weil es dafür eigens vorgesehenes Personal gibt.

Wie ließe es sich lösen?

»Open-Source-Software ist die Grundlage des Internets und damit der gesamten Wirtschaft«, schreibt der Google-Ingenieur Filippo Valsorda in einem Blogpost zum Fall Log4j . Aber die Pflege der vielen Open-Source-Projekte sei nie so professionalisiert worden, dass sie den Ansprüchen der Wirtschaft und aller anderen Organisationen, die darauf vertrauen, gerecht werden könnte. In einem in diesen Kreisen berühmten »xkcd«-Comicstrip  heißt es, die gesamte digitale Infrastruktur hänge ab von »irgendeiner Person in Nebraska, die seit 2003 ein Projekt am Leben erhält, ohne dass es ihr jemand danken würde«.

Filippo Valsorda schlägt daher vor, dass Unternehmen Verträge mit den Open-Source-Entwicklern abschließen sollten, auf deren Arbeit sie angewiesen sind, damit diese ihre Arbeit in Rechnung stellen können.

Eine Alternative wäre staatliche Unterstützung. Auf EU-Ebene gab es das bereits 2015, auf den Vorschlag der damaligen EU-Abgeordneten Julia Reda und eines schwedischen Kollegen hin. Das Projekt Fossa  schuf ein Bug-Bounty-Programm, in dessen Rahmen die EU-Kommission Sicherheitsforscherinnen und -forscher dafür bezahlte, Schwachstellen in jener Open-Source-Software auszubügeln, die auch die Kommission selbst benutzt. Das Projekt ist 2020 ausgelaufen , ein ähnlich gelagertes Projekt namens Fosseps wurde vor einigen Tagen vorgestellt .

Reda hat derweil mit der Open Knowledge Foundation eine Machbarkeitsstudie für das Bundeswirtschaftsministerium  erstellt, in der es um die gezielte Förderung von Open-Source-Projekten durch einen »Sovereign Tech Fund« geht. Die Leitfrage, sagt Reda dem SPIEGEL, sei gewesen: »Wie müsste ein öffentliches Förderinstrument aussehen, um diese Basistechnologien, die überall genutzt werden, zu unterstützen?« Denkbar sei zum Beispiel, Unternehmen eine staatliche Förderung zuzusprechen, wenn sie ihre Angestellten während der Arbeitszeit an Open-Source-Software arbeiten ließen.

Alternativ sollen sich Einzelpersonen oder kleine Teams »niedrigschwellig« für eine Förderung bewerben können. Die dritte Säule sei praktische Unterstützung von Entwicklerinnen und Entwicklern, etwa durch die Veranstaltung von Workshops zu einzelnen Aspekten der Software-Entwicklung. Im Koalitionsvertrag erkennt Reda »positive Signale, dass das in Deutschland umgesetzt werden kann«.

Hinweis: In einer früheren Fassung dieses Artikels hieß es, die allermeisten Endnutzerinnen und -nutzer könnten nichts tun, weil Log4j nicht auf ihren Smartphones und Computern läuft. Die Passage wurde überarbeitet.

Die Wiedergabe wurde unterbrochen.