Schädliche Pakete und Supply-Chain-Angriffe mit Snyk verhindern

Open-Source-Pakete spielen eine entscheidende Rolle in der modernen Softwareentwicklung und treiben das rasante Entwicklungstempo voran, das wir überall beobachten. Für Entwicklerinnen und Entwickler, die ihrer Anwendung neue Funktionen hinzufügen möchten, ergibt es einfach keinen Sinn, das Rad neu zu erfinden. Warum nicht einfach ein Paket installieren, in dessen Entwicklung bereits jemand Zeit investiert hat und das genau dieselbe Funktionalität bietet?

Doch Open-Source-Pakete sind auch ein ideales Mittel, um schädlichen Code in Anwendungen einzuschleusen und die Supply-Chain-Sicherheit zu untergraben. Der Grund dafür ist einfach: Sie sind ein leichtes und lohnendes Ziel für Angreifer. Pakete werden ohne Sicherheitsprüfung in Paketregister hochgeladen und anschließend heruntergeladen – bei beliebten Projekten Millionen Mal pro Woche – und gelangen mit kaum mehr Prüfung in Codebasen.

Register wie npm, PyPI und RubyGems haben in den vergangenen Jahren alle ihren Anteil an schädlichen Paketen erlebt. Es geht also nicht darum, dass ein Ökosystem anfälliger wäre als ein anderes. Vielmehr handelt es sich um eine grundlegende Sicherheitsschwäche der modernen Softwareentwicklung, die von Sicherheitsteams – und vor allem von Entwicklerinnen und Entwicklern – erkannt und angegangen werden muss.

In diesem Beitrag werfen wir einen kurzen Blick darauf, wie schädliche Pakete bei Software-Supply-Chain-Angriffen eingesetzt werden und wie Snyk dabei helfen kann, sie zu verhindern.

Schädliche Pakete bei Software-Supply-Chain-Angriffen

Software-Supply-Chain-Angriffe zielen darauf ab, schädlichen Code in ein Softwareprodukt einzuschleusen, um abhängige Systeme weiter unten in der Lieferkette zu kompromittieren. Sie können jedoch sehr unterschiedlich aussehen und sich sowohl hinsichtlich des Angriffsziels als auch der genauen Vorgehensweise unterscheiden.

Beim SolarWinds-Angriff waren beispielsweise Software-Build-Prozesse und Quellcode das Ziel. Beim jüngsten Kaseya-Angriff richtete sich der Angriff gegen bereits vorhandene Software. Und immer häufiger sind Open-Source-Pakete das Angriffsziel. Bei dieser Art von Software-Supply-Chain-Angriff wird schädlicher Code in ein Paket eingeschleust, das in einem Paket-Repository gelistet ist (z. B. npm, PyPI, RubyGems). Entwicklerinnen und Entwickler, die der Authentizität und Integrität dieser Pakete blind vertrauen, laden die schädlichen Pakete unwissentlich herunter und installieren sie – manuell oder im Rahmen eines automatisierten Build-Prozesses.

Aus Sicht von Angreifern kann diese Methode äußerst effektiv sein. Open-Source-Pakete werden millionenfach täglich heruntergeladen und bieten daher einen perfekten Verbreitungsweg. Der bekannte event-stream-Angriff von 2018 zeigt, welche Reichweite ein Software-Supply-Chain-Angriff mit schädlichen Paketen erzielen kann. In diesem Fall übernahm der Angreifer zunächst die Kontrolle über das äußerst beliebte Paket event-stream und änderte es dann so, dass es von einem schädlichen Paket namens flatmap-stream abhängig war. Damals wurde event-stream von 1.600 Paketen verwendet und 1,5 Millionen Mal pro Woche heruntergeladen.

Wie wird schädlicher Code in Pakete eingeschleust?

Eine Angriffsmethode besteht darin, ein völlig neues Paket mit schädlichem Code zu erstellen. Diese Pakete können einen Namen verwenden, der einem bestehenden Paket ähnelt (Typosquatting), oder den Namen bzw. Bezeichner eines bestehenden Pakets wiederverwenden, das von der ursprünglichen Paketbetreuung zurückgezogen wurde (ein „Use-after-free“-Exploit). Bei der zweiten Methode wird ein bestehendes Paket infiziert, indem schädlicher Code in den Quellcode, während des Builds oder in das Paket-Repository eingeschleust wird. Dazu muss lediglich eine scheinbar harmlose Pull-Anfrage mit dem schädlichen Code von der Projektbetreuung übernommen werden. Eine dritte Methode besteht darin, schädliche Pakete in alternativen Repositorys oder Repository-Spiegeln hochzuladen.

Sobald ein schädliches Paket im Abhängigkeitsbaum eines Projekts auftaucht, gibt es verschiedene Möglichkeiten, den schädlichen Code auszuführen. In vielen Fällen werden Installationsskripte während der Paketinstallation ausgeführt. In anderen Fällen muss der schädliche Code zur Laufzeit aufgerufen werden.

Schädliche Pakete mit Snyk eindämmen

Wie können Sie sich also vor schädlichen Paketen schützen?

Für jedes Ökosystem gibt es spezielle Strategien, um zu verhindern, dass schädliche Pakete in Ihre Codebasis gelangen. Für JavaScript haben wir beispielsweise einige Best Practices in diesem Spickzettel zusammengestellt. Als Lösung für die Anwendungssicherheit bietet Snyk außerdem verschiedene integrierte Möglichkeiten, schädliche Pakete früh im Entwicklungsprozess, aber auch in späteren Phasen zu erkennen.

