Autor
Ein Leitfaden zum Erkennen der Risiken, denen Sie ausgesetzt sind, und einige Tipps zum Schutz vor diesen Risiken.
In letzter Zeit ist eine neue Art von Cyber-Bedrohung ans Licht gekommen: Angriffe auf die Software-Lieferkette. Sie sind zwar selten, haben aber massive Auswirkungen, und der Schutz vor ihnen wird immer wichtiger. Aufgrund der Vielfalt der Anwendungsfälle gibt es keine einheitliche Regel, die Sie auf Ihre Python-Projekte anwenden können, um sicher zu sein, und wie immer hängt es von Ihrem Kontext ab.
Einleitung
In den traditionellen Branchen ist eine Lieferkette alles, was es einem Unternehmen ermöglicht, ein Produkt an den Kunden zu liefern. Wenn Sie zum Beispiel ein Croissant in der Bäckerei kaufen, sind alle Zutaten, die Verpackung und der Transport Teil der Lieferkette.
Im Softwarebereich ist eine Lieferkette alles, was sich auf Ihre Software auswirkt, bevor sie in Produktion geht. Sie umfasst alles von der Entwicklungsphase bis zum Release-Prozess, einschließlich des von Ihnen geschriebenen Codes, Ihrer Abhängigkeiten, Ihrer Build-Umgebung, Ihrer IDE, Ihrer Image-Registry - jede Komponente, mit der Ihre Software zu irgendeinem Zeitpunkt interagiert!
Der Begriff "Lieferkette" ist in letzter Zeit aufgrund von Cyberangriffen mit weitreichenden Auswirkungen in den Blickpunkt gerückt. Von allen Angriffen dürfte Solarwinds der bekannteste sein. In der Tat waren die US-Regierung, große Technologieunternehmen wie Microsoft und Intel, aber auch Krankenhäuser, Energieversorger und Finanzinstitute betroffen.
Ironischerweise ist die Grundursache die Infektion von Solarwinds Orion, einem Netzwerksicherheitsmonitor. Das Build-System war kompromittiert worden und alle neuen Versionen zwischen März und Juni 2020 waren mit Malware infiziert. Das Ergebnis ist, dass alle Kunden, die ihre Software in diesem Zeitraum aktualisiert haben, kompromittiert wurden.
Auch wenn der Solarwinds-Angriff in den Medien ausführlich behandelt wurde, gibt es Dutzende ähnlicher Angriffe, von denen wir noch nie gehört haben. Glücklicherweise führt die Cloud Native Computing Foundation eine Übersicht über alle diese Angriffe in einem öffentlichen Repository. Sie werden überrascht sein, wie schnell sich diese Angriffe in den letzten Jahren entwickelt haben.
Es ist nicht möglich, alles, was mit der Sicherheit der Lieferkette zu tun hat, in einem einzigen Blog-Beitrag zu behandeln. Daher werden wir uns in diesem Artikel vor allem auf Projekte konzentrieren, die Python als Primärsprache verwenden.
Wie man Abhängigkeiten in Python verwaltet
Obwohl Python eine "batteries included"-Philosophie verfolgt, benötigen Sie oft externe Bibliotheken, die Sie aus dem PyPI, dem offiziellen Paketindex, herunterladen können, und das ist der Punkt, an dem Sie sehr vorsichtig sein müssen.
Das Python-Ökosystem wurde bereits ins Visier genommen, insbesondere durch den Einsatz von zwei Techniken:
Die erste Technik betrifft einen Befehl, den jeder Python-Entwickler im Laufe seiner Karriere mindestens einmal ausgeführt hat:
Pip-Installation
Hacker veröffentlichen Pakete mit fast demselben Namen wie bestehende Pakete in der Hoffnung, dass Sie einen Tippfehler machen und ihr Paket anstelle des offiziellen Pakets installieren. Zum Beispiel, ein Paket namens python3-dateutil anstelle der offiziellen dateutil wurde kürzlich entdeckt.
Die Python-Gemeinschaft arbeitet hart daran, das Risiko zu mindern, aber das Risiko ist immer noch hoch.
Die zweite Technik, die Abhängigkeitsverwirrung, ist anspruchsvoller als die erste und hat damit zu tun, wie pip arbeitet unter der Haube.
Mit diesem Befehl setzen Sie sich dem Risiko aus:
pip install --extra-index-url
Wenn Sie diesen Befehl eingeben, geschieht Folgendes:
Nehmen wir ein Beispiel:
In diesem Beispiel wird das Paket des böswilligen Hackers auf dem Rechner installiert. Die höhere Versionsnummer befindet sich nämlich auf dem öffentlichen Paketindex.
Sie haben vielleicht verstanden, was bei diesem Prozess schief gehen kann. Jemand mit bösen Absichten kann Pakete in einem öffentlichen Repository veröffentlichen, die die gleichen Namen haben wie die in internen Paketindizes gehosteten und sie mit einer lächerlich hohen Versionsnummer versehen. Außerdem ist es gar nicht so schwer, relevante Paketnamen zu finden, wie dieser Sicherheitsforscher gezeigt hat.
Dieser Befehl könnte als "insecure by design" bezeichnet werden. Dieser Angriff nutzt eine Funktion des Python-Paketmanagers aus und nur wenige Entwickler sind sich dieses Verhaltens bewusst.
Wie man sich vor diesen Angriffen auf die Lieferkette schützen kann
Um sich gegen Tippfehler-Angriffe zu schützen, können Sie eine Sperrdatei verwenden. Eine gute Sperrdatei hat die folgenden Eigenschaften:
Die gute Nachricht ist, dass es ein Paket gibt, dessen Zweck es ist, eine Sperrdatei für Sie zu erstellen: pip-tools. Mit nur wenigen Befehlen können Sie eine Sperrdatei mit allen zuvor beschriebenen Attributen erzeugen.
$ python3 -m venv my-env # Erstellen einer neuen virtuellen Umgebung $ source my-env/bin/activate # Aktivieren der Umgebung $ pip install pip-tools==6.3.0 # Installieren Sie das Paket, mit dem Abhängigkeiten richtig zu verwalten $ echo "sacremoses==0.0.46" >> requirements.in # Fügen Sie das Paket Ihrer Ihrer Wahl in requirements.in $ pip-compile --generate-hashes # kompiliert requirements.txt mit Hashes basierend auf dem, was Sie in requirements.in eingegeben haben
Ihre Datei requirements.txt sollte wie folgt aussehen:
Jetzt, da Sie diese Datei mit allen Abhängigkeiten und den zugehörigen Versionen und Hashes haben, können Sie bei der nächsten Bereitstellung den folgenden Befehl ausführen:
pip install --require-hashes -r requirements.txt
So können Sie sicher sein, dass die Pakete, die Sie in der Produktion verwenden, nicht verändert wurden. Angenommen, Sie haben beim Schreiben Ihrer requirements.in Datei 👀, können Sie auch sicher sein, dass Sie das Paket herunterladen, das Sie wirklich wollen, da alles automatisiert ist. Kein Risiko eines Tippfehlers!
Diese bewährte Praxis ist gut, um sich gegen Typo-Squatting-Angriffe zu schützen, aber was ist mit der Verwirrung von Abhängigkeiten?
Wenn Sie sich die pip Dokumentation sehen Sie, dass es zwei Möglichkeiten gibt, um Pakete aus einem internen Repository herunterzuladen:
In der Dokumentation steht:
Wie Sie sehen können, gibt es einen kleinen Unterschied zwischen den beiden, der auf den ersten Blick nicht offensichtlich ist. Der Unterschied besteht darin, dass Sie bei der Angabe der --index-url Option, pip würde nur Pakete aus dem Repository mit der von Ihnen angegebenen URL beziehen, nicht aber aus öffentlichen Repositorys. Wenn Sie also das oben beschriebene Verhalten vermeiden wollen, verwenden Sie --index-url statt --extra-index-url und Sie werden sicher sein!
Um die neuesten Sicherheitslücken zu verfolgen, die in Ihren Abhängigkeiten entdeckt werden, können Sie regelmäßig die GitHub-Advisory-Datenbank überprüfen oder, noch besser, Tools wie dependabot nutzen, die automatisch einen Pull-Request für Ihr Repo einreichen, um eine Abhängigkeit zu aktualisieren, in der kürzlich eine kritische Sicherheitslücke entdeckt wurde.
Zusammenfassung
In diesem Artikel haben wir das Konzept der Lieferkette für die Software-Welt vorgestellt. Wir haben speziell untersucht, wie dieses Konzept auf das Python-Ökosystem anwendbar ist. Typo-Squatting und Abhängigkeitsverwirrung wurden erklärt und Lösungen vorgeschlagen, um das Risiko einer Gefährdung zu mindern.
Diese kurze Einführung in die Sicherheit der Lieferkette deckte nur die Spitze des Eisbergs ab. Wir hatten nicht die Gelegenheit, zu erörtern, wie Build-Systeme oder sogar Ihre IDEs kompromittiert werden können, aber das lasse ich für einen anderen Artikel!
Danke, dass Sie so weit gelesen haben! Ich würde mich freuen, Ihr Feedback zu hören. Wenn Ihnen die Lektüre gefallen hat, schauen Sie doch mal bei unseren offenen Stellen unter Artefact vorbei 🙂
