Snyk révèle des vulnérabilités de sécurité de la chaîne d’approvisionnement dans les extensions Visual Studio Code

Écrit par

26 mai 2021

0 minutes de lecture

Nous constatons une augmentation constante des incidents liés à la sécurité de la chaîne d’approvisionnement. Il peut s’agir de failles de sécurité dans des gestionnaires de packages open source exploitées, de systèmes d’intégration continue compromis ou encore d’artefacts logiciels piégés. À présent, ces incidents commencent à s’étendre à l’environnement dans lequel les développeurs passent le plus clair de leur temps : leur environnement de développement intégré, et plus précisément l’IDE Visual Studio Code.

Dans cet article :

Introduction : une marketplace d’extensions Visual Studio Code vulnérable
Contexte : l’impact des extensions Visual Studio Code vulnérables sur les développeurs
Démonstration d’exploitation : attaquer les extensions Visual Studio Code
Divulgation des recherches en sécurité : Snyk publie les résultats de ses recherches sur la sécurité de la chaîne d’approvisionnement Visual Studio Code
Que pouvons-nous faire ? Atténuer les risques liés à la sécurité des extensions VS Code

Jusqu’à récemment, aucune vulnérabilité de sécurité n’avait été découverte dans les extensions VS Code, ce qui donnait à des millions de développeurs un sentiment de sécurité. Or, Snyk a découvert et divulgué des vulnérabilités qui représentent une menace réelle et imminente pour les développeurs qui utilisent ces extensions et interagissent ensuite avec un acteur malveillant. Le risque de compromission est si grave qu’une exécution de code à distance sur la machine d’un développeur est possible en le piégeant simplement pour qu’il clique sur un lien.

Cette nouvelle menace visant la chaîne d’approvisionnement des extensions VS Code pourrait devenir un nouveau terrain de jeu pour les attaques et toucher potentiellement plus de 2 000 000 de développeurs. Examinons la situation de plus près.

Une marketplace d’extensions VS Code vulnérable

La marketplace d’extensions VS Code propose environ 25 000 extensions. Il s’agit essentiellement d’archives compressées de code JavaScript qui ressemblent à des packages npm et s’appuient même sur l’écosystème npm comme source de dépendances tierces pour contribuer à leur création.

À l’instar du registre npm, la marketplace d’extensions VS Code est un écosystème ouvert, où tout développeur peut s’inscrire et soumettre ses extensions. Une fois téléversées et validées, ces extensions sont accessibles aux développeurs depuis l’IDE VS Code.

Pour que certaines de ces attaques fonctionnent, un développeur doit utiliser activement les extensions concernées. Voici quelques-unes des extensions vulnérables découvertes par Snyk :

Open in Default Browser : plus de 520 000 téléchargements. Permet aux développeurs d’ouvrir des fichiers dans un navigateur afin de les examiner rapidement et facilement (courant pour les fichiers HTML).
Instant Markdown : plus de 120 000 téléchargements. Permet aux développeurs d’analyser la syntaxe Markdown d’un fichier, puis de l’afficher au format HTML dans un navigateur Web. C’est comparable à l’affichage d’un fichier Markdown, tel qu’un README.md, sur la page d’accueil d’un dépôt GitHub.

En voyant ces extensions populaires, combien de fois avons-nous installé une extension dans notre éditeur sans même penser que nous laissions entrer du code écrit par un inconnu ? Un code qui a peut-être désormais accès à notre environnement de développement, voire le contrôle ? Combien de fois l’utilisation d’une simple extension a-t-elle potentiellement mis des développeurs en danger ?

L’impact des extensions VS Code vulnérables sur les développeurs

À première vue, une extension peut sembler simplement ajouter des fonctionnalités à l’IDE, mais son rayon d’impact est bien plus important. Une extension compromise sur l’ordinateur portable d’un développeur signifie que l’attaquant a, au minimum, percé un trou dans le pare-feu et obtenu l’accès aux réseaux internes de l’entreprise. Pensons ensuite aux informations sensibles auxquelles les développeurs ont accès. Même si l’attaquant ne peut que lire des fichiers, par exemple en exploitant une classique vulnérabilité de traversée de chemin, il peut récupérer des secrets, notamment en accédant aux fichiers de configuration de l’environnement du développeur ou à ses clés SSH, ce qui lui permet à son tour d’obtenir un accès en lecture et en écriture aux dépôts de code source.

