Une faille npm permettait de détourner plus de 1 500 paquets sans voler d'identifiants : GitHub durcit la publication.

GitHub vient de resserrer les règles de publication sur npm. Cette décision fait suite à la découverte d’une faille npm dans le mécanisme de publication de confiance. En effet, des chercheurs ont montré qu’un attaquant pouvait publier de nouvelles versions du paquet d’un autre utilisateur. Il n’avait pas besoin de lui dérober ses identifiants. Par ailleurs, selon le titre de l’information d’origine, plus de 1 500 paquets étaient exposés à un détournement.

Cette affaire rappelle une réalité simple. En effet, les registres de paquets sont devenus une cible de choix pour les attaquants. Ainsi, un seul paquet compromis peut toucher des milliers de projets en aval.

Ce que change GitHub face à la faille npm

GitHub, filiale de Microsoft, a choisi une réponse pragmatique. Désormais, les configurations de publication de confiance non validées expirent 48 heures après leur création. Autrement dit, une configuration restée inutilisée ne reste plus valable indéfiniment.

Le fonctionnement est clair. D’abord, une configuration devient validée après sa première publication réussie. Elle est alors exemptée d’expiration. En revanche, si personne ne s’en sert dans les deux jours, elle disparaît.

Cette règle réduit fortement la fenêtre d’opportunité. En effet, une configuration créée à tort ou de façon malveillante ne peut plus traîner. Elle ne reste donc pas disponible pour un usage détourné plusieurs semaines plus tard.

Les informations disponibles ne détaillent pas tout le scénario d’attaque. Toutefois, l’essentiel est connu : l’abus ne passait pas par un vol de compte. En effet, il exploitait la manière dont les configurations étaient rattachées aux paquets.

Comment fonctionne la publication de confiance

La publication de confiance vise à éliminer les jetons à longue durée de vie. Ces jetons sont souvent copiés dans des fichiers de configuration ou des variables d’environnement. Ils fuient régulièrement, par exemple dans des dépôts publics ou des journaux de compilation.

Avec la publication de confiance, le paquet fait confiance à un flux de travail précis. Ensuite, ce flux de travail s’authentifie de façon temporaire, via un mécanisme d’identité fédérée. Ainsi, aucun secret durable n’est stocké côté développeur.

Sur le papier, le modèle est plus sûr. Cependant, il repose entièrement sur la validité du lien entre un paquet et sa source de publication. Si ce lien peut être établi à tort, la protection perd son sens. C’est précisément ce que cette faille a mis en évidence.

L’incident ne remet pas en cause l’approche elle-même. Il montre plutôt qu’une bonne idée demande des garde-fous solides. Ainsi, la validation par première publication en est un.

Un risque majeur pour la chaîne d’approvisionnement

Le détournement d’un paquet npm est un scénario redouté. En effet, un attaquant qui publie une version piégée atteint tous ceux qui l’installent. Ce type d’attaque contourne les défenses classiques, car la source semble légitime.

Le chiffre de plus de 1 500 paquets doit donc être pris au sérieux. Certes, une exposition ne signifie pas une exploitation. Néanmoins, elle montre l’ampleur potentielle du problème. Un paquet très téléchargé peut servir de relais à une charge malveillante.

De plus, l’attaque est discrète. Aucun mot de passe n’est volé. Aucune alerte de connexion suspecte n’est déclenchée. Le mainteneur peut ne rien remarquer tant qu’une version inattendue n’apparaît pas.

Par conséquent, la surveillance des publications devient aussi importante que la protection des comptes. Les équipes doivent regarder ce qui est publié, et pas seulement qui se connecte.

Recommandations face à la faille npm

Les mainteneurs et les équipes de développement peuvent agir dès maintenant. Voici donc quelques mesures de bon sens.

• Auditer les configurations de publication de confiance associées à chaque paquet dont vous avez la charge.
• Supprimer les configurations inutilisées ou que vous ne reconnaissez pas.
• Vérifier l’historique des versions publiées, afin de repérer toute version que vous n’avez pas déclenchée.
• Valider rapidement les nouvelles configurations par une première publication légitime.
• Activer l’authentification multifacteur sur les comptes qui gèrent les paquets.

Les consommateurs de paquets ont aussi un rôle à jouer. Il est conseillé d’utiliser des fichiers de verrouillage et de figer les versions. En outre, il faut relire les mises à jour avant de les déployer sur des systèmes sensibles.

Ce qu’il faut retenir

• GitHub fait expirer, après 48 heures, les configurations de publication de confiance npm non validées.
• Une configuration est validée après sa première publication réussie, puis n’expire plus.
• La faille permettait de publier de nouvelles versions du paquet d’un tiers sans voler ses identifiants.
• Par ailleurs, plus de 1 500 paquets étaient concernés, selon l’information d’origine.
• Enfin, auditer ses configurations et surveiller ses publications reste la meilleure défense.

Source : GitHub Tightens npm Publishing After Flaw Left 1,500+ Packages Vulnerable to Hijacking