Log4j-Schwachstelle erschüttert die Cybersicherheitsbranche

Am Freitag, den 10. Dezember 2021, erschütterte eine kritische Sicherheitslücke mit der Bezeichnung Log4Shell in Apache Log4j, die Cyber Security-Branche. Dieser Vorfall ist nichts weniger als ein Fukushima-Moment. Apache Log4j ist eine bekannte Open-Source-Apache-Protokollierungsbibliothek. Wenn die Schwachstelle ausgenutzt wird, kann ein nicht authentifizierter, entfernter Angreifer eine speziell gestaltete Anfrage an einen Server senden, auf dem eine anfällige Version von Log4j läuft. Die Schwachstelle wird derzeit aktiv ausgenutzt und betrifft eine Reihe von Diensten und Anwendungen, darunter Minecraft, Steam und Apple iCloud.

Bernard Montel, EMEA Technical Director und Chief Cybersecurity Srategist bei Tenable , erklärt, was Unternehmen über diese Schwachstelle wissen müssen. Er teilt eine Checkliste der Maßnahmen, die Sicherheitsteams heute und in den nächsten Wochen ergreifen sollten, um zu verhindern, dass diese Schwachstelle ein Loch in die Cyberabwehr reißt.

Log4j offenbart Schwachstellen in Open-Source-Codebibliotheken

Log4Shell, eine kritische Sicherheitslücke in Apache Log4j, wirft ein grelles Licht auf die riskante Praxis, sich bei der Entwicklung von Unternehmensanwendungen auf Open-Source-Codebibliotheken zu verlassen. Viele Unternehmen auf der ganzen Welt verlassen sich auf Open-Source-Bibliotheken als Schlüsselelement, um Anwendungen schnell auf den Markt zu bringen. Diese Bibliotheken sind jedoch oft nicht in der Lage, einen sicherheitsorientierten Ansatz zu verfolgen. Diese Abhängigkeit von einem wilden Westen von Code-Bibliotheken wird Unternehmen weiterhin verwundbar machen, bis Zeit und Ressourcen investiert werden, um sie sicherer zu machen.

Log4Shell – ein Fukushima-Moment für die Cybersicherheit

Die Entdeckung eines kritischen Fehlers in der Apache Log4j-Software ist nichts weniger als ein Fukushima-Moment für die Cybersicherheitsbranche. Vor zehn Jahren löste ein Erdbeben und die darauffolgende Flutwelle die Kernschmelze im Kernkraftwerk Fukushima aus, die die Region bis heute plagt. In ähnlicher Weise wird sich die frühe Ausnutzung von Log4j, bei der sich Angreifer auf die niedrig hängenden Früchte der Schwachstelle stürzen, im Laufe der Zeit zu komplexeren Angriffen auf empfindlichere Systeme entwickeln, die dem Internet weniger ausgesetzt sind.

Die Welt wird noch lange über dieses Ereignis sprechen. So wie Fukushima erhebliche Probleme mit langjährigen Prozessen im Kraftwerk ans Licht brachte, so zeigt auch die Log4j-Schwachstelle, bekannt als Log4Shell, zwei wichtige Praktiken auf, die Anlass zur Sorge geben:

1. Wie Unternehmen ihre riesigen Mengen an Protokolldaten erfassen und schützen.
2. Die Verwendung von Open-Source-Codebibliotheken als Bausteine für wichtige Unternehmensanwendungen.

Apache Log4j-Schwachstelle: Ein Fukushima-Moment für die Cybersicherheitsbranche

Unternehmen auf der ganzen Welt werden noch jahrelang mit den Folgen dieser als Log4Shell bekannten Sicherheitslücke zu kämpfen haben. Die Entdeckung einer kritischen Schwachstelle in der Apache Log4j-Software ist nichts weniger als ein Fukushima-Moment für die Cybersicherheitsbranche.

Und so wie Fukushima erhebliche Probleme mit langjährigen Prozessen im Kraftwerk ans Licht gebracht hat, so wirft auch die Log4j-Schwachstelle, bekannt als Log4Shell, ein Schlaglicht auf zwei wichtige Praktiken:

• Die Art und Weise, wie Unternehmen ihre riesigen Mengen an Protokolldaten erfassen und schützen.
• Die Verwendung von Open-Source-Codebibliotheken als Bausteine für wichtige Unternehmensanwendungen.

