Katalogen PyPI har implementerat ett nytt paketautentiseringssystem

Utvecklarna av Python-paketförrådet PyPI (Python Package Index) har meddelat att de har infört stöd för en mekanism för digital certifiering för att verifiera äktheten av publicerade paket, vilken ersätter verifieringen med användning av PGP-signaturer. En nyckelskillnad med certifiering är att paketpubliceringen intygar sig inte av utvecklaren, utan av en tredje part (paketkatalogen) efter bekräftelse av publiceringens giltighet via en extern leverantör av OpenID Connect (till exempel efter att ha bekräftat att det publicerade paketet motsvarar det associerade förrådet på GitHub eller GitLab).

Certifieringssystemet åtgärdar de brister som var förknippade med mekanismen för verifiering via PGP-signaturer, som tidigare hade deklarerats som föråldrad i PyPI. Detta beslut togs på grund av problemen med att verifiera tillhörigheten av utvecklarnas öppna PGP-nycklar som användes för att kontrollera digitala signaturer — av 1069 PGP-nycklar som använts sedan 2020 för att bilda signaturer i PyPI, saknades 29% av de öppna nycklarna på större offentliga nyckelservrar, och 35% av nycklarna kunde inte bekräftas under granskningen. Det bekräftade 36% PGP-nycklarna täckte endast 0,3% av alla signerade filer. servrar I det nya systemet skapas de signaturer som används för att bekräfta paket med hjälp av kortlivade tillfälliga nycklar som genereras baserat på behörigheter som bekräftas av leverantörer av OpenID Connect. Vid genereringen av nycklarna, som krävs för att skapa den digitala signaturen, identifierar utvecklaren sig genom en OpenID-leverantör som bekräftar hans koppling till det huvudsakliga projektet. Infrastrukturen för digital certifiering är byggd med hjälp av systemet Sigstore och verktygen in-toto Attestation Framework.

I det nya systemet skapas de signaturer som används för att bekräfta paket med hjälp av kortlivade tillfälliga nycklar, vilka genereras utifrån rättigheter bekräftade av OpenID Connect-leverantörer. Vid den tidpunkt nycklarna genereras, som behövs för att skapa den digitala signaturen, identifierar utvecklaren sig via en OpenID-leverantör som bekräftar hans koppling till det huvudsakliga projektet. Infrastrukturen för digital certifiering är byggd med hjälp av systemet Sigstore och in-toto Attestation Framework.

Bland fördelarna med certifieringen nämns avsaknaden av bindning till permanenta PGP-nycklar – förlust eller kompromiss av privatnyckeln undergräver förtroendet för de signerade meddelandena som skapats på den, medan i certifieringen skapas signaturen i samband med en token som bekräftar befogenheten vid tidpunkten för paketets publicering och kopplingen mellan paketet och det primära koden i förvaret. Till exempel, vid publicering av ett paket förberett via GitHub Action, fastställer certifiering en verifierbar och bekräftad koppling mellan filen som publiceras i PyPI, förvaret, arbetsflödet och hash av commit som paketet skapades på.

För att spåra äktheten av nycklar och identifiera möjliga kompromisser används en offentlig centraliserad logg för att skapa paket av projekten och PyPI själv, för att säkerställa integritet och skydd mot bakåtgående datamanipulation som involverar strukturen "Merkle-träd" (Merkle Tree, där varje gren verifierar alla undre grenar och noder tack vare trädformad hashning).

Dessutom kan man notera upptäckten i katalogen PyPI av det skadliga paketet "fabrice", som genom typesquatting (tilldelning av liknande namn som skiljer sig åt med enskilda tecken, till exempel, exampl istället för example, djangoo istället för django, pyhton istället för python osv.) maskerade sig som det populära biblioteket "fabric", som har 201 miljoner nedladdningar (7 miljoner nedladdningar den senaste månaden). Det skadliga paketet förblev obemärkt sedan 2021 och hade sedan dess laddats ner över 37 000 gånger.

Paketet "fabrice" replikerade den grundläggande funktionaliteten hos det ursprungliga biblioteket och innehöll dessutom kod för att upptäcka och skicka nycklar för åtkomst till AWS (Amazon Web Services) till externa värdar, installera en bakdörr och köra vissa skript. Aktiveringen av skadliga komponenter skedde i Linux och Windows. I Linux laddades filer relaterade till den skadliga aktiviteten ner till katalogen ~/.local/bin/vscode.

Källa: opennet.ru