Java-Lücke

Log4j – ist Open Source das Problem?

Sicherheitsexperten sind sich einig, dass die Auswirkungen der Log4j-Schwachstelle noch länger anhalten dürften. Doch beim Thema Open Source gehen die Meinungen auseinander.
Von Michael Cooney und
CSO | 14. Februar 2022 05:08 Uhr
Die Java-Sicherheitslücke Log4j wird die Security-Szene weiterhin beschäftigen.
Die Java-Sicherheitslücke Log4j wird die Security-Szene weiterhin beschäftigen.
Foto: Robert Kneschke - shutterstock.com

Die Behebung des Log4j-Fehlers und seiner Auswirkungen wird noch eine ganze Weile andauern. Die Sicherheitsforscher von Cisco Talos gehen davon aus, dass die Sicherheitslücke in nächster Zeit in großem Umfang ausgenutzt werden dürfte. Anwendern wird dringend empfohlen, Patches und angepasste Sicherheitslösungen so schnell wie möglich einzuspielen beziehungsweise zu nutzen.

Die populäre Java-Logging-Software wird häufig als einfach zu nutzende Utility beim Entwickeln von Client-Server-Anwendungen unterschiedlichster Art eingesetzt. Mit der Log4j-Schwachstelle besteht das Risiko, dass ein nicht authentifizierter Akteur die Kontrolle über ein betroffenes Serversystem übernimmt. Er kann sich Zugang zu Unternehmensdaten verschaffen oder einen Denial-of-Service-Angriff starten.

Log4j: Das sagen Security-Experten

Mit dem Thema Log4j hat sich auch der US-Senat beschäftigt, genauer genommen das Committee on Homeland Security & Government Affairs. Es befragte Experten, um herauszufinden, wie Unternehmen reagieren sollten und wie sich künftige Software-Sicherheitslücken dieser Art verhindern lassen. Da Log4j auch in verschiedenen Open-Source-Produkten enthalten ist, wurde auch die Verwendung von Open-Source-Software in kritischen Plattformen diskutiert.

"Die Schwachstelle in Log4j, die schon durch die Eingabe von nur zwölf Zeichen ausgenutzt werden kann, ist ein Beispiel dafür, wie weit verbreitete Softwarefehler - auch die in Open-Source-Code - eine ernsthafte Bedrohung für die nationale und wirtschaftliche Sicherheit darstellen können", sagte der Ausschussvorsitzende Senator Gary Peters. Gemessen an der Anzahl der gefährdeten Online-Dienste, Websites und Geräte, seien die potenziellen Auswirkungen dieser Schwachstelle unermesslich, so Peters. Alle kritischen Infrastrukturen wie Banken, Stromnetze und Regierungsbehörden seien dadurch anfälliger für Netzwerkangriffe geworden.

Ganz anderer Meinung war indes Brad Arkin, Senior Vice President und Chief Security Officer von Cisco: "Ich bin nicht der Meinung, dass Open-Source-Software hier versagt hat. Es ist ein Irrtum zu glauben, dass die Log4j-Schwachstelle einen Beweis für (…) ein erhöhtes Risiko bei Open-Source-Software darstellt." Es sei nun einmal eine Tatsache, dass jede Software Schwachstellen enthalte. Grund dafür sei das naturgemäß eingeschränkte Urteilsvermögen von Menschen, die diese Software designen, schreiben und integrieren müssten.

Cisco sei an verschiedenen Open-Source-Sicherheitsprojekten aktiv beteiligt und überzeugt davon. "Hier entstehen wichtige Bausteine, um die Integrität ganzer Codeblöcke zu erhalten, die in grundlegenden Elementen der IT-Infrastruktur gemeinsam genutzt werden", so Arkin. "Ich fürchte, dass eine Fokussierung auf die Risiken von Open-Source-Software uns von anderen wichtigen Bereichen ablenken könnte, in denen wir die Sicherheitsrisiken, die jeder Software innewohnen, angehen können."

Einen Fürsprecher fand der Cisco-CSO in Trey Herr, verantwortlich für die Cyber Statecraft Initiative beim Think Tank Atlantic Council. Open Source sei nicht das Problem. "Die Sicherheit in der Software-Lieferkette beschäftigt dagegen die weltweite Cybersicherheits-Community seit Jahren."

Er warnte davor, dass Log4j nur der Anfang sei, ähnliche Schwachstellen würden in Zukunft öfter auftauchen. "Log4j ist ein außerordentlich weit verbreitetes Logging-Programm und die Behebung der entsprechenden Schwachstellen kostet erhebliche Anstrengungen. Aber es wird nicht das letzte Mal sein, dass so ein Vorfall auftritt."

