Erkenntnisse aus OpenSSL-Schwachstellen, Teil 2: Schwachstellen in der Supply Chain finden und beheben

Diese Serie zur Supply Chain beleuchtet die Erkenntnisse aus OpenSSL und worauf Sie achten sollten, wenn Sie die Sicherheit Ihrer Supply Chain verbessern. In dieser Serie konzentrieren wir uns auf OpenSSL und relevante Bibliotheken, betrachten aber auch Schwachstellen im Allgemeinen. Im ersten Teil haben wir alles behandelt, was Sie darüber wissen müssen, wo Sie nach anfälligen Bibliotheken suchen sollten. Tauchen wir ein in Teil zwei und besprechen, wie Sie Schwachstellen in Ihrer Supply Chain finden – und vor allem beheben.

So finden Sie Schwachstellen in Ihrer Supply Chain

Welche Methoden Sie verwenden, um problematische Bibliotheken oder Pakete zu suchen, hängt davon ab, welche Bereiche Sie untersuchen. Hosts und VMs verwenden andere Mechanismen als Container und Code. Heute konzentrieren wir uns auf die Softwareseite – Container und Code.

Ein zentraler Überblick über Ihr gesamtes Ökosystem kann die Frage „Wo sind wir betroffen?“ beantworten. Dieser Überblick bietet Einblick in Ihr gesamtes Anwendungsportfolio. Er sollte alle Ihre Anwendungen und die Komponenten umfassen, aus denen sie bestehen – den Code, die Container, in denen Sie sie bereitstellen, sowie sämtliche Open-Source-Abhängigkeiten. Dieser „zentrale Überblick“ würde für jede Ihrer Softwarekomponenten eine Software-Stückliste (SBOM) speichern und einen Index über alle Anwendungen und Container bereitstellen, die Sie ausführen oder speichern. 

Quellcode und Open-Source-Bibliotheken

Ein zentraler Überblick ist hilfreich, aber wie man sagt: Im Nachhinein ist man immer schlauer. Die OpenSSL-Ankündigung könnte Sie durchaus erreicht haben, bevor Sie ein Inventar erstellen konnten (oder überhaupt wussten, dass eine Zentralisierung Ihres Inventars möglich ist). Sehen wir uns an, was Sie beachten und wo Sie suchen sollten, wenn Sie noch keine zentrale Übersicht haben. Moderne Anwendungen nutzen Open-Source-Komponenten und -Bibliotheken – 80 % oder mehr des Codes in Ihren Anwendungen könnten außerhalb Ihrer direkten Kontrolle liegen. Daher ist es ein wichtiger Teil des Problems, herauszufinden, wo diese Bibliotheken und Pakete verwendet werden.

Die Bibliotheken zu finden, die von Ihren eigenen Anwendungen und Projekten importiert werden, ist komplizierter als eine Suche auf physischen Hosts. Sie könnten mit einer Brute-Force-Suche nach „openssl“ in allen requirements.txt-Dateien unter den Projektstammverzeichnissen beginnen, aber damit werden Sie wahrscheinlich nicht viel finden. Nicht nur ist es unwahrscheinlich, dass ein einzelner Host den gesamten Quellcode all Ihrer Projekte enthält – es ist durchaus möglich (und sogar wahrscheinlich), dass Ihre Anwendung(en), falls sie auf OpenSSL angewiesen sind, dies aufgrund der transitiven Abhängigkeiten tun, die wir zuvor angesprochen haben. 

Im Idealfall hätten Sie für jede Ihrer Anwendungen eine Software-Stückliste (SBOM), mit der Sie Risiken schnell ermitteln könnten. Sie sind jedoch noch nicht flächendeckend verbreitet. Mehrere Tools ermöglichen es Ihnen, eine SBOM für Ihre Anwendungen zu erstellen. Snyk bietet beispielsweise eine API und einen CLI-Befehl, snyk sbom, mit dem eine Software-Stückliste in den Formaten SPDX oder CycloneDX erstellt wird. Doch jedes Ihrer Quellcode-Repositorys manuell zu prüfen, ist nicht praktikabel. Statt Ihren Quellcode nur auf Ihrem lokalen Computer zu scannen, können Sie ihn mit vielen Lösungen dort scannen, wo er liegt – in den Repositorys. Mit Snyk können Sie beispielsweise die zu überwachenden Repositorys hinzufügen, indem Sie einfach Ihre Konten verknüpfen und die gewünschten Repositorys auswählen.

