De ontwikkelaars van de Python-pakkettenrepository PyPI (Python Package Index) hebben aangekondigd dat ze digitale certificering zullen ondersteunen voor de authenticatie van gepubliceerde pakketten, ter vervanging van de verificatie met PGP-handtekeningen. Een belangrijk kenmerk van de certificering is dat de publicatie van een pakket niet door de ontwikkelaar wordt bevestigd, maar door een derde partij (een pakkettencatalogus) nadat de echtheid van de publicatie is gecontroleerd via een externe provider van OpenID Connect (bijvoorbeeld na bevestiging dat het gepubliceerde pakket overeenkomt met de bijbehorende repository op GitHub of GitLab).
Het certificeringssysteem verhelpt de tekortkomingen van het PGP-handtekeningenverificatiemechanisme, dat eerder in PyPI verouderd werd verklaard. Deze oplossing is aangenomen vanwege problemen met de authenticatie van ontwikkelaars van open PGP-sleutels die worden gebruikt voor de verificatie van digitale handtekeningen ā van de 1069 PGP-sleutels die sinds 2020 zijn gebruikt voor het maken van handtekeningen in PyPI, ontbraken 29% van de openbare sleutels op belangrijke openbare sleutels, en 35% van de sleutels kon niet worden bevestigd tijdens een audit. servers Van de bevestigde 36% PGP-sleutels dekte slechts 0,3% van alle ondertekende bestanden.
In het nieuwe systeem worden de handtekeningen die voor de certificering van pakketten worden gebruikt, gemaakt met behulp van kortlevende ephemeral sleutels die zijn gegenereerd op basis van bevoegdheden die zijn bevestigd door OpenID Connect-providers. Op het moment van het genereren van de sleutels die nodig zijn voor het maken van de digitale handtekening, identificeert de ontwikkelaar zich via de OpenID-provider, die zijn verband met het hoofdproject bevestigt. De infrastructuur voor digitale certificering is opgebouwd met behulp van het Sigstore-systeem en de in-toto Attestation Framework-toolset.
Een van de voordelen van certificering is dat er geen behoefte is aan permanente PGP-sleutels. Het verlies of de compromittering van een privƩsleutel schaadt het vertrouwen in de ondertekeningen die daarop zijn gebaseerd, terwijl bij certificering de handtekening wordt gevormd in verband met een token, dat de bevoegdheden bevestigt op het moment van het plaatsen van het pakket en de verbinding tussen het pakket en het hoofrepo met de code. Bijvoorbeeld, bij het publiceren van een pakket dat is voorbereid via GitHub Action, definieert certificering een verifieerbare en bevestigde verbinding tussen het bestand dat in PyPI is geplaatst, de repository, het workflowproces en de commit-hash waarop het pakket is gebaseerd.
Voor het volgen van de authenticiteit van sleutels en het identificeren van mogelijke compromitteringen, wordt een openbare gecentraliseerde logboek gebruikt voor het creƫren van projectpakketten en PyPI zelf. Dit logboek waarborgt de integriteit en biedt bescherming tegen gegevensmanipulatie achteraf, waarbij een "Merkle-boom" structuur gebruikt wordt (Elke tak verifieert alle onderliggende takken en knooppunten dankzij boom-hashing).
Daarnaast kan worden opgemerkt dat in de PyPI-catalogus een kwaadaardig pakket "fabrice" is ontdekt, dat zich door middel van typosquatting (toekenning van vergelijkbare namen met een verschil in enkele symbolen, bijvoorbeeld, exampl in plaats van example, djangoo in plaats van django, pyhton in plaats van python, enzovoort) heeft vermomd als de populaire bibliotheek "fabric", die 201 miljoen downloads heeft (7 miljoen downloads in de afgelopen maand). Dit kwaadaardige pakket bleef onopgemerkt sinds 2021 en is sindsdien meer dan 37 duizend keer gedownload.
Het pakket "fabrice" herhaalde de basisfunctionaliteit van de originele bibliotheek en voegde extra code toe voor het detecteren en verzenden van toegangssleutels naar AWS (Amazon Web Services), het installeren van een backdoor en het uitvoeren van specifieke scripts. De activatie van de kwaadaardige componenten vond plaats in Linux en Windows. In Linux werden de bestanden die verband hielden met kwaadaardige activiteiten gedownload naar de map ~/.local/bin/vscode.
Bron: opennet.ru
