Ein Überblick über Angriffe auf die Open Source Software Lieferkette

Wahrscheinlich ist ein großer Teil des Codes, den Sie ausführen, nicht von Ihnen geschrieben. Aber was bedeutet das in Bezug auf die Sicherheit? In diesem Beitrag werden wir erörtern, wie lange es dauert, bis ein bösartiges Paket entdeckt wird, was passiert, wenn Sie eines dieser Pakete einbinden, und was Sie dagegen tun können.

Ich werde Ihnen die wichtigsten Statistiken und Erkenntnisse aus dem Artikel von Marc Ohm et al. vorstellen. In dem Artikel'Backstabber's Knife Collection' haben sie 174 bösartige Pakete in RubyGems, PyPI und npm untersucht:A Review of Open Source Software Supply Chain Attacks'.

Wenn Sie diese Pakete selbst analysieren möchten, sollten Sie die GitHub-Seite der Autoren besuchen.

Alle Ihre Pakete gehören uns

Die typische Anwendung von heute enthält eine Reihe von Open-Source-Paketen, oft mit zusätzlichen Paketen, die im Entwicklungsprozess verwendet werden. Viele dieser Pakete tragen zu einer besseren Entwicklungserfahrung und letztendlich zu einem besseren Produkt bei.

Da Hacker nun einmal Hacker sind, stellen all diese nützlichen Open-Source-Pakete ein sehr interessantes Ziel für Angriffe auf die Lieferkette dar (d.h. "Gift in den Brunnen werfen"). In einem solchen Fall wurde das npm-Paket event-stream im September 2018 kompromittiert. Die Hacker hatten es zwei Monate lang über das Paket auf die Bitcoin-Brieftaschen der Entwickler abgesehen, bevor sich jemand meldete. Zu diesem Zeitpunkt hatte event-stream über 1,5 Millionen wöchentliche Downloads.

Offensichtlich ist dies nicht das einzige Beispiel, aber sind wir in der Lage, diese Bösartigkeit zu erkennen?

Wie schnell werden bösartige Pakete entdeckt?

Ein bösartiges Paket ist im Durchschnitt 209 Tage lang verfügbar (Minimum: -1, Maximum: 1216), bevor es öffentlich gemeldet wird.

Sie fragen, ob sie seit -1 Tag verfügbar ist? Das war , das von Anfang an als bösartig bekannt war und trotzdem heruntergeladen wurde. Einen ausführlichen Bericht über diesen Vorfall finden Sie in diesem Beitrag.

Am anderen Ende des Spektrums dauerte es 1216 Tage, bis die Schlechtigkeit inrpc-websocket 0.7.7 entdeckt wurde.

Das Scannen zum Zeitpunkt der Erstellung ist also kein Allheilmittel: Es könnte sein, dass noch niemand die Bösartigkeit entdeckt hat. Wenn Sie die bösartige Version angeheftet haben, könnten Sie sie auf unbestimmte Zeit herunterladen. Deshalb ist es wichtig, regelmäßig zu scannen.

Zum Glück gibt es nicht nur schlechte Nachrichten. In einigen Fällen entdecken die internen Teams der Paketmanager die Probleme rechtzeitig, wie bei electron-native-notify.

Was passiert, wenn Sie ein bösartiges Paket eingeschlossen haben?

Die meisten bösartigen Pakete für JavaScript und Python starten bei der Installation Routinen (d.h. sie laden zusätzliche Dateien herunter bzw. führen sie aus).

Ruby ist gegen dieses Verhalten immun, da Ruby nicht die gleiche Installationslogik implementiert. Daher lösen bösartige Ruby-Pakete Routinen zur Laufzeit aus.

• Das Hauptziel der meisten Pakete(55 %) ist die Datenexfiltration (z. B. /etc/passwd, ~/.ssh, ~/.npmrc, ~/.bash_history, ~/.aws). Besondere Erwähnung: Einige Pakete zielen auf den Discord-Token ab, da dieser mit Kreditkarteninformationen verknüpft sein kann.
• 49% der Pakete verwenden eine Art von Verschleierung.
• 41% der Pakete überprüfen eine Bedingung vor der Ausführung (z.B. ob die App in prod ist, die Auflösbarkeit eines Domainnamens, die Anzahl der Münzen in einer Krypto-Brieftasche).
• 1% der Pakete verwendeten'test' als Auslöser. Besondere Erwähnung: latter-test-js v1.0.0 führt sudo rm -rf /* aus.
• Pakete sind in der Regel unabhängig von den Betriebssystemen.

Wir wissen also, dass diese Pakete bereits in dem Moment, in dem sie installiert werden, schlimme Dinge tun können (es sei denn, Sie verwenden Ruby). Sie haben es vor allem auf die Wertsachen auf unserem Laptop abgesehen. Aber was können wir dagegen tun?

Was Sie dagegen tun können

• Scannen Sie die Pakete, die Sie regelmäßig verwenden, mit Tools wie safety (Python), bundler-audit (Ruby) oder dem in npm integrierten npm audit (JavaScript). Wenn Sie yarn verwenden, können Sie yarn audit nutzen. GitHub scannt bereits einige dieser Pakete für Sie.
• Erweitern Sie Ihr CI/CD , um die Integrität dessen, was Sie bereitstellen oder veröffentlichen, zu überprüfen, um Injektionen zu erkennen und weiteren Schaden zu verhindern.
• Verwenden Sie nach Möglichkeit temporäre Anmeldedaten, um die Auswirkungen von abgegriffenen Anmeldedaten zu begrenzen.
• Wechseln Sie SSH-Schlüssel, Zugangsschlüssel und Token regelmäßig und schützen Sie sie nach Möglichkeit mit einer Passphrase.
• Bewahren Sie Ihre Geheimnisse sicherauf.
• Verwenden Sie, wo immer möglich, eine Multi-Faktor-Authentifizierung.

Stellen Sie sicher, dass Sie im Falle einer Kompromittierung Ihre Anmeldedaten rotieren lassen. Vergessen Sie außerdem nicht, einen Vorfall bei den anderen beteiligten Parteien zu melden. Diese können Ihnen vielleicht helfen, die Probleme zu lösen oder einzudämmen.

Referenzen

1. M. Ohm et al., Backstabber's Knife Collection: A Review of Open Source Software Supply Chain Attacks, International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (2020). Springer
2. Anweisungen zum Abrufen von bösartigen Paketproben
3. ESLint Postmortem
4. Sicherheit für Python
5. Bundler-audit für Ruby
6. npm-audit für JS
7. Garn-Audit für JS