Sind Repositorys auf diese Weise verknüpft, können sie regelmäßig gescannt werden. So lassen sich neu entdeckte Schwachstellen finden, die bereits in den Abhängigkeiten Ihrer Projekte schlummerten (zum Beispiel die OpenSSL-Schwachstellen, von denen wir gestern noch nichts wussten), ebenso wie Schwachstellen, die möglicherweise von Entwicklern hinzugefügt wurden. 

Container-Images

Container-Images sind ebenfalls Teil Ihrer Software-Supply-Chain. Sie dienen nicht nur als Grundlage für Ihre Workloads, sondern bündeln auch Inhalte, die über Ihren Code und dessen Abhängigkeiten hinausgehen. Es gibt mehrere Tools, mit denen sich Container-Images auf Zusammensetzung, Pakete und Schwachstellen scannen lassen – darunter Snyk Container mit kostenpflichtigen und kostenlosen Tarifen, IDE-Integrationen, einer Befehlszeilenschnittstelle und Unterstützung für die Automatisierung in Ihren CI/CD-Pipelines. Außerdem gibt es verschiedene Open-Source-Projekte – etwa Syft, Grype, trivy sowie ein inoffizielles Tool namens „docker index“ –, die Schwachstellen erkennen können. Das Tool docker-index lässt sich über die Befehlszeile verwenden, um CVEs zu finden. Das Tool selbst ist derzeit nicht signiert, Sie können es aber in einem Container ausführen (sehr meta). Hier ein Beispiel für ein öffentliches Image, apache/tika:2.6.0.1, das zum Zeitpunkt der Erstellung dieses Artikels noch eine anfällige OpenSSL-Version enthält. Für eine bessere Lesbarkeit habe ich die Argumente ausgeschrieben – kürzen Sie -it gern ab.

1docker run \
2    --interactive \
3    --tty \
4    --rm \
5    ghcr.io/docker/docker-index:main \
6    cve -i \
7    apache/tika:2.6.0.1 CVE-0000

Der Befehl docker-index erkennt die OpenSSL-Schwachstellen 3602 und 3768, aber sonst nichts:

1INFO Requesting image apache/tika:2.6.0.1
2INFO Copied image
3INFO Indexed 333 packages
4INFO Detected 2 vulnerabilities
5
6Detected CVE-2022-3602  HIGH
7https://dso.docker.com/cve/CVE-2022-3602
8
9pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.6?os_distro=jammy&os_name=ubuntu&os_version=22.04
10ADD file:ba96f963bbfd429a0839c40603fdd7829eaca58f20adfa0d15e6beae8244bc08 in /
110: sha256:301a8b74f71f85f3a31e9c7e7fedd5b001ead5bcf895bc2911c1d260e06bd987
12
13Detected CVE-2022-3786  HIGH
14https://dso.docker.com/cve/CVE-2022-3786
15
16pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.6?os_distro=jammy&os_name=ubuntu&os_version=22.04
17ADD file:ba96f963bbfd429a0839c40603fdd7829eaca58f20adfa0d15e6beae8244bc08 in /
180: sha256:301a8b74f71f85f3a31e9c7e7fedd5b001ead5bcf895bc2911c1d260e06bd987

Die meisten Scanner für Container und Open-Source-Komponenten zeigen eine Liste von Schwachstellen an. Einige geben auch eine „Version mit Fix“ an. Ein Beispiel ist die Ausgabe von Trivy, das eine lange Liste von Schwachstellen aufzeigt, die docker-index nicht erkennt (Auszug):

Das Tool hat die beiden neuen OpenSSL-Schwachstellen mit dem Schweregrad HIGH erkannt und zeigt eine Übersicht sowie eine „behobene“ Version an, hilft aber nicht wirklich dabei, einen sichereren Container zu erstellen:

