- Une attaque en cours tente d’infecter les appareils des développeurs qui dépendent de ces bibliothèques de code en téléversant des centaines de paquets malveillants dans le dépôt NPM (Node Package Manager)
- Les noms des paquets malveillants ressemblent à ceux de bibliothèques légitimes comme Puppeteer, Bignum.js, ainsi qu’à diverses bibliothèques liées aux cryptomonnaies
- Cette campagne était toujours active au moment de la publication de l’article et a été découverte par l’entreprise de sécurité Phylum
Il faut se méfier des attaques de la chaîne d’approvisionnement
- Les auteurs du malware ont dû chercher de nouvelles méthodes pour masquer leurs intentions et obscurcir les serveurs distants qu’ils contrôlent
- C’est un avertissement supplémentaire montrant que les attaques de la chaîne d’approvisionnement restent très actives
- Les paquets malveillants installés utilisent une nouvelle méthode pour cacher l’adresse IP à laquelle ils se connectent afin de récupérer une charge utile malveillante de second niveau
- Aucune adresse IP n’apparaît dans le code de premier niveau. À la place, celui-ci accède à un smart contract Ethereum pour récupérer une chaîne de caractères (une adresse IP) associée à une adresse de contrat précise sur le mainnet Ethereum
- Dans les paquets analysés par Phylum, l’adresse IP renvoyée était
hxxp://193.233.201[.]21:3001
- Le stockage de données sur la blockchain Ethereum permet de voir les adresses IP utilisées auparavant par les attaquants
- Ethereum conserve un historique immuable de toutes les modifications des valeurs observées jusqu’à présent
- Il est donc possible de voir toutes les adresses IP utilisées par cet acteur de la menace
- Les paquets malveillants s’installent sous la forme d’un paquet Vercel et s’exécutent en mémoire
- La charge utile se configure pour être chargée à chaque redémarrage et se connecte à l’adresse IP du contrat Ethereum
- Elle effectue ensuite plusieurs requêtes pour récupérer des fichiers JavaScript supplémentaires, puis renvoie à nouveau des informations système au même serveur de requêtes
- Ces informations incluent le GPU, le CPU, la quantité de mémoire de la machine, le nom d’utilisateur et des informations sur la version de l’OS
- Les attaques exploitant les fautes de frappe sont largement utilisées
- Cette attaque repose sur le typosquatting, c’est-à-dire l’usage de noms très proches de paquets légitimes, avec seulement quelques lettres différentes
- Le typosquatting est utilisé depuis cinq ans pour tromper les développeurs et leur faire télécharger des bibliothèques de code malveillantes
- Les développeurs devraient toujours revérifier le nom d’un paquet avant d’exécuter ce qu’ils ont téléchargé
8 commentaires
S’ils utilisent des smart contracts, on pourrait peut-être aussi contre-attaquer pour épuiser le gas du hacker, haha
De toute façon, c’est toujours cette fichue crypto le problème.
J’aimerais bien qu’il y ait un genre de scanner de malware pour le Nix store, il va falloir que je cherche. Les développeurs devraient tous passer à nix. Il faut figer et verrouiller tous les actifs numériques pour qu’on ne puisse plus y toucher. Et l’État devrait aussi créer une IA RAG ou je ne sais quoi et la déployer aux entreprises, à quand ça ? Courage. C’est quand que cet environnement de développement pire qu’en Asie du Sud-Est va enfin prendre fin ?
Dans quelle entreprise travaillez-vous pour devoir bosser dans un environnement de développement pire qu’en Asie du Sud-Est…
Vous voulez dire que c’est dû non pas à un problème propre à l’entreprise, mais à une question de politique nationale, n’est-ce pas ?
npm rencontre ce problème de temps en temps ; les dépôts de paquets des autres langages n’ont-ils pas ce genre de problème non plus ?
Par exemple, est-ce parce que la configuration par défaut du gestionnaire de paquets est
allow-net=falseouignore-scripts=true, et donc plus sûre, ou bien est-on dans une situation similaire...C’est surtout parce que npm est très utilisé qu’on le remarque souvent.
C’est pareil pour les dépôts de paquets des autres langages.
Ces outils qui récupèrent et utilisent automatiquement des bibliothèques à distance, comme cargo, alire, maven, etc., ne sont-ils pas tous exposés à des menaces similaires ?