Am 24. November 2021 entdeckte ein Alibaba-Sicherheitsingenieur eine Schwachstelle in der beliebten und weit verbreiteten Java-Protokollierungsbibliothek Log4J. Seitdem rotieren die IT-Abteilungen weltweit. Lesen Sie, warum die Log4j Sicherheitslücke Log4Shell ein Warnruf zur Umkehr sein sollte.
Diese Lücke schlummerte bereits seit über acht bzw. neun Jahren im Kern von Log4j. Sie kann dazu ausgenutzt werden, fremden Code von einem entfernten Server zu laden und später auszuführen. Um das dritte Adventswochenende 2021 begann eine hektische Suche nach der Nutzung dieser Sicherheitslücke, da diese inzwischen bereits für Angriffe aus dem Internet verwendet wurde. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hatte nach kurzer Zeit die Warnstufe Rot für die unter Log4Shell bekannte Schwachstelle ausgerufen. Dabei wurde sogar empfohlen, im Zweifelsfall betroffene Dienste einfach vom Netz zu nehmen, was einige Anbieter dann auch taten.
Obwohl recht schnell erste Fehlerkorrekturen und Anweisungen zur Risikominimierung vorfügbar waren, war es für viele Software-Produkthersteller oder auch Projekte nicht so einfach, diese so schnell umzusetzen, da viele gar nicht wussten, wo welche Versionen dieser weiter versteckten Bibliothek verwendet wurden. Viele verwenden Log4j indirekt über die Verwendung von Fremdbibliotheken, die diese mitbringen.
Mit rund 35.000 Java-Paketen sind etwa acht Prozent aller Maven-Central-Pakete von der Log4Shell potenziell betroffen. Da nicht alle Java-Pakete in Maven-Central liegen, geschweige denn alle Produkte, die Log4j verwenden, ist das Ausmaß der Verbreitung dieser Sicherheitslücke schon zu erahnen. Sie zieht sich von Online-Spielen, über Telefonsoftware hin zu E-Commerce Plattformen.
Der Erfolg der Software-Industrie beruht im großen Stil auf der massiven Nutzung von Open Source-Software. Das Problem dabei ist, dass viele Unternehmen diese Software mehr nutzen, als zu ihrer Weiterentwicklung oder Pflege beizutragen. Insofern ist es umso bewundernswerter, wie Freiwillige so schnell die gemeldete Sicherheitslücke in Log4j behoben haben. Doch Sicherheit sollte nicht von der Arbeit Freiwilliger abhängigen. Sicherheit muss in der Software-Entwicklung von Anfang an verfolgt werden und nicht nur, wenn besonders kritische Lücken in der Öffentlichkeit auftauchen.
ShiftLeft-Ansatz in den DevSecOps Pipelines
Deswegen konnten Firmen, die den ShiftLeft-Ansatz in ihren DevSecOps Pipelines bereits umgesetzt haben, parallel mit der Meldung der Korrekturversion diese bereits mittesten und noch am gleichen Tag in Produktion ausliefern und so das Risiko des „zero day exploits“ reduzieren. Auch Cloud native Dienste konnten schneller zur Laufzeit gepatcht werden, da es hier mit Java-Agenten oder Kubernetes-Ressource-Deployments einfache Möglichkeiten gab, die Gefahr zu bannen oder „zero trust“ Netzwerke mit wenig Aufwand einzurichten. Amazon sei hier exemplarisch genannt. Der Anbieter hat es für seine Dienste EC2, EKS, ECS und Fargate beschrieben.
Denn Geschwindigkeit ist bei solcher Art von Sicherheitslücke enorm wichtig. In der Zeit, bis die Korrekturversion in Produktion eingespielt ist, kann bereits Schadsoftware installiert sein, die auch später noch Schaden anrichten kann.
Löchrige Lieferketten zu reparieren, ist aufwändig. Das haben viele Firmen in diesem Jahr erfahren dürfen. Gleiches gilt für die Produktionsketten für Software. Sie sind nur so stark, wie das schwächste Glied. Da die durchschnittliche Anzahl der verwendeten Open Source-Komponenten zunimmt, steigt damit auch die Gefahr, sich eine Sicherheitslücke einzufangen. Auch hier ist Vorsorge besser als Reparatur. Die verwendeten Drittkomponenten sollten kontinuierlich auf bekannte Sicherheitslücke überprüft werden und Regeln definiert werden, ab welcher Stufe diese automatisch aktualisiert werden.
Der Preis der scheinbar kostenlosen Nutzung ist große gemeinsame Verantwortung und Wachsamkeit. Kontinuierlich sicherer entwickeln heißt, weniger Sicherheitslücken in der Produktion zu haben, die behoben werden müssen. Die Reaktionszeiten auf Sicherheitslücken werden für alle Beteiligten immer kürzer, sodass Unternehmen nur mit einer funktionsfähigen DevSecOps-Pipeline lieferfähig bleiben. Das „zero day exploits“ Zeitfenster wird immer kleiner, wie die hektischen Korrekturen bei Log4j zeigen. Dadurch müssen Nutzer von Open Source-Komponenten eine andere Kultur entwickeln, um schneller auf solche Herausforderungen reagieren zu können. Leider werden solche Lücken, wie bei Log4j, nicht die Ausnahme, sondern die Regel sein. Deswegen bereiten Sie sich am besten bereits heute darauf vor.
Lesen Sie auch den Blog-Beitrag zu DevSecOps.