┌────────────────┬────────────────┬──────────┬───────────────────┬────────────────────┐
│ libssl3        │ CVE-2022-3602  │ HIGH     │ 3.0.2-0ubuntu1.6  │ 3.0.2-0ubuntu1.7   │
│                │                │          │                   │                    │
│                ├────────────────┤          │                   │                    │
│                │ CVE-2022-3786  │          │                   │                    │
│                │                │          │                   │                    │
└────────────────┴────────────────┴──────────┴───────────────────┴────────────────────┘

Ähnlich wie bei Open Source in unserem ersten Beitrag ist es zwar möglich, ein oder zwei Container-Images zu scannen. Hunderte oder Tausende Container-Images zu scannen, ist in einem typischen Entwicklungsworkflow jedoch unrealistisch.

Wie bei transitiven Abhängigkeiten und Open Source verwenden Sie wahrscheinlich nicht Ubuntu- oder tika-Images direkt, sondern Images, die davon abgeleitet sind – und übernehmen damit auch die enthaltenen Schwachstellen sowie weitere Schwachstellen, die Sie über Benutzeranweisungen hinzugefügt haben. Das macht die Suche komplexer.

Wo wir betroffen sind

Wie wir gesehen haben, gibt es mehrere Tools, die dabei helfen können, anfällige Bibliotheken in Container-Images und Open-Source-Abhängigkeiten zu finden. Tools für Ad-hoc-Analysen in Ihrer lokalen Entwicklungsumgebung eignen sich vielleicht für Projekte mit wenigen Entwicklern, werden aber unhandlich, wenn das Team und die Zahl der Projekte wachsen. Tools, die sich dagegen in die zentrale Quelle für Ihr Anwendungsportfolio integrieren lassen – also in Quellcode-Repositorys und Container-Image-Registries –, können Ihr Inventar nachverfolgen und aktuelle Informationen zu möglichen Auswirkungen bereitstellen. Wenn Sie beispielsweise nach einer anderen schwerwiegenden Schwachstelle filtern, zeigt Snyk Reporting eine zentrale Übersicht der von Log4Shell betroffenen Projekte. Ganz gleich, ob wir die Brute-Force-Methode oder die ordentliche zentrale Übersicht verwendet haben: Zumindest können wir die Frage „Wo sind wir betroffen?“ beantworten.

Es geht um mehr als nur darum, Vorkommen zu „finden“

Wir haben gesehen, dass über 80 % des Codes in Ihrer Software-Supply-Chain aus externen Quellen stammen könnten. Doch die Vorkommen zu finden, ist nur ein Teil der Frage, die Ihr Chef stellen wird. Jetzt wissen wir, wo wir anfällig sind, und haben eine Liste der zu behebenden Probleme. Doch die zweite Hälfte der Frage bleibt: „Wie werden wir das beheben?“ Bei Betriebssystemen oder Anwendungen bedeutet „beheben“ normalerweise, auf Patches oder Updates eines Anbieters zu warten und diese einzuspielen. 

Bei Schwachstellen in Open-Source-Bibliotheken und Containern warten Sie wahrscheinlich ebenfalls auf Updates der Projektbetreuer – allerdings sind weitere Schritte nötig. Die Betreuer warten wahrscheinlich auch auf einen Fix von einer vorgelagerten Stelle. Nehmen wir Ubuntu 22.04, die Long-Term-Support-Version (LTS) der beliebten Linux-Distribution, als Beispiel. Als die OpenSSL-Schwachstellen bekannt wurden, enthielt Ubuntu 22.04 OpenSSL 3.0.2 (genauer gesagt 3.0.2-0ubuntu1.6), eine der anfälligen Versionen. Im Fall von Ubuntu wurde die Version 3.0.2 nicht durch 3.0.7 ersetzt, sondern gepatcht, um die Schwachstellen zu beheben. Damit war es aber noch nicht getan. Nachdem die Bibliothek gepatcht worden war, musste das Update erst für Ubuntu 22.04 selbst veröffentlicht und aktualisierte Container-Images erstellt werden. 

