Des chercheurs ont identifié que des milliers de développeurs JavaScript utilisent une adresse e-mail avec un domaine expiré pour leurs comptes npm, laissant leurs projets exposés à des risques de détournements faciles, s'étonne The Record.
L'étude, réalisée l'année dernière par des chercheurs de Microsoft et de la North Caroline State University, a analysé les métadonnées de 1 630 101 bibliothèques téléchargées sur Node Package Manager (npm), le référentiel de facto pour les bibliothèques JavaScript et le plus grand référentiel de packages sur Internet.
Or, 2 818 responsables de projets, gérant 8 494 packages, utilisaient encore une adresse e-mail pour leurs comptes dont le domaine avait expiré. Certains étaient même en vente sur des sites comme GoDaddy.
Des attaquants pourraient dès lors acheter ces domaines, réenregistrer l'adresse du responsable sur leurs propres serveurs de messagerie, puis réinitialiser le mot de passe du compte du responsable et reprendre ses packages npm.
Les chercheurs ont également souligné que de nombreuses bibliothèques et comptes npm sont soit non maintenus (58,7%) soit abandonnés (44,3%), et qu'il y aurait de grandes chances que les attaquants puissent mener leurs attaques sans même que les mainteneurs s'en aperçoivent.
Une attaque comme celle-ci fonctionnerait car le portail npm n'applique pas l'authentification à deux facteurs (2FA) pour les propriétaires de compte, ce qui signifie qu'une fois que l'attaquant a réinitialisé le mot de passe du propriétaire, il serait libre de modifier les packages avec tout autre obstacle.
npm a depuis annoncé son intention de commencer lentement à appliquer 2FA pour les comptes de développeur. Ce processus devait se dérouler en plusieurs étapes, les comptes des 100 meilleurs responsables étant inscrits au 2FA obligatoire au début de ce mois.
Commentaires (9)
#1
C’est un hallucinant de voir ça…
#2
Bloquer les comptes ayant un domaine expiré.
Genre, immédiatement, tout de suite, maintenant.
C’est ce qu’ils ont fait, j’espère, non?
#3
Probablement pas, car il y a surement de grosses boites concernées et ça risque de gueuler… mais d’accord avec toi
#4
Bah, npm quoi.
#5
Et comparé à packagist ? Car bon, les “je balance mon projet du moment sur packagist/npm/* parce que je trouve ça fun”, il doit y en avoir des tas, et sur toutes les plateformes
.
#6
Après, c’est aussi de la responsabilité des usagers de se reposer ou non sur des projets sécuritaires.
Il y a l’excuse des dépendances transitives, mais un arbre de dépendances ça s’analyse ^_^. Enfin voilà, ce n’est pas pour rien que des boites ont des politiques très strictes sur les dépendances.
#6.1
Oui mais au delà de npm, je constate surtout que c’est à la mode de faire des langages/plateformes sans vraie librairie standard. Ça impose de faire appel à des dépendances (si on ne veut pas réinventer la roue) pour le moindre truc basique.
Il y a juste un monde entre ce qui peut être fait sans dépendances entre d’un côté Python, Go, C# ou Java et de l’autre JavaScript ou Rust (et j’adore Rust, mais on va vraiment pas loin sans dépendances).
Même PHP avait une stdlib extrêmement fournie (bien que moisie, avec du recul) qui permettait de faire des tas de choses sans frameworks / librairies.
#6.2
De l’autre côté, pour le cas du Rust, le choix de limiter la librairie standard à ce qu’ils peuvent assurer une stabilité forte au niveau API est une très bonne chose. Au niveau dépendance, ce qu’on pourrait retrouver dans des libs standards plus étoffées sont généralement maintenus par des devs core de Rust. Donc bon, ça me semble pas non plus dégueulasse comme écosystème.
Et on se retrouve pas coincé avec une lib standard dépassé par ce qu’on peut trouver dans les libs externes et qui peuvent pas évoluer sous peine de casser pleins de code.
#7
Tu as raison mais je pensais plus à certaines dépendances qui deviennent, de manière directe ou transitive, assez rapidement nécessaires comme serde ou tokio. Après il s’agit clairement de deux exemples de très bonne qualité.