Le Python Package Index (PyPI) a annonc qu’il exigera que chaque compte qui gre un projet sur la plateforme ait activ l’authentification deux facteurs (2FA) d’ici la fin de l’anne. PyPI est un rfrentiel de logiciels pour les packages crs dans le langage de programmation Python. L’index hberge 200 000 packages, ce qui permet aux dveloppeurs de trouver des packages existants qui rpondent aux diverses exigences du projet et d’conomiser du temps et des efforts.
L’quipe PyPI affirme que la dcision de rendre la 2FA obligatoire sur tous les comptes fait partie de leur engagement long terme amliorer la scurit sur la plateforme, en complment des mesures prcdentes prises dans cette direction, comme le blocage des informations d’identification compromises et la prise en charge des jetons d’API.
L’un des avantages de la protection 2FA est le risque rduit d’attaques de la chane d’approvisionnement. Ces types d’attaques se produisent lorsqu’un acteur malveillant prend le contrle du compte d’un mainteneur de logiciel et ajoute une porte drobe ou un logiciel malveillant un package utilis comme dpendance dans divers projets logiciels.
Selon la popularit du package, de telles attaques peuvent avoir un impact sur des millions d’utilisateurs. Alors que les dveloppeurs sont responsables d’inspecter minutieusement les lments constitutifs de leur projet, la mesure de PyPI devrait permettre de minimiser plus facilement ce type de problme.
De plus, le rfrentiel du projet Python a souffert de tlchargements de logiciels malveillants effrns, d’une usurpation d’identit de package clbre et de la nouvelle soumission de code malveillant l’aide de comptes pirats au cours des derniers mois.
Le problme a atteint une telle ampleur qu’il y a quelques jours, PyPI a d suspendre temporairement les enregistrements de nouveaux utilisateurs et projets jusqu’ ce qu’une solution de dfense efficace puisse tre dveloppe et mise en uvre.
La protection 2FA aidera attnuer le problme des attaques de prise de contrle de compte et devrait galement fixer une limite sur le nombre de nouveaux comptes qu’un utilisateur suspendu peut crer pour tlcharger nouveau des packages malveillants.
La rapparition des logiciels malveillants persiste sur PyPI
Plus tt ce mois-ci, un acteur malveillant sur GitHub a ajout ses rfrentiels des logiciels malveillants crits en Python et hbergs sur PyPI. Quelques minutes aprs la suppression de son malware de PyPI, le mme malware rapparat sur PyPI sous un nom lgrement diffrent. Il met ensuite immdiatement jour tous ses rfrentiels pour pointer vers ce nouveau package. La plupart de ses projets GitHub sont des bots ou une varit de logiciels malveillants.
Ci-dessous, un extrait du billet de la socit de cyberscurit Phylum.
Patrick Pogoda annonce des rfrentiels douteux sur sa page GitHub. Certains de ces projets Python crent des robots Discord, Telegram et Twitter. D’autres sont des attrapeurs de jetons manifestes qui volent des utilisateurs sans mfiance.
Plus rcemment, il a cr un package pour interagir avec ChatGPT, probablement pour surfer sur la rcente vague d’intrt pour l’IA et les grands modles de langage (LLM).
Une inspection du code montre que le package semble contenir du code lgitime pour interagir avec ChatGPT comme annonc. Il est important de noter que ce dpt GitHub est diffrent du chatgpt-api sur PyPI.
Annonce de PyPI
L’une des principales promesses de scurit de PyPI est que lorsque vous tlchargez quelque chose, seules les personnes associes ce projet pourront tlcharger, supprimer ou modifier un projet. Que lorsque vous regardez ce projet et que vous voyez qu’il appartient quelqu’un en qui vous avez confiance, vous pouvez tre assur que personne d’autre n’apporte de modifications ce package sur PyPI.
Cette promesse repose sur la scurit de chaque compte individuel sur PyPI utilis pour crer et maintenir un projet Python. Dans le pass, nous avons pris des mesures pour protger ces comptes en bloquant les mots de passe compromis, une prise en charge 2FA renforce l’aide de TOTP et WebAuthN, la prise en charge des jetons d’API avec attnuation hors ligne, l’inscription des projets les plus tlchargs dans la 2FA obligatoire et l’activation des jetons de courte dure pour le tlchargement.
Aujourd’hui, dans le cadre de cet effort long terme pour scuriser l’cosystme Python, nous annonons que chaque compte qui maintient un projet ou une organisation sur PyPI devra activer 2FA sur son compte d’ici la fin de 2023.
D’ici la fin de l’anne, PyPI commencera bloquer l’accs certaines fonctionnalits du site en fonction de l’utilisation de 2FA. En outre, nous pouvons commencer slectionner certains utilisateurs ou projets pour une application anticipe.
Que puis-je faire pour me prparer ?
Les choses les plus importantes que vous pouvez faire pour vous prparer sont d’activer 2FA pour votre compte ds que possible, soit avec un dispositif de scurit (prfr) ou une application d’authentification et de passer l’utilisation d’diteurs de confiance (prfrs) ou de jetons API pour tlcharger sur PyPI.
Pourquoi utiliser 2FA ?
Les attaques de prise de contrle de compte proviennent gnralement de quelqu’un qui utilise un mot de passe non scuris : peut-tre tait-il facile deviner, ou il a t rutilis et est apparu dans une brche. Avec ce mot de passe non scuris, un attaquant peut prendre le contrle d’un compte de responsable et commencer agir comme s’il tait cet utilisateur.
Cela est particulirement problmatique sur un site comme PyPI, o les actions qu’une personne peut entreprendre incluent la publication de logiciels pouvant tre utiliss par des personnes du monde entier, permettant un attaquant d’installer et d’excuter des logiciels sur les ordinateurs d’utilisateurs sans mfiance. Les attaques de prise de contrle de compte ont dj t utilises pour compromettre les utilisateurs de PyPI de cette manire.
L’authentification deux facteurs neutralise immdiatement le risque associ un mot de passe compromis. Si un attaquant a le mot de passe de quelqu’un, cela ne suffit plus pour lui donner accs ce compte.
Pourquoi chaque mainteneur de projet ou d’organisation ?
Il y a deux faons de penser cette question :
- Pourquoi chaque mainteneur de projet et d’organisation au lieu d’un sous-ensemble d’entre eux (bas sur la popularit, le but, si cet utilisateur utilise son compte, etc.) ?
- Pourquoi uniquement les mainteneurs et pas tous les utilisateurs ?
Tous les comptes sur PyPI n’ont pas la mme valeur pour un attaquant. Un compte ayant accs au projet le plus tlcharg sur PyPI peut tre utilis pour attaquer beaucoup plus de personnes qu’un compte ayant accs au projet le moins tlcharg.
Cependant, il suffit d’un seul projet compromis dans l’ensemble de dpendances de quelqu’un pour compromettre son ordinateur. L’attaquant ne se soucie pas de savoir s’il vous obtient d’un projet largement utilis ou d’un projet de niche, juste qu’il vous a obtenu. Pire encore, une fois compromis, un attaquant peut tendre cette attaque pour attaquer d’autres systmes, y compris d’autres projets sur PyPI que la personne dsormais compromise maintient.
tant donn qu’il suffit d’un seul projet compromis, quel que soit le nombre de tlchargements qu’il obtient 1, pour compromettre quelqu’un, nous voulons nous assurer que chaque projet est protg par 2FA.
D’un autre ct, un compte sans accs aucun projet ne peut tre utilis pour attaquer qui que ce soit 2, c’est donc une cible de trs faible valeur.
Nous reconnaissons que l’activation de 2FA pour un compte impose un cot non nul la fois pour le propritaire de ce compte et pour PyPI 3, donc forcer cela sur des comptes qui ne peuvent affecter personne d’autre qu’eux-mmes n’est pas une utilisation efficace de ressources limites. De plus, d’un point de vue pratique, le flux 2FA standard auquel la plupart des gens sont habitus et que PyPI implmente implique galement l’ajout d’un jeton 2FA un compte existant plutt que de le forcer faire partie du flux d’enregistrement.
Les dveloppeurs estiment que c’est un pas dans la bonne direction
La nouvelle a plutt t bien accueillie par les dveloppeurs. Un professionnel indique : C’est bien. Vous ne devriez pas publier de logiciels utiliser par d’autres dans un tel rfrentiel de logiciels, si vous n’utilisez mme pas des lments de scurit de base comme 2FA .
Un autre estime que PyPI peut mieux faire en matire de scurit :
Bien sr [c’est bien]. Mais j’espre que quiconque publie un logiciel pour d’autres fait quelque chose de plus en matire de scurit que juste la 2FA.
La 2FA ne rsout pas les pots de miel. Cela ne rsout pas les imposteurs de nom de package. Cela ne rsout pas directement le cas o dveloppeur empoisonne dlibrment ses versions. Cela n’impose aucune sorte de rvision de code. Tout ce que la 2FA fait, c’est valider l’entit qui se connecte et publie la version ; cela ne dit rien de la diligence raisonnable du dveloppeur qui fait la publication.
La 2FA est un geste symbolique – mais elle ne rsout pas les divers problmes auxquels les rfrentiels binaires et de packages sont tous confronts
.
Et un autre de dclarer :
Mandater la 2FA pour les utilisateurs est formidable.
Maintenant, le plus gros problme, ce sont les jetons API. Vous pouvez les gnrer, les stocker dans des endroits, puis vous venez de dplacer votre risque de mot de passe vers quelque chose nomm diffremment, c’est–dire un jeton API.
GitHub slectionne dsormais par dfaut les jetons bass sur le temps, afin qu’ils expirent. Et ceux-ci ne sont pas gniaux non plus, car ils provoquent essentiellement la rupture des choses des moments alatoires lorsque vous ne vous y attendez pas.
D’un autre ct, les jetons d’API permanents, valables jusqu’ leur rvocation, risquent de faire l’objet d’une fuite, surtout si quelqu’un publie depuis son propre ordinateur. Si vous faites cela via un processus CI, vous pourriez toujours avoir (et cela s’est produit) une fuite car un autre outil / package malveillant pourrait envoyer un dump de votre environnement un point de terminaison fourre-tout.
Je ne critique pas PyPI, la scurit est excellente, je reconnais simplement que ce n’est pas une solution parfaite.
Une chose qui aiderait renforcer les choses est de s’assurer que l’approbation finale dans PyPI est effectue par un utilisateur. Par exemple. chaque package publi doit tre approuv par l’un des administrateurs.
Mais ensuite, quelqu’un crira un script autour de cela et le publiera sur PyPI.
Et vous ?
Que pensez-vous de cette dcision de PyPI ?
Que pensez-vous des propos des dveloppeurs qui estiment que la mesure est loin d’tre suffisante en matire de scurit ?
Voir aussi :