Mercredi soir, la société de sécurité JFrog a publié un bulletin d’alerte concernant une attaque d’une taille a priori conséquente.
Elle vise les développeurs utilisant Azure de Microsoft, dans l’espoir de leur dérober des PII – « personally identifiable information », des informations personnelles identifiantes, dans l’espoir d’obtenir ensuite de précieux identifiants.
Selon les chercheurs Andrey Polkovnychenko and Shachar Menashe, les premiers dépôts de npm malveillants ont été détectés le 21 mars. Les pirates (non identifiés) visent les paquets npm ayant un préfixe @azure, @azure-rest, @azure-tests, @azure-tools ou @cadl-lang via une attaque par typosquattage par l’intermédiaire d’un script automatisé.
Pour JFrog, les chances que les développeurs puissent se faire avoir sont réelles, car les paquets npm visés sont téléchargés des dizaines de millions de fois chaque semaine.
La société de sécurité fournit dans son billet de blog une liste complète des paquets actuellement visés. Nous ne la reproduisons pas ici car il y en a plusieurs dizaines.
Le temps que cette attaque soit jugulée, il est donc recommandé aux développeurs de faire particulièrement attention à ce qu’ils téléchargent et d’en vérifier la provenance.
Commentaires (4)
#1
JFrog n’est pas vraiment une “société de sécurité”, le cœur de leur offre est un gestionnaire de paquets - la sécurité est plus un à côté.
#2
C’est beau de rêver, j’ai rarement vu des projets sur lesquels les dépendances du code sont connues et suivies…
#3
Attaque par typosquatting, c’est pas vraiment la bonne catégorie; on est pas sur des utilisateurs lambdas qui se font avoir par une faute d’orthographe/typo en allant un peu vite sur la vérification.
On est plus dans l’attaque par supply chain, à la rigueur.
Par contre, quand on regarde l’exemple dans leur billet de blog, c’est vraiment pas fin comme attaque … Suppression du scope Azure, version totalement wtf, même pas de readme affiché …
NPM a l’air d’avoir agit et supprimé au moins le paquet d’exemple : https://www.npmjs.com/package/core-tracing
#4
Ce qui fait suite à d’autres découvertes de vulnérabilités sur les dépôts NPM traduites dans une publication, qui avait mentionnée ici aussi auparavant.
Les bonnes pratiques sont et resteront :
Bien évidemment, par construction, beaucoup de projet réutilisés disposent d’une palanquée de dépendances externes qui sont bien souvent directement tirées depuis des dépôts/registres externes (Docker, NPM/Yarn, Go viennent immédiatement à l’esprit).
Sans attention particulière, on se retrouve donc bien souvent à compiler localement… du code qui tire des dépendances externes, ce qui réduit l’intérêt de la chose.
La chose la plus importante relative à ce que je viens d’énoncer est que
tout le mondel’écrasante majorité de la populationcensée êtreconcernée s’en cogne.Commençons par là.