Das Paradoxon von Log4j: Je mehr man protokolliert, desto schlimmer wird es

Tenable entdeckt jede Minute neue Anwendungen, die Log4j auf die eine oder andere Weise nutzen. Das betrifft nicht nur den Code, den Unternehmen erstellen, sondern auch die Systeme von Drittanbietern, die sie im Einsatz haben. Alles, vom neuen Drucker, den sie für ihr Büro gekauft haben, bis hin zum Ticketing-System, das sie gerade eingerichtet haben, ist potenziell von dieser Schwachstelle betroffen. Einige der betroffenen Systeme befinden sich vielleicht vor Ort, andere werden in der Cloud gehostet, aber egal, wo sie sich befinden, die Schwachstelle wird wahrscheinlich Auswirkungen haben.

Um ein Gefühl für das Ausmaß der Schwachstelle zu geben: Tenable beobachtet bereits, dass Kunden 1.000 Systeme pro Sekunde überprüfen und ein betroffenes System pro Sekunde identifizieren.

Die Ironie dieser Schwachstelle besteht darin, dass sie es Angreifern ermöglichen könnte, genau die Logging-Praktiken auszunutzen, die das Aushängeschild für solide Sicherheitspraktiken sind: Je sicherer ein Unternehmen ist, desto mehr protokolliert es jede Aktion, was bedeutet, dass sie auf einem größeren Pool von Logging-Daten sitzt, die potenziell ausgenutzt werden können. Die ausgereiftesten Sicherheitsorganisationen erfassen in der Regel die größte Menge an Protokolldaten, um effektiv auf Vorfälle reagieren und Sicherheitsmaßnahmen ergreifen zu können. Das Kernproblem von Log4j ist, dass man es ausnutzen kann, wenn man es dazu bringt, beliebige Spuren zu protokollieren. Tenable hat es mit sehr unsicheren Daten zu tun, und die Bibliothek behandelt sie aus irgendeinem Grund so, als wären sie bereinigt worden.

Open-Source-Code-Bibliotheken: Anwendungen auf wackligen Fundamenten bauen

Der Apache Log4j-Flaw wirft ein grelles Licht auf die riskante Praxis, sich bei der Entwicklung von Unternehmensanwendungen auf Open-Source-Codebibliotheken zu verlassen. Die Apache Foundation, von der auch die Struts-Schwachstelle im Jahr 2017 stammt, ist eine von der Community geführte Organisation, die behauptet, Softwareprodukte im Wert von 22 Milliarden US-Dollar kostenlos für die Allgemeinheit zur Verfügung zu stellen. Unternehmen auf der ganzen Welt profitieren jeden Tag von der Arbeit der Stiftung. Dennoch haben wir es als Branche nicht zu unserer Priorität gemacht, die Organisation mit Mitteln zu unterstützen, die einen sicherheitsorientierten Ansatz fördern können.

Da die Anforderungen an die digitale Transformation und die Agilität der Softwareentwicklung jedes Jahr exponentiell steigen, verlassen sich Unternehmen auf der ganzen Welt auf Open-Source-Bibliotheken als Schlüsselelement ihrer Fähigkeit, Anwendungen schnell auf den Markt zu bringen. Die Folge ist eine Abhängigkeit von einem quasi wilden Westen von Code-Bibliotheken. Dies wird Unternehmen weiterhin verwundbar machen, solange sie nicht die nötige Zeit und die Ressourcen investieren, um für mehr Sicherheit zu sorgen. Es ist längst an der Zeit, ein Sicherheitsklassifizierungssystem für Open-Source-Codebibliotheken zu schaffen. Ein solches System würde jedem Code eine Sicherheitseinstufung zuweisen und den Benutzern einen Überblick darüber verschaffen, wie gut die Bibliotheken unter Sicherheitsaspekten gepflegt werden.

Wenn Unternehmen Open-Source-Software weiterhin zu einer kritischen Komponente ihrer benutzerdefinierten Entwicklungsmodelle machen wollen, ist es an der Zeit, eine Reihe von Standards und Praktiken einzuführen, die eine saubere Bewertung der Kritikalität jeder Open-Source-Komponente in ihrer Infrastruktur ermöglichen. Ebenso gilt es sicherzustellen, dass bei jedem Schritt im Entwicklungslebenszyklus ein Sicherheitsdesign vorhanden ist.