Lehren aus OpenSSL-Schwachstellen, Teil 1: Bereiten Sie Ihre Supply Chain auf die nächste kritische Schwachstelle vor

Es ist früh am Morgen an einem für Oktober ungewöhnlich warmen Dienstag. Sie lesen Ihre E-Mails bei Ihrer ersten Tasse Kaffee oder Tee des Tages und müssen beinahe spucken, als Sie lesen, dass OpenSSL demnächst ein Update zur Behebung einer KRITISCHEN Schwachstelle veröffentlicht. Sofort kommen Ihnen Bilder von Heartbleed in den Sinn. Sie verfassen schnell eine Slack-Nachricht an Ihre Vorgesetzten und merken – kurz bevor Sie auf „Senden“ klicken –, dass Sie genau wissen, was sie fragen werden: Wo sind wir betroffen, und wie werden wir das Problem beheben?

Das OpenSSL-Projektteam kündigte die Schwachstelle mit etwa einer Woche Vorlauf und reichlich Anlass zur Panik an. Als es schließlich veröffentlichte, welche Probleme mit Version 3.0.7 behoben wurden, stufte es den Schweregrad auf „hoch“ herab und gab zwei neue Schwachstellen bekannt. Aber was, wenn dies das nächste Heartbleed wäre? Wären Sie vorbereitet? Wie würden Sie herausfinden, ob und wo Sie betroffen sind? Wo müssten Sie überhaupt suchen? Schließlich ist es nicht die Frage, „ob“ eine neue kritische Schwachstelle in einer häufig genutzten Bibliothek auftaucht, sondern „wann“. 

In dieser zweiteiligen Serie gehen wir auf einige Aspekte ein, die Sie berücksichtigen sollten, wenn Sie Schwachstellen in Ihrer Software-Supply-Chain aufspüren. Diese Serie konzentriert sich zwar auf OpenSSL und relevante Bibliotheken, wir betrachten aber auch Schwachstellen im Allgemeinen. Beginnen wir damit, wo Sie nach anfälligen Bibliotheken suchen sollten, und sehen uns einige Tipps und Tricks für die Suche an.

Wo Sie in Ihrer Supply Chain nach anfälligen Bibliotheken suchen sollten

Bei den beiden neuen OpenSSL-CVEs (CVE-2022-3602 und CVE-2022-3786) handelt es sich um Buffer-Overflow-Probleme, die OpenSSL-Versionen von 3.0.0 bis 3.0.6 betreffen. Glücklicherweise waren die Versionen 1.x, die deutlich häufiger im Einsatz sind, nicht betroffen. „Gut“, denken Sie vielleicht, „ich muss also nur nach Hosts suchen, auf denen OpenSSLv3 installiert ist.“ Das ist zwar ein Schritt in die richtige Richtung, doch es gibt noch weitere Aspekte zu beachten – und viele weitere Orte und Wege, über die sich anfällige Versionen einschleichen können.

Hosts, VMs und Container-Images

Die Ressourcen, mit denen Sie Workloads ausführen, werden üblicherweise nicht als Teil der Supply Chain betrachtet, sollten aber nicht außer Acht gelassen werden. Neben der Überprüfung physischer Hosts auf betroffene OpenSSL-Versionen – Server, Desktops, Laptops und Workstations – müssen Sie auch virtuelle Hosts berücksichtigen. Dazu gehören virtuelle Maschinen (VMs), die auf Ihren eigenen Hypervisoren laufen, aber auch Computing-Instanzen bei AWS, GCP, Azure oder anderen Cloud-Anbietern. Diese Cloud-Instanzen, ob EC2, GCE oder ein anderes markenspezifisches Akronym, sind potenzielle Angriffspunkte. Gute Cloud- und Netzwerkkonfigurationen können den Zugriff auf diese Instanzen einschränken, doch es ist besser, ein durchsuchbares Inventar zu pflegen. Dazu können Sie Endpoint Protection auf Ihren Hosts installieren oder native Cloud-Tools wie AWS Inspector verwenden (der AWS-Workloads in der AWS-Umgebung über EC2 ermittelt). In diesem Blog konzentrieren wir uns auf die Software-Seite.

