Qu’est-ce que le typosquatting et comment ces attaques sont à l’origine de modules malveillants sur npm

Vous avez peut-être entendu parler de paquets malveillants dans différents contextes : conteneur Docker malveillant, ou paquet open source malveillant publié dans le registre public d’un écosystème. Snyk a même publié une étude approfondie sur les malwares dans les applications mobiles, baptisée SourMint.

Nous avons déjà examiné certains de ces incidents de sécurité, qui ne se limitent pas à un seul écosystème :

• Attaques par typosquatting dans le registre PyPI de Python

• L’incident très médiatisé d’event-stream : publication d’une version malveillante dans l’écosystème JavaScript npm

• Exécution de code à distance malveillante dans les célèbres projets de gems Ruby bootstrap-sass et strong_password

Cependant, tous les paquets malveillants ne se ressemblent pas. En ce qui concerne les registres des écosystèmes, on peut les classer dans les catégories suivantes :

• Attaques par typosquatting : des acteurs malveillants publient des paquets dangereux dans un registre en espérant piéger les utilisateurs et les inciter à les installer. Nous avons vu ce type de paquets dans les registres PyPI et Node.js. Le cas le plus notable est celui de crossenv. Son nom ressemblait à celui du paquet populaire cross-env et il en reprenait les fonctionnalités, mais capturait également les variables d’environnement pour les envoyer à un serveur distant contrôlé par un attaquant.

• Comptes compromis : les responsables de projets open source n’ont pas nécessairement une meilleure maîtrise de la sécurité que les autres développeurs, ce qui peut entraîner une gestion malheureuse et peu sûre des secrets liés à leurs droits de publication. La situation se complique encore lorsqu’un projet compte plusieurs responsables et que les règles du projet doivent être appliquées à chacun d’eux. Des contrôles d’authentification insuffisants dans certains registres peuvent également expliquer la compromission de comptes. Quoi qu’il en soit, des comptes compromis peuvent entraîner de graves incidents de sécurité, car les projets gérés par ces comptes peuvent être très populaires et avoir un impact immédiat sur leur écosystème.

• Ingénierie sociale plutôt que graphe de dépendances : l’open source encourage et accueille pleinement la collaboration. Toutefois, si une ligne de code malveillante dans une pull request alertera probablement rapidement de nombreux regards, c’est une autre histoire lorsqu’elle est ajoutée à une dépendance du projet.

Attaques par typosquatting

Parmi les types de paquets et de versions malveillants mentionnés ci-dessus, le typosquatting est l’un des plus répandus. La « barrière à l’entrée » est très faible pour les attaquants et les contre-mesures sont peu nombreuses.

En quoi consistent les attaques par typosquatting ?

Les attaques par typosquatting consistent, pour des acteurs malveillants, à publier des paquets dangereux dans un registre dans l’espoir de piéger les utilisateurs et de les inciter à les installer. Les registres publics de logiciels, comme npm ou PyPI, sont des exemples d’écosystèmes où nous avons déjà observé de telles tentatives.

Le principe est très proche des attaques de phishing visant des sites web : elles exploitent les fautes de frappe de personnes qui saisissent accidentellement une adresse erronée, par exemple https://bankofamerca.com au lieu de https://bankofamerica.com. Si le premier domaine était contrôlé par un attaquant, celui-ci pourrait créer un faux site ressemblant à l’original et dérober des informations financières sensibles, comme des identifiants ou des coordonnées bancaires.

Exemples de modules malveillants liés au typosquatting, trouvés dans la base de données des vulnérabilités de Snyk, dès 2017, avec une série de vulnérabilités :

Et si vous pensez que le typosquatting a disparu en 2020, détrompez-vous :

L’histoire de crossenv

Un cas particulièrement notable d’attaque par typosquatting est celui de crossenv. L’attaquant a choisi un nom proche de celui du paquet populaire cross-env et en a même repris exactement les fonctionnalités, pour faire croire que le module fonctionnait comme prévu. En réalité, il capturait aussi les variables d’environnement et les envoyait à un serveur distant contrôlé par un attaquant.

Le 19 juillet, l’utilisateur npm hacktask a publié crossenv, l’un de plus de 30 autres paquets malveillants utilisés pour dérober les variables d’environnement des victimes piégées et incitées à les installer.

Comme l’a indiqué C J Silverio dans son blog, voici la liste complète des paquets, accompagnés du nombre total de téléchargements enregistrés pendant leur présence dans le registre public npm :

