De ontwikkelaars van de Python-pakketrepository PyPI (Python Package Index) kondigden de introductie aan van ondersteuning voor een digitaal attesteringsmechanisme om de authenticiteit van gepubliceerde pakketten te verifiëren, ter vervanging van verificatie met behulp van PGP-handtekeningen. Het belangrijkste verschil met attestation is dat de publicatie van een pakket niet wordt geverifieerd door de ontwikkelaar, maar door een derde partij (de pakketdirectory) nadat de juistheid van de publicatie is bevestigd via een externe OpenID Connect-provider (bijvoorbeeld nadat is geverifieerd dat de gepubliceerd pakket komt overeen met de bijbehorende repository op GitHub of GitLab).
Het attestatiesysteem pakt de tekortkomingen aan van het PGP-handtekeningverificatiemechanisme, dat eerder op PyPI was afgekeurd. Deze beslissing werd genomen vanwege problemen met het verifiëren van het eigendom van de openbare PGP-sleutels die werden gebruikt om digitale handtekeningen te verifiëren. Van de 1069 PGP-sleutels die sinds 2020 op PyPI zijn gebruikt om handtekeningen te genereren, ontbrak 29% van de openbare sleutels in de lijst met belangrijkste openbare sleutels. servers sleutels, en 35% van de sleutels kon niet worden geverifieerd tijdens de audit. Bovendien dekte de 36% van de geverifieerde PGP-sleutels slechts 0.3% van alle ondertekende bestanden.
In het nieuwe systeem worden handtekeningen die worden gebruikt om pakketten te verifiëren aangemaakt met behulp van kortstondige sleutels die zijn gegenereerd op basis van inloggegevens die zijn geverifieerd door OpenID Connect-providers. Op het moment dat de sleutels worden gegenereerd die nodig zijn om een digitale handtekening te maken, identificeert de ontwikkelaar zichzelf via de OpenID-provider, waarmee hij zijn verbinding met het hoofdproject bevestigt. De infrastructuur voor digitale certificering is gebouwd met behulp van het Sigstore-systeem en de in-toto Attestation Framework-tools.
Een van de voordelen van attestation is de afwezigheid van binding aan permanente PGP-sleutels - het verlies of het compromitteren van een privésleutel vernietigt het vertrouwen in de handtekeningen die op basis daarvan zijn gecreëerd, terwijl tijdens attestation de handtekening wordt gevormd in verband met een token dat de autoriteit op het moment van plaatsing van het pakket en de verbinding van het pakket met de hoofdrepository met code. Wanneer u bijvoorbeeld een pakket publiceert dat is voorbereid via GitHub Action, definieert attestation een verifieerbare en bevestigde relatie tussen het bestand dat wordt gehost in PyPI, de repository, de workflow en de commit-hash waaruit het pakket is gegenereerd.
Om de authenticiteit van sleutels te volgen en mogelijke compromissen te identificeren, wordt een openbaar gecentraliseerd logboek gebruikt om pakketten van projecten en PyPI zelf te vormen. Om achteraf de integriteit en bescherming tegen datacorruptie te garanderen, wordt de Merkle Tree-structuur gebruikt (elke vertakking verifieert alle onderliggende vertakkingen). en knooppunten dankzij boomhashing).
Bovendien kunnen we de identificatie van een kwaadaardig pakket “fabrice” in de PyPI-directory noteren, dat met behulp van typosquatting (het toewijzen van vergelijkbare namen die verschillen in individuele tekens, bijvoorbeeld example in plaats van example, djangoo in plaats van django, pyhton in plaats van python , enz.) was vermomd als een populaire bibliotheek-“stof” met 201 miljoen downloads (7 miljoen downloads vorige maand). Het kwaadaardige pakket is sinds 2021 onopgemerkt gebleven en is sindsdien ruim 37 duizend keer gedownload.
Het "fabrice"-pakket reproduceerde de basisfunctionaliteit van de originele bibliotheek en bevatte daarnaast code voor het detecteren en verzenden van sleutels naar externe hosts voor toegang tot AWS (Amazon Web Services), het installeren van een backdoor en het uitvoeren van specifieke scripts. De kwaadaardige componenten werden geactiveerd in Linux и Windows. In Linux Bestanden die verband houden met kwaadwillige activiteiten zijn gedownload naar de map ~/.local/bin/vscode.
Bron: opennet.ru