Sorgfaltsprüfung nach links verlagern

Anwendungssicherheit nach links zu verlagern ist längst zum De-facto-Standard geworden. Die effektivsten Teams automatisieren Sicherheitstests so früh wie möglich – bereits in lokalen Entwicklungsumgebungen und IDEs. Doch Sicherheitsprüfungen und das Erkennen schädlicher Pakete können sogar stattfinden, bevor Sie die erste Zeile Code schreiben – nämlich während der Planungs- und Recherchephase.

Eine sorgfältige Prüfung ist immer empfehlenswert, wenn Sie recherchieren, welche Software Sie in Ihr Projekt integrieren möchten. Ein bestimmtes Paket zu untersuchen, ist jedoch nicht immer einfach. In einer idealen Welt würden Paketregister alle nötigen Informationen bereitstellen, um zu entscheiden, ob ein Paket installiert werden soll – einschließlich Angaben dazu, ob es sicher ist. In der Realität fehlen den Registern jedoch viele Informationen zum Zustand und zur Sicherheit von Paketen.

Snyk Advisor ist ein kostenloses Online-Recherchetool, das Ihnen bei der Entscheidung helfen kann, welches Paket Sie in Ihren Projekten verwenden sollten. Snyk Advisor zeigt einen Zustandswert an, der auf wichtigen Faktoren basiert, die bei der Auswahl eines Pakets berücksichtigt werden sollten. So analysiert Snyk Advisor beispielsweise den Wartungszustand eines Pakets anhand der Häufigkeit von Versionsveröffentlichungen und der Aktivität im Repository. Außerdem bewertet Snyk Advisor die Beliebtheit eines Pakets und die Stärke der Community, die das Projekt unterstützt.

Natürlich berücksichtigt Snyk Advisor auch den Sicherheitsstatus eines Pakets. Die Sicherheitsdaten basieren auf der Snyk Intel Vulnerability Database und enthalten Informationen dazu, ob ein Paket schädlich ist. Im Beispiel unten wird das npm-Paket lyft-dataset-sdk von Snyk Advisor als schädliches Paket gekennzeichnet, das für Dependency Confusion missbraucht werden kann. Das Paket trägt denselben Namen wie ein von Lyft entwickeltes Python-Paket und kann daher leicht in eine Codebasis gelangen, in der diese Abhängigkeit definiert ist.

Auch die Snyk Vulnerability Database kennzeichnet schädliche Pakete und kann Teil Ihres Rechercheprozesses sein.

Im folgenden Typosquatting-Beispiel wird ein Gem namens auth-client als schädlich gekennzeichnet. Die verantwortliche Person bzw. die verantwortlichen Personen haben diesen Namen bewusst so gewählt, dass er den Namen bestehender und sicherer Ruby-Pakete sehr ähnlich ist (z. B. auth_client, authclient). So hoffen sie, dass Entwicklerinnen und Entwickler den Namen der Abhängigkeit falsch eingeben und dadurch das trojanisierte Paket herunterladen.

Schädliche Pakete über den gesamten SDLC hinweg bekämpfen

Selbst bei gründlicher Recherche können schädliche Pakete unentdeckt bleiben. Die Sicherheitstests von Snyk kommen in verschiedenen Phasen des SDLC zum Einsatz, damit diese Pakete so schnell wie möglich erkannt werden.

Bei Git-Projekten, die von Snyk überwacht werden, wird jede neue Pull-Anfrage eines beitragenden Entwicklers mit der Snyk Vulnerability Database abgeglichen. Wird ein schädliches Paket erkannt, schlägt der Sicherheitstest fehl und gibt Informationen zum Paket sowie zum Grund für das Fehlschlagen aus.

Was ist mit schädlichen Paketen, die sich bereits in Ihrem Backlog befinden? Wenn Sie mit Hunderten oder gar Tausenden von Schwachstellen konfrontiert sind, kann es selbst für das erfahrenste Team eine enorme Herausforderung sein, ein Problem zu finden, das durch ein schädliches Paket eingeführt wurde.

Snyk kennzeichnet schädliche Pakete auch in der Snyk-Benutzeroberfläche. Bei von Snyk überwachten Projekten fließt diese Information in den Priority Score einer Schwachstelle ein – neben weiteren Faktoren wie dem CVSS-Score, der Verfügbarkeit eines Fixes, der Frage, ob die Schwachstelle aktuell in den sozialen Medien im Trend liegt, bekannten Exploits, dem Alter der Schwachstelle und ihrer Erreichbarkeit. So finden, priorisieren und beheben Sie diese konkreten Probleme schnell:

Frühzeitig handeln

Aus Sicht von Angreifern macht dieser Angriff besonders attraktiv, dass Pakete ohne jegliche Sicherheitsprüfung problemlos in Register hochgeladen werden können und die Abhängigkeit von solchen Paketen für ein immer höheres Entwicklungstempo stetig zunimmt.

Dies ist eine grundlegende Sicherheitsschwäche der heutigen Anwendungsentwicklung. Deshalb müssen Fachleute aus Entwicklung und Sicherheit schädliche Pakete bereits in den frühesten Recherchephasen erkennen können – bei der Auswahl eines Pakets, aber auch später im Entwicklungsprozess.

Weitere Informationen zur Software-Supply-Chain-Sicherheit finden Sie hier.