babelcli: 42
cross-env.js: 43
crossenv: 679
d3.js: 72
fabric-js: 46
ffmepg: 44
gruntcli: 67
http-proxy.js: 41
jquery.js: 136
jquery.js: 136
mariadb: 92
mongose: 196
mssql-node: 46
mssql.js: 48
mysqljs: 77
node-fabric: 87
node-opencv: 94
node-opensl: 40
node-openssl: 29
node-sqlite: 61
node-tkinter: 39
nodecaffe: 40
nodefabric: 44
nodeffmpeg: 39
nodemailer-js: 40
nodemailer.js: 39
nodemssql: 44
noderequest: 40
nodesass: 66
nodesqlite: 45
opencv.js: 40
openssl.js: 43
proxy.js: 43
shadowsock: 40
smb: 40
sqlite.js: 48
sqliter: 45
sqlserver: 50
tkinter: 45

À quoi ressemble un paquet malveillant comme crossenv ?

Pour examiner le cas du paquet malveillant crossenv, commençons par le fichier package.json :

Examinons quelques éléments qui semblent suspects à première vue dans le fichier package.json :

• Ligne 2 : le nom du paquet est manifestement erroné, mais supposons que personne ne l’ait remarqué.

• Ligne 13 : le paquet cross-env d’origine est inclus. Comme vous pouvez le voir, sa version (5.0.1) diffère de celle du module lui-même (6.1.1, ligne 3).

• Ligne 8 : les signaux d’alerte devraient s’allumer. Que contient package-setup.js et pourquoi ce paquet a-t-il besoin de cette configuration ?

Avant d’entrer dans le détail de l’histoire de node package-setup.js, prenons un peu de recul pour expliquer l’importance de cette ligne. Le script d’exécution appelé postinstall est l’un des hooks intégrés au cycle de vie des paquets npm. Il s’exécute automatiquement lors de l’installation d’un paquet.

Toute commande définie dans un script postinstall est exécutée par une commande npm install, que vous ayez ou non besoin de ce script dans votre propre code.

Acte 1 : la charge utile malveillante du paquet npm

Poursuivons notre enquête et examinons le contenu du fichier package-setup.js : l’affaire prend une tournure inquiétante.

Pendant l’installation du paquet npm, ce script collecte toutes les variables d’environnement à l’aide de process.env, les encode en base64, puis les envoie par requête HTTP POST à un serveur distant contrôlé par un attaquant.

L’action malveillante n’a lieu qu’une seule fois, au moment de l’installation. Ensuite, le paquet crossenv continue de fournir la fonctionnalité pour laquelle il a été installé, en faisant appel au véritable paquet cross-env, et passe ainsi inaperçu.

Acte 2 : mesurer l’impact des paquets malveillants

Il est important de découvrir et de mettre en lumière cette faille de sécurité, mais ce n’est pas suffisant. Pour comprendre les dégâts qu’elle aurait pu causer et les conséquences d’une telle attaque, prenons le temps de nous poser quelques questions :

1. Quelles informations stockons-nous dans nos variables d’environnement ?

2. Que se serait-il passé si un développeur avait fusionné ce code dans une branche et l’avait exécuté sur un serveur CI ? Et que se passerait-il s’il était ensuite déployé sur un serveur de production ?

3. Quel serait l’impact si l’attaque ne se limitait pas à la lecture des variables d’environnement, mais allait jusqu’à installer des portes dérobées, à infecter les environnements avec des vers autoréplicatifs ou à déclencher d’autres scénarios cauchemardesques ?

Épilogue : comment avons-nous découvert ce paquet malveillant sur npm ?

Oscar Bolmsten, ingénieur logiciel suédois, a publié un tweet au sujet d’une possible activité malveillante du paquet crossenv. Apparemment, celle-ci est passée inaperçue pendant deux semaines :

https://twitter.com/o\_cee/status/892306836199800836?ref\_src=twsrc%5Etfw

Que pouvons-nous faire ?

• Ne stockez aucune information sensible dans les variables d’environnement.

• Connectez votre dépôt à Snyk pour que nous puissions surveiller chaque jour les dépendances de votre projet et vous alerter en cas de paquet malveillant ou d’autre vulnérabilité. Si nous trouvons une vulnérabilité pouvant être corrigée, nous ouvrirons automatiquement une pull request (ou une merge request) dans votre dépôt pour la corriger !

• Consultez Snyk Advisor avant d’installer des paquets afin d’avoir un aperçu de leur état général, de leur popularité, de leur maintenance, de leur sécurité et d’autres caractéristiques.

• Lors de l’installation de paquets, utilisez l’option CLI npm --ignore-scripts pour empêcher l’exécution des scripts des paquets tiers pendant l’installation.

• Pensez à utiliser npq pour installer des paquets en toute sécurité : cet outil recueille des informations sur leur état avant leur installation.

Pour découvrir d’autres bonnes pratiques et conseils de sécurité npm, consultez le pense-bête sur la sécurité npm.