Log4Shell: Wie gut kennen Sie Ihre Software-Lieferkette?

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die höchste Warnstufe für die vor wenigen Tagen aufgedeckte Sicherheitslücke in der weit verbreiteten Java-Bibliothek log4j vergeben. Diese Bedrohung erfordert natürlich eine sofortige Reaktion. Doch im zweiten Schritt müssen sich Unternehmen generell Fragen zu Prozessen rund um Software-Lieferketten und dokumentierte (?) Abhängigkeiten stellen. 

Ein Kommentar von Udo Schneider, IoT Security Evangelist Europe.

Die vor ein paar Tagen bekannt gewordene Log4Shell-Sicherheitslücke ist gerade in aller Munde und hält die Sicherheitsfachleute weltweit auf Trab. Das BSI spricht von einer „extrem kritischen Bedrohungslage“, denn die angreifbare Log4J-Bibliothek ist gewissermaßen „der“ Log-Standard in Java-Umgebungen. Dementsprechend wird sie auch in tausenden von Applikationen und Internet-Diensten genutzt.

Hinzu kommt, dass die Lücke einfach zu missbrauchen ist und in vielen Fällen aus der Ferne ausgenutzt werden kann, wobei sie letztendlich die Ausführung beliebiger Kommandos erlaubt. Aus Cybersecurity-Sicht ein wahrer Albtraum! Unternehmen können als unmittelbare Reaktion unseren detaillierten Empfehlungen folgen und vorhandene Patches aufspielen sowie Best Practices anwenden.

Doch in einem zweiten Schritt sollten sie einen generellen Blick auf Prozesse rund um Software-Lieferketten werfen. Denn letztendlich ist auch Log4Shell, so sicherheitsrelevant die Lücke auch sein mag, „nur“ ein fehlerhafter Baustein in der Software-Lieferkette. Um Software-Lieferketten und deren Kontext zu verstehen, hilft ein Blick auf die „reale“ Welt, etwa die Herstellung von Elektronikprodukten. Dabei sind so genannte „Stücklisten“ (BOM – Bill of Material) für Baugruppen gang und gäbe.

Betrachtet man eine einzelne Platine als Baugruppe, so enthält die passende Stückliste eine Auflistung aller verwendeten Komponenten wie Widerstände, Kondensatoren, Dioden, ICs und vieles mehr. Zu jeder Komponente werden auch genaue Parameter, Hersteller, Preise, Bezugsquellen und letztendlich auch Seriennummern bzw. zumindest Chargeninformationen gespeichert.

Sollte es also vom Hersteller einer der Bauelemente eine Information geben, dass bestimmte Bauteile einer Charge z.B. nicht den spezifizierten Temperaturwerten entsprechen, so ist es möglich selbst im Nachhinein genau nachzuverfolgen, welche Platinen (mit jeweils eigener Seriennummer) davon a) betroffen sind und b) ob Handlungsbedarf entsteht. Müssen entsprechende Maßnahmen eingeleitet werden, hilft die Information, welche Baugruppen (aufgrund der Seriennummer) überhaupt betroffen sind natürlich massiv.

Letztendlich setzt sich dieses Vorgehen mit „Baugruppen“ fast beliebig fort ... bis man letztendlich eventuell bei massiven Installationen wie z.B. dem LHC am CERN landet. Selbst bei einer so großen Maschine kann der Fehler an einem winzigen SMD-Bauteil zum Versagen der gesamten Maschine führen. Werden also z.B. fehlerhafte Chargen bekannt, so muss man letztendlich in der Lage sein, jeden einzelnen verbauten Widerstand zu verifizieren.

Software Bill of Material (SBOM)
Genauso funktionieren auch Software-Lieferketten, also SBOMs“ -- und ganz konkret zurück zu Log4Shell: Können Sie auf die Schnelle sagen, ob Sie von dieser Lücke betroffen sind? Bei eigener Software, die Log4J nutzt, lässt sich die Frage vielleicht noch schnell beantworten. Oft bieten sogar SCM-Dienste wie GitHub oder GitLab solche Funktionen direkt an.

Was aber ist mit transienten Abhängigkeiten? Nutzt vielleicht eine bei Ihnen eingesetzte Bibliothek eines Drittanbieters intern Log4J? Oder noch schlimmer – nutzt eine Library, die Sie verwenden, eine Library, die wiederum von einer Library abhängt (usw.) die Log4J nutzt? Setzt die eingekaufte Software eines Dienstleisters auf Log4J? Verwendet ein Cloud-Dienst, den Sie einkaufen, Log4J?

Fragen über Fragen, die der Antworten bedürfen, für die Sie sich mit SBOMs auseinandersetzen müssen. Log4Shell führt sehr deutlich die Probleme vor Augen, die entstehen, wenn die Software-Lieferkette eben nicht dokumentiert ist. Aber lassen Sie sich nicht täuschen. Log4Shell ist gerade sicherlich eine Art Worst-Case-Szenario. Doch selbst bei einfachen „Fehlern“, die keine direkte Sicherheitsrelevanz haben, ist die Frage, ob man betroffen ist, von Bedeutung!

Abhängigkeiten dokumentieren
Grundsätzlich geht es bei SBOMs um die Dokumentation von Abhängigkeiten. Dies können Abhängigkeiten in Form von Software (Bestandteilen) sein aber auch Dienste, Lizenzen, Server und vieles mehr. Speziell bei der Modellierung von Softwareabhängigkeiten haben sich im Laufe der Zeit zwei Austauschformate herauskristallisiert: CycloneDX und SPDX. Beide erlauben die Beschreibung verschiedener Softwarekomponenten inkl. eventueller Abhängigkeiten:

