Les développeurs du dépôt de paquets Python, PyPI (Python Package Index), ont annoncé l'introduction d'un mécanisme de certification numérique pour vérifier l'authenticité des paquets publiés, remplaçant ainsi la vérification via des signatures PGP. La principale distinction de cette certification est que la publication d'un paquet est validée non par le développeur, mais par un tiers (le catalogue de paquets) après vérification de l'authenticité de la publication par un fournisseur externe d'OpenID Connect (par exemple, après avoir vérifié que le paquet publié correspond à son dépôt associé sur GitHub ou GitLab).
Le système de certification élimine les défauts inhérents au mécanisme de vérification par signatures PGP, qui a précédemment été déclaré obsolète dans PyPI. Cette solution a été adoptée en raison des problèmes rencontrés pour vérifier la propriété des clés PGP ouvertes utilisées pour valider les signatures numériques : sur 1069 clés PGP utilisées depuis 2020 pour former des signatures dans PyPI, 29 % des clés ouvertes étaient absentes sur les grands répertoires publics. serveurs Quant aux clés, 35 % d'entre elles se sont avérées impossibles à confirmer lors de l'audit. Au total, les 36 % de clés PGP confirmées ne couvraient que 0,3 % de tous les fichiers signés.
Dans le nouveau système, les signatures utilisées pour garantir les paquets sont créées à l'aide de clés éphémères à courte durée de vie, générées sur la base des autorisations validées par des fournisseurs d'OpenID Connect. Au moment de la génération des clés nécessaires à la création de la signature numérique, le développeur s'identifie via un fournisseur OpenID, qui confirme son lien avec le projet principal. L'infrastructure pour la certification numérique est construite à l'aide du système Sigstore et du cadre d'attestation in-toto.
Parmi les avantages de l'attestation, on note l'absence de lien avec des clés PGP permanentes — la perte ou la compromission de la clé privée détruit la confiance dans les signatures qui en découlent, tandis qu'avec l'attestation, la signature est générée en lien avec un jeton confirmant les droits au moment de la publication du paquet et le lien entre le paquet et le dépôt principal contenant le code. Par exemple, lors de la publication d'un paquet préparé via GitHub Action, l'attestation définit un lien vérifiable et confirmé entre le fichier déposé sur PyPI, le dépôt, le processus de workflow et le hash du commit à partir duquel le paquet a été créé.
Pour suivre l'authenticité des clés et détecter d'éventuelles compromissions, un registre public centralisé est utilisé pour la création de paquets de projets et de PyPI lui-même, afin d'assurer l'intégrité et de protéger contre la falsification des données rétroactivement, impliquant une structure d'arbre Merkle (Merkle Tree, chaque branche vérifiant toutes les branches et nœuds inférieurs grâce au hachage en arbre).
On peut également relever la détection dans le répertoire PyPI d'un paquet malveillant «fabrice», qui, par le biais de type-squatting (attribution de noms similaires, se différenciant par quelques symboles, par exemple, exampl au lieu de example, djangoo au lieu de django, pyhton au lieu de python, etc.), se dissimulait derrière la populaire bibliothèque «fabric», qui compte 201 millions de téléchargements (7 millions de téléchargements le mois dernier). Ce paquet malveillant est passé inaperçu depuis 2021 et a depuis été téléchargé plus de 37 000 fois.
Le paquet «fabrice» répétait la fonctionnalité de base de la bibliothèque source et incluait également du code pour détecter et envoyer des clés d'accès à AWS (Amazon Web Services) à des hôtes externes, installer un backdoor et exécuter certains scripts. L'activation des composants malveillants se produisait sous Linux et Windows. Sous Linux, les fichiers liés à l'activité malveillante étaient chargés dans le répertoire ~/.local/bin/vscode.
Source : opennet.ru