Comme vous pouvez le constater, un environnement de développement est très puissant et souvent considéré comme une entité de confiance au sein d’un réseau. La compromission de développeurs constitue donc une cible très intéressante pour les attaquants.

En fait, une vulnérabilité de sécurité similaire affectait l’environnement d’exécution Node.js en novembre 2018. Identifiée sous le nom de CVE-2018-12120, cette vulnérabilité exposait potentiellement les développeurs à un risque, car le port du débogueur de l’environnement d’exécution était à l’écoute sur toutes les interfaces réseau disponibles. Imaginez que vous déboguiez une application Node.js ou JavaScript en exécutant node --debug depuis un réseau public non sécurisé, comme celui d’un café. Des attaquants pourraient alors se connecter à l’interface de débogage et exécuter du code JavaScript arbitraire dans votre environnement de développement.

Si vous pensez que cet exemple est un cas isolé, sachez que Rapid7 a transformé en arme un exploit ciblant précisément cette vulnérabilité d’injection de commandes du débogueur Node.js, en créant un module pour le framework d’exploitation Metasploit.

Attaquer les extensions VS Code

Examinons de plus près l’une des extensions vulnérables pour voir comment un attaquant peut l’exploiter à son avantage.

Dans la démonstration suivante, nous allons exploiter une vulnérabilité de code dans l’extension Instant Markdown. Après l’avoir installée depuis la marketplace, vous pouvez voir à quoi ressemble le cas d’usage classique de prévisualisation des fichiers Markdown :

Page de l’extension Instant Markdown pour Visual Studio Code, avec le code Markdown dans l’éditeur et son aperçu dans le navigateur.

Dès que vous affichez un fichier Markdown, comme le README.md d’un dépôt, l’extension lance un serveur Web à l’écoute sur localhost et le port 8090. Vous n’avez même pas besoin d’ouvrir le volet de l’extension dans VS Code. Elle se lance automatiquement en arrière-plan.

Si vous ouvrez un fichier README.md dans l’éditeur VS Code, puis accédez à http://localhost:8090, vous verrez le contenu du fichier README.md sous forme de fichier HTML.

Le problème vient du fait que l’extension Instant Markdown présente une vulnérabilité de traversée de chemin. Ainsi, toute personne ayant accès à ce serveur localhost peut demander et recevoir n’importe quel fichier de l’environnement exécutant VS Code, qui est en réalité la machine du développeur.

Par exemple, si j’utilisais cette extension et que j’avais un fichier de logo Snyk dans mon dossier de téléchargements, tel que ~/Downloads/snyk-dog.svg, puis que j’exécutais la commande curl ci-dessous dans l’invite de commande, le contenu de ce fichier serait renvoyé :

1curl "http://localhost:8090/foo/?/../../../../../Downloads/snyk-dog.svg"

Vous vous demandez peut-être comment quelqu’un pourrait accéder à un fichier servi par un serveur Web local. Et si cette personne vous incitait à visiter un site Web ? Il lui suffit que vous ouvriez dans votre navigateur un site contrôlé par un attaquant.

Voici un diagramme qui explique comment contourner les problèmes liés à CORS :

Diagramme de séquence montrant comment une URL malveillante conduit du navigateur d’une victime, via une iframe et une extension VS Code, jusqu’à un attaquant, qui peut ainsi accéder à des fichiers locaux confidentiels.

Le vecteur d’attaque décrit ci-dessus exploite la vulnérabilité de traversée de chemin, ainsi qu’une falsification de requête côté serveur et quelques astuces JavaScript ingénieuses, comme le déclenchement du téléchargement d’un fichier sur l’environnement de l’utilisateur, l’utilisation d’une iframe et de l’API Window.postMessage du navigateur pour transmettre les données nécessaires.

