Software Supply Chain: Die Lehren aus Log4j

Inhaltsverzeichnis

Es ist Anfang Dezember 2021. Eine Sicherheitslücke wird veröffentlicht. Sie trägt den Namen CVE-2021-44228. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) gibt eine Cybersicherheitswarnung der Stufe Rot heraus. Risiko kritisch. Ein CVSSv3 Score von 10 von 10 Punkten. Der Spiegel schreibt "Wie löscht man ein brennendes Internet" und selbst in der Tagesschau vom 13.12.2021 findet Log4Shell Erwähnung.

Was war passiert?

Die Sicherheitslücke in der Open-Source-Java-Bibliothek Log4j war deshalb so dramatisch, weil sie in sehr vielen Java-Anwendungen eingesetzt wird – und niemand einen Überblick hatte, wo überall. Entsprechend hektisch forschten Softwarehersteller und IT-Abteilungen weltweit, ob ihre Anwendungen betroffen waren.

Es war nicht das erste Mal, dass eine Schwachstelle in einer Open-Source-Bibliothek für Überstunden in IT-Abteilungen gesorgt hat. Doch was haben wir daraus gelernt? Welche Erkenntnisse wurden gewonnen und welche Maßnahmen ergriffen, um bei der nächsten Zero-Day Vulnerability effizienter agieren zu können? Ist es möglich, schneller herauszufinden, in welchen Produkten eine Bibliothek in einer bestimmten Version verwendet wird?

Was technisch genau die Ursache ist und wie sich die Log4j-Sicherheitslücke ausnutzen lässt, liegt nicht im Fokus dieses Artikels. Es geht vielmehr darum, aufzuzeigen, wie sich eine kontinuierliche Software Composition Analysis (SCA) einrichten lässt, um Risiken in der Software Supply Chain frühzeitig zu identifizieren.

In den vergangenen Monaten traten vermehrt Fälle von ernsthaften Verwundbarkeiten in der Software Supply Chain zu Tage, häufig in Open-Source-Bibliotheken, die wie Log4j in vielen Softwareprodukten weltweit zum Einsatz kommen. Der Fall Log4j gab dem Autor letztendlich den Anstoß, sich Maßnahmen zu überlegen und umzusetzen, die dabei helfen, die Risiken in der Software Supply Chain schneller und effizienter zu identifizieren.

Was ist zu tun?

Zunächst ist es wichtig herauszufinden, welche Produkte betroffen sind, und zu recherchieren, ob bereits Patches bereitstehen, um die Lücke zu schließen. Das Log4j-Entwicklerteam hat zügig eine neue Version veröffentlicht. Allerdings folgten weitere Nachbesserungen, sodass IT-Abteilungen mehrfach patchen mussten.

Bei selbst entwickelten Anwendungen lässt sich durch die Analyse der Maven-POM-Dateien herausfinden, wo Log4j verwendet wird. Bei zugekaufter Software gestaltet sich das schwierig, da der Sourcecode meist nicht vorliegt. In solchen Fällen ist es notwendig, die Hersteller zu kontaktieren, um festzustellen, ob das Produkt gefährdet ist – und wann mit einem Patch zu rechnen ist. Einige Hersteller haben aktiv auf ihren Websites informiert, ob ihr Produkt betroffen ist. Meist jedoch nur, um Entwarnung zu geben.

In vielen Anwenderunternehmen ist jedoch unklar, wer für mutmaßlich betroffene Produkte verantwortlich ist und sich um Informationen und Patches bemühen sollte. Der IT-Betrieb installiert die Software in der Regel nur, und den Fachbereichen, die mit den Anwendungen arbeiten, fehlt die notwendige Kompetenz. Es kann daher sinnvoll sein, Product Owner für Kaufsoftware zu etablieren.

Im Falle von Log4Shell standen rasch Tools zur Verfügung, um die Infrastruktur zu härten – beispielsweise durch ein Middleware-Plug-in für den Reverse Proxy und Loadbalancer Traefik. Betroffene erhielten darüber hinaus konkrete Hilfestellung über sichere Konfigurationsmaßnahmen, die ein Ausnutzen der Sicherheitslücke verhindern sollten, wie etwa das Flag log4j.formatMsgNoLookup=true. Nutzer einer Web-Application-Firewall durften zumindest darauf hoffen, die Angriffe erkennen und blockieren zu können. Blieben die bisher genannten Maßnahmen wirkungslos, hieß der letzte Ausweg: Ausschalten!