Le Python Package Index (PyPI) a annoncé qu'il exigera que chaque compte qui gère un projet sur la plateforme ait activé l'authentification à deux facteurs (2FA) d'ici la fin de l'année. PyPI est un référentiel de logiciels pour les packages créés dans le langage de programmation Python. L'index héberge 200 000 packages, ce qui permet aux développeurs de trouver des packages existants qui répondent aux diverses exigences du projet et d'économiser du temps et des efforts.L'équipe PyPI affirme que la décision de rendre la 2FA obligatoire sur tous les comptes fait partie de leur engagement à long terme à améliorer la sécurité sur la plateforme, en complément des mesures précédentes 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 réduit d'attaques de la chaîne d'approvisionnement. Ces types d'attaques se produisent lorsqu'un acteur malveillant prend le contrôle du compte d'un mainteneur de logiciel et ajoute une porte dérobée ou un logiciel malveillant à un package utilisé comme dépendance dans divers projets logiciels.
Selon la popularité du package, de telles attaques peuvent avoir un impact sur des millions d'utilisateurs. Alors que les développeurs sont responsables d'inspecter minutieusement les éléments constitutifs de leur projet, la mesure de PyPI devrait permettre de minimiser plus facilement ce type de problème.
De plus, le référentiel du projet Python a souffert de téléchargements de logiciels malveillants effrénés, d'une usurpation d'identité de package célèbre et de la nouvelle soumission de code malveillant à l'aide de comptes piratés au cours des derniers mois.
Le problème 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 défense efficace puisse être développée et mise en œuvre.
La protection 2FA aidera à atténuer le problème des attaques de prise de contrôle de compte et devrait également fixer une limite sur le nombre de nouveaux comptes qu'un utilisateur suspendu peut créer pour télécharger à nouveau des packages malveillants.
La réapparition des logiciels malveillants persiste sur PyPI
Plus tôt ce mois-ci, un acteur malveillant sur GitHub a ajouté à ses référentiels des logiciels malveillants écrits en Python et hébergés sur PyPI. Quelques minutes après la suppression de son malware de PyPI, le même malware réapparaît sur PyPI sous un nom légèrement différent. Il met ensuite immédiatement à jour tous ses référentiels pour pointer vers ce nouveau package. La plupart de ses projets GitHub sont des bots ou une variété de logiciels malveillants.
Ci-dessous, un extrait du billet de la société de cybersécurité Phylum.
Patrick Pogoda annonce des référentiels douteux sur sa page GitHub. Certains de ces projets Python créent des robots Discord, Telegram et Twitter. D'autres sont des attrapeurs de jetons manifestes qui volent des utilisateurs sans méfiance.
Plus récemment, il a créé un package pour interagir avec ChatGPT, probablement pour surfer sur la récente vague d'intérêt pour l'IA et les grands modèles de langage (LLM).
Une inspection du code montre que le package semble contenir du code légitime pour interagir avec ChatGPT comme annoncé. Il est important de noter que ce dépôt GitHub est différent du chatgpt-api sur PyPI.
Annonce de PyPI
L'une des principales promesses de sécurité de PyPI est que lorsque vous téléchargez quelque chose, seules les personnes associées à ce projet pourront télécharger, 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 sécurité de chaque compte individuel sur PyPI utilisé pour créer et maintenir un projet Python. Dans le passé, nous avons pris des mesures pour protéger ces comptes en bloquant les mots de passe compromis, une prise en charge 2FA renforcée à l'aide de TOTP et WebAuthN, la prise en charge des jetons d'API avec atténuation hors ligne, l'inscription des projets les plus téléchargés dans la 2FA obligatoire et l'activation des jetons de courte durée pour le téléchargement.
Aujourd'hui, dans le cadre de cet effort à long terme pour sécuriser l'écosystème Python, nous annonçons 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'année, PyPI commencera à bloquer l'accès à certaines fonctionnalités du site en fonction de l'utilisation de 2FA. En outre, nous pouvons commencer à sélectionner certains utilisateurs ou projets pour une application anticipée.
Que puis-je faire pour me préparer ?
Les choses les plus importantes que vous pouvez faire pour vous préparer sont d'activer 2FA pour votre compte dès que possible, soit avec un dispositif de sécurité (préféré) ou une application d'authentification et de passer à l'utilisation d'éditeurs de confiance (préférés) ou de jetons API pour télécharger sur PyPI.
Pourquoi utiliser 2FA ?
Les attaques de prise de contrôle de compte proviennent généralement de quelqu'un qui utilise un mot de passe non sécurisé : peut-être était-il facile à deviner, ou il a été réutilisé et est apparu dans une brèche. Avec ce mot de passe non sécurisé, un attaquant peut prendre le contrôle d'un compte de responsable et commencer à agir comme s'il était cet utilisateur.
Cela est particulièrement problématique sur un site comme PyPI, où les actions qu'une personne peut entreprendre incluent la publication de logiciels pouvant être utilisés par des personnes du monde entier, permettant à un attaquant d'installer et d'exécuter des logiciels sur les ordinateurs d'utilisateurs sans méfiance. Les attaques de prise de contrôle de compte ont déjà été utilisées pour compromettre les utilisateurs de PyPI de cette manière.
L'authentification à deux facteurs neutralise immédiatement 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 accès à ce compte.
Pourquoi chaque mainteneur de projet ou d'organisation ?
Il y a deux façons 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 même valeur pour un attaquant. Un compte ayant accès au projet le plus téléchargé sur PyPI peut être utilisé pour attaquer beaucoup plus de personnes qu'un compte ayant accès au projet le moins téléchargé.
Cependant, il suffit d'un seul projet compromis dans l'ensemble de dépendances 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 systèmes, y compris d'autres projets sur PyPI que la personne désormais compromise maintient.
Étant donné qu'il suffit d'un seul projet compromis, quel que soit le nombre de téléchargements qu'il obtient 1, pour compromettre quelqu'un, nous voulons nous assurer que chaque projet est protégé par 2FA.
D'un autre côté, un compte sans accès à aucun projet ne peut être utilisé pour attaquer qui que ce soit 2, c'est donc une cible de très faible valeur.
Nous reconnaissons que l'activation de 2FA pour un compte impose un coût non nul à la fois pour le propriétaire de ce compte et pour PyPI 3, donc forcer cela sur des comptes qui ne peuvent affecter personne d'autre qu'eux-mêmes n'est pas une utilisation efficace de ressources limitées. De plus, d'un point de vue pratique, le flux 2FA standard auquel la plupart des gens sont habitués et que PyPI implémente implique également l'ajout d'un jeton 2FA à un compte existant plutôt que de le forcer à faire partie du flux d'enregistrement.
Les développeurs estiment que c'est un pas dans la bonne direction
La nouvelle a plutôt été bien accueillie par les développeurs. Un professionnel indique : « C'est bien. Vous ne devriez pas publier de logiciels à utiliser par d'autres dans un tel référentiel de logiciels, si vous n'utilisez même pas des éléments de sécurité de base comme 2FA ».
Un autre estime que PyPI peut mieux faire en matière de sécurité :
Bien sûr [c'est bien]. Mais j'espère que quiconque publie un logiciel pour d'autres fait quelque chose de plus en matière de sécurité que juste la 2FA.
La 2FA ne résout pas les pots de miel. Cela ne résout pas les imposteurs de nom de package. Cela ne résout pas directement le cas où développeur empoisonne délibérément ses versions. Cela n'impose aucune sorte de révision 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 développeur qui fait la publication.
La 2FA est un geste symbolique - mais elle ne résout pas les divers problèmes auxquels les référentiels binaires et de packages sont tous confrontés
La 2FA ne résout pas les pots de miel. Cela ne résout pas les imposteurs de nom de package. Cela ne résout pas directement le cas où développeur empoisonne délibérément ses versions. Cela n'impose aucune sorte de révision 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 développeur qui fait la publication.
La 2FA est un geste symbolique - mais elle ne résout pas les divers problèmes auxquels les référentiels binaires et de packages sont tous confrontés
Et un autre de déclarer :
Mandater la 2FA pour les utilisateurs est formidable.
Maintenant, le plus gros problème, ce sont les jetons API. Vous pouvez les générer, les stocker dans des endroits, puis vous venez de déplacer votre risque de mot de passe vers quelque chose nommé différemment, c'est-à-dire un jeton API.
GitHub sélectionne désormais par défaut les jetons basés sur le temps, afin qu'ils expirent. Et ceux-ci ne sont pas géniaux non plus, car ils provoquent essentiellement la rupture des choses à des moments aléatoires lorsque vous ne vous y attendez pas.
D'un autre côté, les jetons d'API permanents, valables jusqu'à leur révocation, 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 sécurité 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 effectuée 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.
Maintenant, le plus gros problème, ce sont les jetons API. Vous pouvez les générer, les stocker dans des endroits, puis vous venez de déplacer votre risque de mot de passe vers quelque chose nommé différemment, c'est-à-dire un jeton API.
GitHub sélectionne désormais par défaut les jetons basés sur le temps, afin qu'ils expirent. Et ceux-ci ne sont pas géniaux non plus, car ils provoquent essentiellement la rupture des choses à des moments aléatoires lorsque vous ne vous y attendez pas.
D'un autre côté, les jetons d'API permanents, valables jusqu'à leur révocation, 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 sécurité 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 effectuée 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 décision de PyPI ? Que pensez-vous des propos des développeurs qui estiment que la mesure est loin d'être suffisante en matière de sécurité ?Voir aussi :
GitHub rendra obligatoire l'authentification à deux facteurs pour tous les développeurs d'ici fin 2023, la mesure touchera en premier des groupes d'utilisateurs spécialement sélectionnés 