Mit der Beschreibungssprache ist es aber nicht getan. Vielmehr muss die konkrete Umgebung ebenfalls beschrieben und auf aktuellem Stand gehalten werden. Natürlich lassen sich diese Beschreibungen manuell erstellen – und manchmal, z.B. bei der Abhängigkeit von externen Diensten, bleibt auch nichts anderes übrig.

Wenn es aber um die Erstellung von Beschreibungen bei Software geht, sind manuelle Aufwände nicht sinnvoll. Hier muss die Erstellung und Pflege dieser Beschreibungen vollautomatisiert im Rahmen der CI/CD Pipeline stattfinden. Dabei gibt es grundsätzlich zwei Ansätze: Die Einbindung in den Build-Prozess und das Scannen von Build-Artefakten.

• CI/CD Einbindung – Build-Prozess
  Sowohl bei CycloneDX als auch bei SPDX gibt es Werkzeuge, die sich direkt in den Build-Prozess integrieren lassen. Diese extrahieren direkt „an der Quelle“ (transiente) Abhängigkeiten. Dies können Libraries, ausführbare Dateien aber auch Container bzw. Container-Layer sein. Die direkte Einbindung erlaubt es auch, Abhängigkeiten zu verfolgen, die z.B. nur während des Builds selbst, aber nicht im fertigen Produkt bestehen.
  
  

• CI/CD Einbindung – Build Artefakt
  Selbst wenn nicht direkt in den Build Prozess eingegriffen werden soll darf, gibt es für CycloneDX und SPDX Werkzeuge, die „im Nachhinein“ das Endergebnis scannen. D.h. diese Werkzeuge extrahieren z.B. aus der Java Anwendung die Abhängigkeiten und dokumentieren diese. Da diese Werkzeuge immer nur das fertige Ergebnis sehen, kann es aber durchaus sein, dass einige Abhängigkeiten schlichtweg übersehen werden, da diese sich aus dem Endergebnis nicht mehr erschließen lassen.
  
  

Schwachstellen-Monitoring
Für Unternehmen, die ausschließlich an einem Schwachstellen-Monitoring interessiert sind, bieten viele dieser Werkzeuge auch eine direkte Korrelation mit Schwachstellen-Datenbanken an. Das bedeutet, dass die Ausgabe nicht nur die gefundenen Komponenten enthält, sondern auch gleich eine Liste von Verwundbarkeiten. Dies ist z.B. vergleichbar mit der Einbindung von snyk, Trend Micro Application Security oder Trend Micro Container Security in die CI/CD Pipeline.

OWASP Dependency Track
Wenn auch die Nachverfolgung und Dokumentation von Lizenzen, Inventar oder Verbreitungsgrad eine Rolle spielen, so bieten sich andere Lösungen (zusätzlich) an. In diesem Umfeld ist das Dependency Track-Tool der OWASP (Open Web Application Security Project) sicherlich einer der Platzhirsche.

Als Open Source-Lösung ist es in der Regel in CI/CD Pipelines integriert und erhält dort SBOM-Daten – entweder über CycloneDX/SPDX Daten (manuell, API) oder direkt aus dem Build Prozess. Zusätzlich hält Dependency Track automatisiert Verwundbarkeitsdaten aus verschiedenen Schwachstellen-Datenbanken vor und korreliert laufend die Daten aus (historischen) Builds und Verwundbarkeiten.

Matches werden entsprechend in einem Dashboard angezeigt oder direkt via Chat und CI/CD Integration gemeldet bzw. optional auch an Werkzeuge zur automatischen Behebung weitergeleitet. Dependency Track stellt also eine Datenbank dar, mit der sich die Frage: „Wo bin ich von Log4Shell betroffen“ einfach beantworten lässt. Diese Antwort umfasst nicht nur aktuelle Versionen der Software, vielmehr werden auch Beschreibungen alter Version vorgehalten.

Eine mögliche Erkenntnis kann also sein, dass ein Unternehmen in der aktuellen Version nicht betroffen ist (da ausreichend gepatcht), 34 ältere Versionen aber betroffen sind. Wenn man nun auch noch Informationen über die Anzahl der installierten Versionen mit verfolgt, sind das nahezu perfekte Daten für eine fundierte Risikobetrachtung.

Fazit
Letztendlich ist es wichtig, die eingangs gestellten Fragen beantworten zu können: Nutzen wir (direkt oder in unserer Software-Lieferkette) Log4J? Wenn ja, in welchem Ausmaß (Version, Verbreitung) sind wir von Log4Shell betroffen? Der Aufwand zur Beantwortung dieser Frage stellt einen Gradmesser dar, inwiefern Sie Einblick in Ihre Software-Lieferkette haben, bzw. ob es sich lohnt, dort mit Werkzeugen nachzuhelfen.

Bezüglich der Werkzeuge gilt es zu klären, ob es „nur“ um die Frage „bin ich betroffen“ geht. Ist dies der Fall, helfen Tools wie snyk oder die bei GitHub und GitLab integrierten Möglichkeiten schon weiter. Ist hingegen ein umfassenderer Einblick gewünscht, so bieten sich weitere Lösungen zum Erfassen und Katalogisieren von Software-Artefakten an.

Diese gibt es sowohl kommerziell als auch kostenlos. Aus dem OpenSource-Lager ist Dependency Track hier sicherlich das am weitesten verbreitete.Schlussendlich bleibt aber festzuhalten, dass Sicherheitslücken ein wichtiges Argument für Software Supply Chain Management ist – aber sicherlich nicht das einzige!