Neben physischen und virtuellen Hosts betreiben mehr als 90 % der von uns befragten Unternehmen auch dynamische und kurzlebige containerisierte und serverlose Workloads, deren Scan etwas schwieriger sein kann. Diese Workloads sind kurzlebig, da sie nur für kurze Zeit bestehen können, und dynamisch, weil sie nach einem Zeitplan oder durch Ereignisse instanziiert werden können. Deshalb reicht es nicht aus, nur die laufenden Container zu überprüfen. Sie müssen auch die Container-Images in Ihrem Inventar prüfen, von denen es Hunderte oder Tausende geben kann. 

Container-Images werden üblicherweise in einer Container-Registry wie Docker Hub, Quay oder JFrog Artifactory gespeichert oder in einem vom Cloud-Anbieter bereitgestellten Image-Repository. Außerdem können Images als Workloads bereitgestellt oder als Grundlage – also als Basis-Image – für andere Images verwendet werden. Schwachstellen werden oft transitiv weitergegeben. Wenn Sie ein anfälliges Paket in einem Container-Image finden, ist es möglich und sogar wahrscheinlich, dass auch davon abgeleitete Images betroffen sind, die mit `FROM` auf diesem Image aufbauen.

Damit haben Sie einen guten Überblick darüber, wo Sie aus Sicht der „Hosts“ (physisch, virtuell und kurzlebig) nach OpenSSL suchen sollten. An diesen Stellen wurde OpenSSL wahrscheinlich über Paketmanager installiert – zum Beispiel mit `brew (or yum, or apt) install openssl` – oder über heruntergeladene und manuell installierte Pakete. Es gibt jedoch noch weitere Wege, auf denen anfällige Pakete auf Ihre Systeme gelangen können.

Quellcode und Abhängigkeiten

Möglicherweise sind bestimmte OpenSSL-Versionen auf Ihren Hosts installiert – zum Beispiel, wenn Sie eine Version installieren, um SSH-Verbindungen zu anderen Hosts herzustellen oder von dort anzunehmen. Unabhängig davon, ob diese direkten Vorkommen anfällig sind, können weitere Instanzen durch oder zusammen mit der von Ihnen verwendeten Software oder durch die von Ihnen entwickelte und bereitgestellte Software installiert werden. Diese Instanzen gelangen in Ihre Supply Chain, wenn Ihr Code direkt von OpenSSL-Bibliotheken abhängt. Zum Beispiel, wenn Ihre Anwendung OpenSSL-Bibliotheken in ihren Abhängigkeiten angibt, etwa in `requirements.txt`, `pom.xml` oder `Gemfile`. Das kann auch vorkommen, wenn etwas im Abhängigkeitsbaum Ihrer Anwendung OpenSSL benötigt – selbst wenn es viele Ebenen tiefer in den transitiven Abhängigkeiten liegt. Ihre Anwendung nutzt zum Beispiel eine Hilfsbibliothek, die wiederum auf eine Kryptobibliothek angewiesen ist. So kann sich die Abhängigkeitskette fortsetzen, bis der Abhängigkeitsbaum zeigt, dass die Bibliothek „qux“ OpenSSL 3.05 eingebunden hat, obwohl keine der Zwischenbibliotheken in Ihrem dreizeiligen `Gemfile` überhaupt auftaucht. Wenn etwas im Abhängigkeitsbaum Ihrer Anwendung OpenSSL-Bibliotheken einbindet, enthält auch die Software-Stückliste (SBOM) Ihrer Anwendung diese OpenSSL-Bibliotheken.

Manchmal kopieren Anwendungsentwickler OpenSSL-Bibliotheken einfach in ihre Anwendungen und verteilen sie mit, statt sie über Paketmanager einzubinden. In diesem Fall bettet die Anwendung die Bibliothek während des Build-Prozesses ein, anstatt auf das Vorhandensein externer Bibliotheken angewiesen zu sein.

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

Wenn Sie Snyk Container und Snyk Open Source zum Schutz Ihrer Software-Supply-Chain einsetzen, 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, noch bevor die Schwachstellen überhaupt veröffentlicht werden. So können Sie sicher sein, die Antworten parat zu haben, wenn Sie in Slack auf „Senden“ klicken und die Nachricht an Ihre Vorgesetzten abschicken.

Falls Sie noch keines haben, erstellen Sie noch heute ein kostenloses Snyk-Konto und sparen Sie Zeit und Aufwand bei Ihrer Suche. Besuchen Sie uns nächste Woche wieder: Dann sprechen wir weiter darüber, wie Sie Schwachstellen in der Supply Chain finden und beheben können.