Wenn Sie Ubuntu-Images direkt nutzen (zum Beispiel, wenn Ihr Dockerfile mit FROM ubuntu:22.04 beginnt), können Sie Ihre Images neu erstellen, um den Fix zu übernehmen, sobald die betroffenen Images veröffentlicht wurden. (Und hoffentlich testen Sie Ihre Images, denn selbst die kleinsten Änderungen müssen geprüft werden.) Als nachgelagerter Nutzer, der auf Images setzt, die von dieser neuen Version von Jammy Jellyfish abgeleitet sind, müssen Sie möglicherweise ein paar weitere Iterationen abwarten, bis die Fixes weitergegeben wurden und das erwartete Image aktualisiert ist.

Anders als die Open-Source-Tools zum Scannen von Containern im vorherigen Abschnitt hilft Ihnen Snyk Container dabei, Abhängigkeitsbäume von Images zu durchleuchten und bessere Basis-Images zu finden, damit Sie sicherere Images erstellen können. Snyk pflegt und aktualisiert regelmäßig einen Index der Image-Versionen beliebter offizieller Images auf Docker Hub. So können Sie erkennen, wenn Images mit Rolling Tags veraltet sind – also Images, die direkt aktualisiert werden, statt eine neue Nebenversion zu erhalten. In diesem Fall erkennt Snyk Container, dass ubuntu:22.04 seit der Erstellung des gescannten Images aktualisiert wurde, und empfiehlt, das Image neu zu erstellen, um die Änderung zu übernehmen:

1Your base image is out of date
21) Pull the latest version of your base image by running 'docker pull ubuntu:22.04'
32) Rebuild your local image

Snyk Container kann Ihnen auch eine Liste besser geeigneter Images bereitstellen – unabhängig davon, ob Sie offizielle Docker-Images oder eigene Basis-Images verwenden. Dazu gehört die automatische Erstellung von Pull Requests mit nur einem Klick, damit Sie schnell ein Upgrade durchführen und mehrere Schwachstellen auf einmal beheben können.

Auch die Behebung von Schwachstellen in Open-Source-Abhängigkeiten ist mit Snyk ganz einfach. Neben Details zu anfälligen Bibliotheken erhalten Sie Informationen zu Versionen mit Fix, wie unten zu sehen:

Snyk stellt auch Tools zur Behebung bereit: Mit „Fix PRs“ können Sie mehrere Schwachstellen mit einem Klick beheben.

Wenn eine schrittweise Behebung für die Größe Ihres Unternehmens nicht praktikabel ist, ist die Antwort auf die Frage „Wie werden wir das beheben?“ ganz einfach: „Wir beheben es mit Snyk.“

Bereiten Sie sich mit Snyk auf die nächste Supply-Chain-Schwachstelle vor

Nutzen Sie die entschärften OpenSSL-Schwachstellen, um Ihre Prozesse für den Umgang mit Schwachstellen zu testen. Erstellen Sie Playbooks und Checklisten für die nächste Schwachstelle – einschließlich der einzubeziehenden Personen, der Bewertung der Auswirkungen, des zu prüfenden Inventars und der internen (und gegebenenfalls externen) Kommunikation von Ergebnissen und Auswirkungen. Sorgen Sie vor allem dafür, dass alle wissen, wo sie die Playbooks finden. Beginnen Sie noch vor der nächsten kritischen Schwachstelle mit dem Einsatz von Tools zur Nachverfolgung Ihres Quellcodes und Container-Inventars, damit Sie besser auf die nächste Schwachstelle vorbereitet sind.

Wenn Sie Snyk Container und Snyk Open Source nutzen, um Ihre Software-Supply-Chain abzusichern, können Sie Ihre Container und Open-Source-Projekte proaktiv überwachen. Statt hektisch nach anfälligen Container-Images oder Open-Source-Paketen suchen zu müssen, können Sie wissen, ob Sie betroffen sind, bevor die Schwachstellen überhaupt veröffentlicht werden. So können Sie sicher sein, dass Sie die Antworten parat haben, wenn Sie in Slack auf „send airplane“ klicken und Ihrem Chef die Nachricht schicken.

Erfahren Sie mehr über Tools für die Sicherheit der Software-Supply-Chain und darüber, wie Snyk Ihnen helfen kann, die Sicherheit Ihrer Software-Supply-Chain zu stärken. Starten Sie noch heute kostenlos.