Ein Leck in der weit verbreiteten Logging-Bibliothek Log4j – es wurde "Log4Shell" genannt – hält IT-Sicherheitsexperten auf Trab. Es handelt sich um eine der schwersten Lücken seit Jahrzehnten. Sie bietet riesiges Schadpotenzial, ist relativ simpel ausnutzbar und hat nicht umsonst die maximale Bewertung von zehn Punkten im standardisierten Einstufungssystem für Software-Schwachstellen (CVSS) erhalten.

Der sprichwörtliche Hut brennt allerdings auch, weil die Behebung alles andere als einfach ist. Theoretisch lassen sich diese und weitere seitdem aufgetauchte Lücken mit einem Update von Log4j beheben. Praktisch gestaltet sich das allerdings kompliziert, da Log4j keine eigenständige, zentral laufende Applikation ist. Es handelt sich um eine Komponente, die in einzelne Programme eingebaut wird. Und jedes dieser Programme muss nun identifiziert und eine sichere Version von Log4j eingepflegt werden.

Das geht verhältnismäßig einfach, wenn man als Unternehmen eine Software selbst entwickelt. Bei Anwendungen von Drittherstellern ist man wiederum darauf angewiesen, dass diese eine Aktualisierung liefern.

Neues Einfallstor für Erpressungstrojaner

Die Ende November entdeckte Lücke wird zumindest seit Anfang Dezember bereits ausgenutzt. Möglicherweise aber schon länger, denn die erste betroffene Log4j-Version erschien bereits im September 2013. Die Security-Firma Checkpoint Security ermittelte alleine zwischen 10. und 15. Dezember 1,8 Millionen versuchte Angriffe auf Log4Shell. Mit dabei mutmaßlich von ihren Regierungen finanzierte Hackergruppen aus dem Iran und China.

IT-Experten warnen davor, dass die nächste Angriffswelle verheerend werden dürfte, berichtet nun Wired. Log4Shell droht zum Einfallstor für groß angelegte Ransomware-Attacken zu werden. Erste Anzeichen dafür gibt es bereits. Die bekannte Gruppierung Conti nutzt das Leck laut einem Bericht der Analysten von Advanced Intelligence bereits seit 13. Dezember, um seinen Erpressungstrojaner in fremde Systeme einzuschleusen.

Großer Behebungsaufwand

Die nun erwartete zweite Angriffsphase, funktioniert allerdings anders. Während größere und professionellere Gruppen ihre Attacken alleine abwickeln können, werden wohl bald via Log4Shell "eingerichtete" Zugänge auf einschlägigen Marktplätzen landen. Dort können dann Cyberkriminelle zuschlagen, die dort ihre Schadsoftware ausbringen oder spionieren möchten.

Daraus ergibt sich ein weiteres Problem. Selbst dort, wo von Log4Shell betroffene Applikationen bereits gepatcht wurden, könnten sich Angreifer bereits tiefer im System eingenistet haben. Den IT-Verantwortlichen in Firmen und Organisationen bleibt also wenig anderes übrig, als nach möglichen Anzeichen einer Kompromittierung zu fahnden und die Augen nach verdächtigen Aktivitäten offen zu halten. Während große Konzerne die Mittel dafür aufbringen können, sich gut gegen solche Eventualitäten abzusichern, könnte das für kleinere Unternehmen eine ziemliche Herausforderung werden.

Mehr Geld für Open Source?

Es stellt sich auch die Frage, wie ein solcher Worst Case in Zukunft verhindert werden kann. Log4j ist nur ein Stück quelloffener Software, die vielfach eingesetzt wird und bei der ein schweres Sicherheitsleck viele Millionen Nutzer direkt oder indirekt betreffen kann. Der Vorteil von Open Source liegt auch darin, dass der Code der Programme für jeden einsehbar ist, was die Wahrscheinlichkeit erhöht, dass Probleme schnell gefunden werden.

Aber es ist keine Garantie dafür, denn letztlich hängt es auch davon ab, wie aktiv ein Projekt gepflegt wird – also wie viele Entwickler wie viel Zeit in Weiterentwicklung und Sichtung stecken. Die Entwicklung von Log4j wird von Ralph Goers als Freizeitprojekt geleitet. Lediglich drei Leute leisteten ihm zum Zeitpunkt des Bekanntwerdens der Lücke als freiwillige Sponsoren einen kleinen finanziellen Ausgleich. Bei manch anderer gern genutzter Open-Source-Software dürfte es ähnlich aussehen.

Dementsprechend wurden Forderungen laut, mehr Geld für solche Projekte aufzustellen, damit ihre Pflege als bezahlte Arbeit und nicht nur als Hobby möglich wird. Es gibt aber Zweifel, dass das Problem sich rein auf monetärem Wege beheben lässt. Clay Shafer von Red Hat denkt, dass mehr Finanzmittel nur zu vernachlässigbaren Verbesserungen führen würden. Er argumentiert das damit, dass selbst Banken, die riesige Geldmengen in ihre IT stecken würden, sich trotzdem immer wieder mit Lücken herumschlagen müssen.

Stücklisten für Software

Eine andere Idee kommt unter anderem von der US-Cybersicherheitsbehörde CISA. Sie argumentiert für die Etablierung einer "Software Bill of Materials" (SBOM), also einer "Stückliste", vergleichbar mit der Aufschlüsselung der Komponenten bei der Herstellung von Elektronik. Anders gesagt soll bei der Veröffentlichung von Software transparent gemacht werden, welche Komponenten in diese integriert sind. So ließe sich bei Fällen wie Log4Shell schnell ermitteln, welche Applikationen und Geräte betroffen sind, was Zeit und Geld spart.

Das Konzept ist nicht neu. Codehosting-Plattformen wie Github bieten entsprechende Features an. Diese Dokumentation ist allerdings nicht verpflichtend. Ihr Einsatz ist aber nicht nur aus genannten Gründen sinnvoll, sondern erleichtert auch die Arbeit bei der Weiterentwicklung von Software sowie den Einstieg von neuen Programmierern, die mit dem Projekt noch nicht vertraut sind.

Die potenziell riesige Tragweite von Log4Shell wird sich erst in den kommenden Monaten zeigen. Die Lücke dürfte die IT-Welt, so schätzt der Softwarehersteller Dynatrace gegenüber dem STANDARD, noch über Jahre hinweg beschäftigen. (gpi, 20.12.2021)