Une faille a été identifiée dans NPM qui permet de détecter l'existence de packages dans des référentiels fermés. Le problème est dû à des temps de réponse différents lors de la demande d'un package existant et inexistant à un tiers qui n'a pas accès au référentiel. S'il n'y a aucun accès pour les packages dans les référentiels privés, le serveur Registry.npmjs.org renvoie une erreur avec le code « 404 », mais si un package portant le nom demandé existe, l'erreur est émise avec un retard notable. Un attaquant peut utiliser cette fonctionnalité pour déterminer la présence d'un package en recherchant les noms de packages à l'aide de dictionnaires.
La détermination des noms de packages dans des référentiels privés peut être nécessaire pour effectuer une attaque de mélange de dépendances qui manipule l'intersection des noms de dépendances dans les référentiels publics et internes. Sachant quels packages NPM internes sont présents dans les référentiels d'entreprise, un attaquant peut placer des packages portant les mêmes noms et des numéros de version plus récents dans le référentiel NPM public. Si lors de l'assemblage les bibliothèques internes ne sont pas explicitement liées à leur référentiel dans les paramètres, le gestionnaire de packages npm considérera le référentiel public comme une priorité plus élevée et téléchargera le package préparé par l'attaquant.
GitHub a été informé du problème en mars mais a refusé d'ajouter une protection contre l'attaque, invoquant des limitations architecturales. Il est recommandé aux entreprises utilisant des référentiels privés de vérifier périodiquement l'apparition de noms qui se chevauchent dans le référentiel public ou de créer des stubs en leur nom avec des noms qui répètent les noms des packages dans les référentiels privés, afin que les attaquants ne puissent pas placer leurs packages avec des noms qui se chevauchent.
Source: opennet.ru