Herr empfahl der US-Regierung, für die Lösung des Problems Geld in die Hand zu nehmen. Es gehe darum, die Basisarbeiten zu finanzieren, Ressourcen dort bereitzustellen, wo die Industrie es nicht tue oder worauf das Augenmerk der Öffentlichkeit nicht gerichtet sei. Wichtig seien "strukturelle Verbesserungen bei der Sicherheit von Software-Lieferketten für alle Beteiligten". Für Herr ist die Sicherung der Software-Lieferketten und des breit verwendeten Open-Source-Codes in erster Linie ein Infrastrukturproblem, für das ein langfristiges Investitionsmodell hermüsse.

Log4j: Das sollten Sie beachten

Jen Miller-Osborn, stellvertretende Direktorin für Bedrohungsdaten bei den Sicherheitsforschern von Unit 42 bei Palo Alto Networks, empfahl als Reaktion auf Log4Shell und Prävention für künftige Schwachstellen folgende Maßnahmen zur Senkung der Risiken:

  • Damit US-Behörden ihr Schwachstellen-Management besser in den Griff bekommen, sollten sie die Verbreitung von Richtlinien für den Umgang damit weitgehend automatisieren. "Wir begrüßen es, dass das Department of Homeland Cybersecurity and Infrastructure Agency einen Katalog mit ausgenutzten Schwachstellen erstellt und pflegt. Es ist aber unwahrscheinlich, dass manuelles Reporting an mehr als 100 zivile Bundesbehörden den Gegnern einen Schritt voraus sind", sagte Miller-Osborn.

  • Eine branchenweite Übereinstimmung darin, bestimmte Sicherheitsmaßnahmen gemeinsam voranzutreiben, wäre wichtig. "Hier passiert bereits eine Menge, aber es wäre wichtig, dass die gängigen Entwicklungswerkzeuge für die Zugangskontrolle zu Open-Source-Komponenten noch intensiver eingesetzt würden. Diese Tools können alle Open-Source-Pakete sowohl auf Integrität als auch auf Sicherheit prüfen, bevor diese von den Entwicklungsteams für die Verwendung in Produkten bereitgestellt werden."

Cisco-Manager Arkin betonte, dass die Implementierung von Sicherheitsarchitekturen entscheidend sei, um Systeme stärker zu segmentieren. So ließen sich die negativen Auswirkungen von Schwachstellen eingrenzen, eine schnelle Wiederherstellung und langfristige Widerstandsfähigkeit werde ermöglicht.

"Eine angemessene Segmentierung erschwert es einem Angreifer, sich seitwärts durch das Netzwerk zu bewegen, selbst wenn er sich durch Ausnutzung einer Schwachstelle Zugang verschaffen kann", so Arkin. "Die Implementierung einer Zero-Trust-Umgebung schützt kritische Daten und Systeme zusätzlich vor Eindringlingen und Ausbeutung, indem sie sicherstellt, dass jeder Versuch, eine Verbindung zum Netzwerk herzustellen und auf wichtige Daten und Systeme zuzugreifen, überprüft wird."

Arkin und andere Experten begrüßten die präsidiale Anordnung an Industrie und Unternehmen, sicherer Softwareentwicklung den Vorzug zu geben und Zero-Trust-Netzwerke voranzutreiben. Unabhängig von der Frage, ob damit die Log4Shell-Schwachstelle hätte verhindert werden können, seien dies die richtigen Maßnahmen.

Das Problem des unvollkommenen Codes werde kaum verschwinden, sagte David Nalley, Präsident der Apache Software Foundation. "Die Realität ist, dass Menschen Software schreiben und dabei Fehler machen. Trotz aller Bemühungen werden einige dieser Fehler Sicherheitslücken schaffen. Da wir immer stärker vernetzt und digitalisiert sind, wird die Zahl der Schwachstellen und der möglichen Folgen wahrscheinlich noch zunehmen", warnte Nalley.

"Es gibt keine einfache Lösung für die Softwaresicherheit", sagte Nalley. Wichtig sei eine umfassende Verteidigungsstrategie. Dazu gehöre insbesondere die Upstream-Entwicklung in Open-Source-Projekten, die bei Patches die ursprünglichen Autoren und Betreuer der Software einbeziehe. Zudem müssten Softwarehersteller, die auf Open-Source-Komponenten zurückgreifen, genauso mit im Boot sein wie Entwickler in den Unternehmen, die damit arbeiten.

Dieser Artikel basiert auf einem Beitrag unserer US-Schwesterpublikation Networkworld.

Lesetipps: Log4j - Experten sagen, was jetzt zu tun ist

Log4j - die Angreifer bereiten sich vor

Julia Mutzbauer ist  Editor bei CSO. Ihr Schwerpunkt ist Security.