Die Entwickler des Python-Paket-Repositorys PyPI (Python Package Index) haben die Einführung eines digitalen Zertifizierungsmechanismus bekannt gegeben, um die Authentizität veröffentlichter Pakete zu überprüfen. Dieser ersetzt die vorherige Verifizierung mittels PGP-Signaturen. Ein wesentlicher Unterschied der Zertifizierung ist, dass die Veröffentlichung eines Pakets nicht vom Entwickler selbst, sondern von einer dritten Partei (dem Paketkatalog) nach Überprüfung der Richtigkeit der Veröffentlichung über einen externen Anbieter von OpenID Connect (z.B. nach der Überprüfung, dass das veröffentlichte Paket mit dem zugehörigen Repository auf GitHub oder GitLab übereinstimmt) bescheinigt wird.
Das Zertifizierungssystem beseitigt die Nachteile, die mit dem Mechanismus zur Verifizierung mittels PGP-Signaturen verbunden sind, der zuvor in PyPI als veraltet angesehen wurde. Diese Entscheidung wurde aufgrund der Probleme bei der Überprüfung der Zuordnung von Entwicklern zu den öffentlichen PGP-Schlüsseln getroffen, die zur Überprüfung digitaler Signaturen verwendet wurden – von 1069 PGP-Schlüsseln, die seit 2020 zur Erstellung von Signaturen in PyPI verwendet wurden, fehlten 29 % der öffentlichen Schlüssel in großen öffentlichen Verzeichnissen. Servern Schlüssel, wobei sich 35% der Schlüssel während des Audits als nicht verifizierbar erwiesen. Die bestätigten 36% der PGP-Schlüssel deckten jedoch nur 0,3% aller signierten Dateien ab.
Im neuen System werden die zur Bestätigung von Paketen verwendeten Signaturen mit kurzlebigen, temporären Schlüsseln erstellt, die auf der von OpenID Connect-Anbietern bestätigten Berechtigung basieren. Zum Zeitpunkt der Generierung der für die Erstellung der digitalen Signatur erforderlichen Schlüssel identifiziert sich der Entwickler über den OpenID-Anbieter, der seine Verbindung zum Hauptprojekt bestätigt. Die Infrastruktur für die digitale Zertifizierung wurde mithilfe des Sigstore-Systems und des in-toto Attestation Frameworks aufgebaut.
Ein Vorteil der Zertifizierung ist, dass sie nicht an permanente PGP-Schlüssel gebunden ist. Der Verlust oder die Kompromittierung des privaten Schlüssels untergräbt das Vertrauen in die darauf basierenden Signaturen. Bei der Zertifizierung hingegen wird die Signatur in Verbindung mit einem Token erzeugt, das die Berechtigung zum Zeitpunkt der Paketplatzierung bestätigt und die Verbindung zwischen dem Paket und dem Haupt-Repository mit dem Code herstellt. Zum Beispiel bestimmt die Zertifizierung bei der Veröffentlichung eines über GitHub Action vorbereiteten Pakets die überprüfbare und bestätigte Verbindung zwischen der im PyPI veröffentlichten Datei, dem Repository, dem Workflow-Prozess und dem Hash des Commits, auf dessen Grundlage das Paket erstellt wurde.
Um die Authentizität der Schlüssel zu verfolgen und mögliche Kompromittierungen zu erkennen, wird ein öffentlicher zentralisierter Log für die Erzeugung von Projektpaketen und für PyPI selbst verwendet. Zur Gewährleistung der Integrität und zum Schutz vor nachträglichen Datenverfälschungen wird dabei die Struktur eines „Merkle-Baums“ (Merkle Tree) eingesetzt, wobei jeder Ast alle darunter liegenden Äste und Knoten mithilfe von baumförmigem Hashing verifiziert.
Zusätzlich wurde ein bösartiges Paket mit dem Namen „fabrice“ im PyPI-Katalog entdeckt. Dieses Paket maskierte sich durch Typ-Squatting (Vergabe ähnlicher Namen, die sich nur durch einzelne Zeichen unterscheiden, zum Beispiel exampl statt example, djangoo statt django, pyhton statt python usw.) als beliebte Bibliothek „fabric“, die 201 Millionen Downloads verzeichnete (7 Millionen Downloads im letzten Monat). Das bösartige Paket blieb seit 2021 unbemerkt und wurde seitdem über 37.000 Mal heruntergeladen.
Das Paket „fabrice“ wiederholte die grundlegende Funktionalität der Originalbibliothek und beinhaltete zusätzlich Code, um Schlüssel für den Zugriff auf AWS (Amazon Web Services) zu entdecken und an externe Hosts zu senden, Backdoors einzurichten und bestimmte Skripte auszuführen. Die Aktivierung der bösartigen Komponenten geschah sowohl in Linux als auch in Windows. In Linux wurden mit bösartiger Aktivität verbundene Dateien im Verzeichnis ~/local/bin/vscode hochgeladen.
Quelle: opennet.ru
