if ( !emtpy($headline_subheadline ) ) : ?>
Une faiblesse dans le modèle de confiance de npm pourrait permettre aux attaquants de publier des mises à jour de packages légitimes en revendiquant les noms de référentiels GitHub abandonnés, ont découvert les chercheurs.
endif; ?>
Une faille dans le mécanisme de publication sécurisée de npm pourrait permettre à des attaquants de détourner des packages logiciels légitimes en récupérant les noms de référentiels GitHub abandonnés, exposant ainsi potentiellement des millions de téléchargements de packages à des attaques de la chaîne d’approvisionnement.
Les chercheurs de Bloom Security ont identifié plus de 1 500 packages NPM potentiellement vulnérables, notamment des scanners de sécurité, des outils d’authentification et des packages cryptographiques.
La vulnérabilité, baptisée SlugFest, provenait du fait que npm s’appuyait sur des noms de référentiels GitHub lisibles par l’homme pour vérifier les éditeurs de confiance plutôt que sur les identifiants numériques permanents des référentiels. Cela pourrait permettre à un attaquant d’hériter de la confiance de publication d’un package en revendiquant un nom de référentiel que son propriétaire d’origine avait abandonné.
Un nom de référentiel récupéré a permis la publication de packages
La publication sécurisée de npm permet aux responsables de packages de publier des versions via des flux de travail automatisés à l’aide d’OpenID Connect (OIDC), évitant ainsi les informations d’identification de publication de longue durée. Cependant, Bloom a constaté que la configuration de confiance de npm reposait sur le nom du propriétaire/référentiel du référentiel GitHub au lieu de son ID de référentiel immuable.
Lorsqu’un référentiel est renommé, transféré ou supprimé, son ancien nom peut devenir disponible pour qu’un autre utilisateur puisse le réclamer. Un attaquant pourrait créer un référentiel à cette adresse et configurer un workflow GitHub Actions avec le nom de fichier attendu. Étant donné que npm a vérifié le nom du référentiel et le nom du fichier de workflow sans vérifier l’ID du référentiel permanent, l’attaquant pourrait potentiellement obtenir des informations d’identification de publication valides pour un package dont il ne possédait pas.
Les chercheurs ont démontré l’attaque contre un package contrôlé par des chercheurs, en publiant une nouvelle version à partir d’un référentiel GitHub appartenant à une autre organisation. L’attaque n’a pas nécessité de compromettre le compte GitHub ou npm du responsable légitime ni de voler ses informations d’identification.
Leur analyse à l’échelle du registre a identifié plus de 1 500 packages vulnérables avec plus de 10 millions de téléchargements combinés et plus d’un million de téléchargements par mois. Un package représentait plus de 200 000 téléchargements mensuels, selon Bloom.
Les agents d’IA amplifient le risque de la chaîne d’approvisionnement
Bloom affirme que les agents de codage d’IA peuvent accélérer la distribution de dépendances malveillantes car ils sélectionnent et installent de plus en plus de progiciels avec une intervention humaine limitée.
Dans des dizaines d’organisations, les chercheurs ont mesuré chaque mois environ 70 packages installés par agent par point final, atteignant environ 350 sur les machines des développeurs. Ces chiffres couvrent les installations directes et excluent les dépendances transitives.
Une version malveillante pourrait exécuter du code contrôlé par un attaquant via un hook d’installation lorsque les développeurs ou les systèmes CI installent le package compromis. Les agents d’IA pourraient introduire une telle dépendance sans qu’un développeur ne la sélectionne explicitement. « Un package piraté n’a plus besoin de trouver un développeur », a déclaré Myers. « Il suffit que ce soit le forfait choisi par un agent. »
Outre que GitHub a résolu le problème en faisant expirer les configurations de publication de confiance non validées après 48 heures, npm a également renforcé ses garanties en rejetant les jetons de publication de confiance émis via les événements issue_comment de GitHub Actions, parallèlement à la restriction existante sur les événements pull_request_target.
De plus, Bloom a recommandé aux responsables d’auditer leurs configurations de publication approuvée, de vérifier que chaque nom de référentiel approuvé correspond toujours à un référentiel sous leur contrôle, et de supprimer et recréer les liaisons si nécessaire. Les chercheurs ont également conseillé aux équipes de sécurité d’auditer les dépendances logicielles et les outils utilisés dans leurs environnements et d’appliquer des contrôles sur ce que les développeurs et les agents d’IA sont autorisés à installer.
