Die Entwickler des Python-Paket-Repositorys PyPI (Python Package Index) haben die Einführung eines digitalen Zertifizierungsmechanismus zur Überprüfung der Authentizität veröffentlichter Pakete angekündigt, der die vorherige Verifizierung mittels PGP-Signaturen ersetzt. Ein entscheidendes Unterscheidungsmerkmal der Zertifizierung besteht darin, dass die Veröffentlichung eines Pakets nicht vom Entwickler, sondern von einer dritten Partei (dem Paketverzeichnis) nach Bestätigung der Richtigkeit der Veröffentlichung über einen externen OpenID Connect-Anbieter (zum Beispiel nach Überprüfung, dass das veröffentlichte Paket mit dem zugehörigen Repository auf GitHub oder GitLab übereinstimmt) beglaubigt wird.
Das Zertifizierungssystem beseitigt die Mängel, die dem Verifizierungsmechanismus durch PGP-Signaturen eigen sind, der zuvor von PyPI als veraltet erklärt wurde. Diese Entscheidung wurde aufgrund von Problemen bei der Überprüfung der Zuordnung von Entwicklern zu den OpenPGP-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 genutzt wurden, waren 29 % der offenen Schlüssel auf großen öffentlichen Schlüsselservern nicht vorhanden. Servern 35 % der Schlüssel konnten während eines Audits nicht bestätigt werden. Dabei umfassten die bestätigten 36 % der PGP-Schlüssel lediglich 0,3 % aller signierten Dateien.
Im neuen System werden die zur Beglaubigung von Paketen verwendeten Signaturen mit kurzlebigen, ephemeral Schlüssel erstellt, die auf Basis von Berechtigungen generiert werden, die von OpenID Connect-Anbietern bestätigt werden. Zum Zeitpunkt der Schlüsselgenerierung, die zur Erstellung einer digitalen Signatur erforderlich sind, 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 Systems Sigstore und des in-toto Ataestationsrahmenwerks aufgebaut.
Zu den Vorteilen der Zertifizierung zählt die Unabhängigkeit von permanenten PGP-Schlüsseln – der Verlust oder die Kompromittierung des privaten Schlüssels zerstört das Vertrauen in die auf seiner Grundlage erstellten Signaturen, während bei der Zertifizierung die Signatur in Verbindung mit einem Token erstellt wird, das die Autorität zum Zeitpunkt der Paketplatzierung bestätigt und die Verbindung des Pakets mit dem Hauptrepository und dem Code herstellt. Beispielsweise bestimmt die Zertifizierung beim Veröffentlichen eines über GitHub Actions vorbereiteten Pakets die überprüfbare und bestätigte Verbindung zwischen der in PyPI veröffentlichten Datei, dem Repository, dem Workflow-Prozess und dem Commit-Hash, auf dessen Grundlage das Paket erstellt wurde.
Zur Überwachung der Authentizität der Schlüssel und zur Aufdeckung möglicher Kompromittierungen wird ein öffentlicher zentralisierter Log zur Erstellung von Projektpaketen sowie für PyPI verwendet, um die Integrität zu gewährleisten und vor nachträglicher Datenkorruption zu schützen. Dabei kommt eine Struktur namens „Merkle-Baum“ (Merkle Tree) zum Einsatz, bei der jeder Branch alle darunter liegenden Branches und Knoten durch baumartige Hashing-Methoden verifiziert.
Zusätzlich ist das Auftreten des bösartigen Pakets „fabrice“ im PyPI-Verzeichnis zu erwähnen, das durch Typosquatting (die Vergabe ähnlicher Namen, die sich nur durch einzelne Zeichen unterscheiden, z. B. exampl statt example, djangoo statt django, pyhton statt python usw.) als beliebte Bibliothek „fabric“ maskiert wurde, die 201 Millionen Downloads (7 Millionen Downloads im letzten Monat) aufweisen kann. Das bösartige Paket blieb seit 2021 unbemerkt und wurde seitdem mehr als 37.000 Mal heruntergeladen.
Das Paket „fabrice“ wiederholte die grundlegende Funktionalität der ursprünglichen Bibliothek und beinhaltete zusätzlich einen Code zur Aufdeckung und zum Versand von Schlüsseln für den Zugriff auf AWS (Amazon Web Services), zur Installation eines Backdoors und zur Ausführung bestimmter Skripte. Die Aktivierung der bösartigen Komponenten erfolgte in Linux und Windows. In Linux wurden die mit schädlichen Aktivitäten verbundenen Dateien in das Verzeichnis ~/.local/bin/vscode hochgeladen.
Quelle: opennet.ru