Voici une vidéo qui montre le déroulement de l’attaque. Kirill Efimov, chercheur en sécurité chez Snyk, démarre un serveur Web qu’il contrôle, le rend accessible sur Internet via ngrok pour simuler un site HTTP accessible depuis Internet, puis finit par dérober les clés SSH d’un développeur qui utilise VS Code et une extension vulnérable :

Snyk publie les résultats de ses recherches sur la sécurité de la chaîne d’approvisionnement VS Code

Ce n’est qu’un exemple des moyens que les attaquants chercheront à exploiter dans les extensions VS Code et ce vecteur de la chaîne d’approvisionnement pour cibler les développeurs. En réalité, nous avons trouvé d’autres extensions vulnérables à des vecteurs d’attaque similaires, comme LaTeX Workshop, qui compte plus de 1 200 000 téléchargements.

Avant de partager ces résultats avec le public, Snyk a suivi une procédure de divulgation responsable et a informé les mainteneurs concernés des problèmes, comme indiqué ici, afin de coordonner la résolution.

Je vous invite à en savoir plus sur les détails techniques de l’affaire liée à la chaîne d’approvisionnement VS Code dans l’article des chercheurs en sécurité de Snyk Raul Onitza-Klugman et Kirill Efimov, qui ont mené cette recherche, créé les preuves de concept et collaboré avec les mainteneurs des extensions pour remédier à la situation et préserver la sécurité de notre écosystème.

Atténuer les risques liés à la sécurité des extensions VS Code

En tant que développeur d’extensions ou de code en JavaScript, TypeScript ou Java, vous pouvez et devriez utiliser un outil qui vous aide à détecter les failles de sécurité pendant que vous codez dans votre IDE. Je ne parle pas d’un linter classique, mais de Snyk Code, un outil d’analyse statique de la sécurité des applications (SAST) récemment annoncé, que vous pouvez utiliser directement depuis votre IDE. Vous pouvez également l’exécuter avec la CLI Snyk : $ snyk code test.

Voici une capture d’écran de Snyk Code détectant cette vulnérabilité de traversée de chemin dans l’extension Instant Markdown pour VS Code :

IDE affichant du code TypeScript signalé par Snyk pour une vulnérabilité de traversée de chemin de gravité élevée (CWE-23).

Pour détecter les problèmes de sécurité liés à l’analyse statique du code dans plusieurs dépôts de projets, vous pouvez également importer vos dépôts GitHub dans Snyk, qui y recherchera les vulnérabilités potentielles. Voici les mêmes informations sur la vulnérabilité de traversée de chemin, annotées dans l’application Web Snyk :

Tableau d’analyse du code montrant une vulnérabilité de type « traversée de chemin » de gravité élevée dans du code TypeScript, avec l’appel vulnérable à sendFile mis en évidence

Du point de vue des développeurs qui utilisent l’IDE VS Code, il est important de prêter davantage attention aux extensions que vous installez. Malheureusement, la marketplace n’intègre actuellement aucun outil permettant de vérifier la sécurité des extensions. En revanche, pour les bibliothèques open source de vos projets, sur npm ou ailleurs, vous pouvez toujours utiliser Snyk (c’est gratuit !) pour détecter et corriger les vulnérabilités de sécurité dans ces packages.

Résumé

Les risques liés à la sécurité de la chaîne d’approvisionnement ne feront que s’amplifier, gagner en profondeur et cibler de plus en plus l’écosystème des développeurs. Nous espérons que la lecture de ces résultats de recherche vous sensibilisera davantage aux risques de sécurité potentiels et à leurs conséquences.

Si vous souhaitez assister à une démonstration en direct du piratage des extensions Visual Studio Code, je vous invite à regarder cette session le 8 juin à 15 h UTC avec Liran Tal, directeur de Developer Advocacy chez Snyk, et Kirill Efimov, chercheur en sécurité chez Snyk :

https://www.youtube.com/watch?v=pkvywMhd30c