{"id":105307,"date":"2022-10-14T15:36:38","date_gmt":"2022-10-14T13:36:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah"},"modified":"2022-10-14T15:36:38","modified_gmt":"2022-10-14T13:36:38","slug":"ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah","title":{"rendered":"Une attaque sur NPM permettant de d\u00e9tecter la pr\u00e9sence de paquets dans des d\u00e9p\u00f4ts priv\u00e9s.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Une vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 identifi\u00e9e dans NPM, permettant de d\u00e9terminer l'existence de paquets dans des d\u00e9p\u00f4ts priv\u00e9s. Ce probl\u00e8me est caus\u00e9 par des temps de r\u00e9ponse diff\u00e9rents lors de la requ\u00eate d'un paquet existant et d'un paquet inexistant par un utilisateur tiers n'ayant pas acc\u00e8s au d\u00e9p\u00f4t. En cas de manque d'acc\u00e8s pour tout paquet dans des d\u00e9p\u00f4ts priv\u00e9s, le serveur registry.npmjs.org renvoie une erreur avec le code \u00ab 404 \u00bb, mais si le paquet avec le nom demand\u00e9 existe, l'erreur est d\u00e9livr\u00e9e avec un d\u00e9lai perceptible. Un attaquant peut exploiter cette particularit\u00e9 pour d\u00e9terminer la pr\u00e9sence d'un paquet en testant des noms de paquets par le biais de listes de mots. <\/p>\n
La d\u00e9termination des noms de paquets dans des d\u00e9p\u00f4ts priv\u00e9s peut \u00eatre n\u00e9cessaire pour r\u00e9aliser une attaque par m\u00e9lange de d\u00e9pendances, qui manipule les intersections de noms de d\u00e9pendances entre d\u00e9p\u00f4ts publics et internes. Sachant quels paquets NPM internes sont pr\u00e9sents dans les d\u00e9p\u00f4ts d'entreprise, un attaquant peut publier des paquets portant les m\u00eames noms et des num\u00e9ros de version plus r\u00e9cents dans un d\u00e9p\u00f4t public NPM. Si, lors de la construction, les biblioth\u00e8ques internes ne sont pas explicitement li\u00e9es \u00e0 leur d\u00e9p\u00f4t dans la configuration, le gestionnaire de paquets npm consid\u00e9rera le d\u00e9p\u00f4t public comme plus prioritaire et t\u00e9l\u00e9chargera le paquet pr\u00e9par\u00e9 par l'attaquant. <\/p>\n
GitHub a \u00e9t\u00e9 inform\u00e9 du probl\u00e8me en mars, mais a refus\u00e9 d'ajouter une protection contre cette attaque en invoquant des limitations architecturales. Les entreprises utilisant des d\u00e9p\u00f4ts priv\u00e9s sont conseill\u00e9es de v\u00e9rifier p\u00e9riodiquement l'apparition de noms se chevauchant dans le d\u00e9p\u00f4t public ou de cr\u00e9er, en leur nom, des substituts avec des noms r\u00e9p\u00e9tant les noms de paquets dans les d\u00e9p\u00f4ts priv\u00e9s, afin que les malfaiteurs ne puissent pas publier leurs paquets avec des noms similaires. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"