Un trou dans l’éditeur VSCode basé sur le navigateur de GitHub pourrait conduire au vol d’un jeton

Une vulnérabilité dans l’éditeur VSCode basé sur le navigateur de GitHub pourrait conduire au vol du jeton d’un développeur dans certaines circonstances, explique un chercheur.

Le problème, révélé cette semaine dans un blog d’Ammar Askar, a apparemment déjà été résolu par Microsoft, propriétaire de GitHub. Mais cela soulève des questions à la fois sur la sécurité DevOps et sur l’allégation du chercheur selon laquelle, parce que Microsoft ne prend pas au sérieux les découvertes de bugs, il peut justifier de lui donner un court préavis avant de publier ouvertement les vulnérabilités qu’il trouve.

Tout d’abord, le bug : les utilisateurs de ne s’en rendent peut-être pas compte, mais lorsqu’ils se trouvent sur n’importe quel référentiel, ils peuvent passer à sa version basée sur un navigateur de VSCode simplement en modifiant l’URL.

Pourquoi faire ça ? Parce que l’instance de navigateur de VSCode est assez puissante, explique Askar sur son blog. « Vous pouvez afficher tous les fichiers du dépôt (même s’il est privé), vous pouvez envoyer des demandes d’extraction et même effectuer des validations. »

Rob Enderle, un consultant informatique qui dirige le groupe Enderle, convient que sauter dans VSCode de cette façon est « un outil tactique incroyablement utile pour des tâches rapides. En appuyant simplement sur le ‘. » saisissez n’importe quel dépôt GitHub, vous obtenez instantanément une interface VS Code basée sur un navigateur sans avoir à cloner des gigaoctets de données localement. Il est parfait pour des révisions rapides de relations publiques, des modifications rapides de documentation ou pour naviguer dans le code à la volée sans interrompre votre flux de travail. Gardez simplement à l’esprit qu’il s’exécute entièrement dans le bac à sable du navigateur ; il n’y a pas de backend de calcul, pas de terminal et pas d’exécution de code.

Pour toute tâche lourde ou toute compilation réelle, a-t-il ajouté, le développeur aura toujours besoin du calcul brut d’un poste de travail local ou d’un environnement cloud complet comme Codespaces.

Le problème, dit Askar, est que cette fonctionnalité est obtenue en POSTant sur un jeton OAuth qui lui permet d’interagir avec GitHub en votre nom. « Le jeton n’est pas limité au dépôt particulier avec lequel vous avez interagi, ce qui signifie qu’il a un accès complet à tous les autres dépôts auxquels vous avez accès », a-t-il écrit sur le blog.

« La présence de ce jeton et le fait que cette application Web exécute presque tout le poids de la base de code Typescript d’un million de lignes de VSCode, en fait une cible idéale pour quiconque étudie les bogues de VSCode », a-t-il écrit.

L’exploit

Askar a déclaré qu’un acteur malveillant pourrait installer une extension dans un référentiel à l’aide d’un bloc-notes Jupyter, une application Web permettant de créer et de partager des documents informatiques qui a la capacité d’installer une extension d’espace de travail local malveillante tout en ignorant la vérification de la confiance de l’éditeur. Dans sa preuve de concept, Askar a déclaré qu’une fois sa charge utile exécutée, l’extension nouvellement installée récupérera le jeton de l’API GitHub, exécutera une requête pour obtenir les dépôts privés auxquels le développeur a accès, puis imprimera les réponses et le jeton.

Cette vulnérabilité existe également dans la version de bureau de VSCode, a déclaré Askar, bien qu’elle soit plus difficile à exploiter, car un acteur malveillant devrait convaincre la victime de cloner son dépôt et d’ouvrir le bloc-notes contenant la charge utile du script WebView. « Bien sûr », a-t-il ajouté, « si vous (le pirate informatique) aviez un autre XSS (attaque de script intersite) dans une vue Web que vous pouvez faire ouvrir par une victime, vous obtenez effectivement un RCE (exécution de code à distance) complet sur son ordinateur. »

Dans un e-mail, il a déclaré que cette vulnérabilité était « aussi grave que possible. N’importe quel site Web sur Internet aurait pu vous rediriger vers un lien qui aurait pu fournir à un attaquant un jeton pour lire et modifier vos dépôts de code. Si l’on pouvait convaincre le responsable d’un projet logiciel populaire de cliquer sur un lien, il aurait pu apporter toutes les modifications qu’il souhaitait à son projet. « 

Cela signifie, a déclaré Enderle, « nous devons commencer à traiter les points de terminaison des développeurs avec des paramètres stricts, isolés et de confiance zéro, car nous ne pouvons clairement pas compter sur la complaisance des fournisseurs pour nous protéger ».

Ce problème renforce le point selon lequel vous ne devez jamais suivre de liens à moins de savoir exactement où ils vous mèneront, a ajouté Dwayne McDaniel, principal défenseur des développeurs chez GitGuardian.

Court préavis

C’est ici que les choses se compliquent. En raison d’une expérience malheureuse lors de la divulgation d’une précédente vulnérabilité VSCode à Microsoft – le bug a été corrigé, mais Askar n’a pas reçu de crédit – cette fois, il n’a donné à GitHub qu’un préavis d’une heure pour que cette nouvelle découverte allait être publiée. Microsoft a appliqué ce qu’Askar appelle un correctif « provisoire » en ajoutant une confirmation lorsqu’un développeur ouvre des blocs-notes dans le VSCode Web et en ne permettant pas que l’exigence soit ignorée par les commandes.

(Contenu connexe : Quand la divulgation responsable devient un travail non rémunéré)

Une question éthique

Le court préavis d’Askar soulève une question éthique : combien de temps à l’avance un chercheur responsable doit-il informer un fournisseur d’une vulnérabilité avant de la révéler publiquement ?

De nos jours, la plupart des professionnels de la sécurité de l’information conviennent qu’un préavis doit être donné, sinon un acteur malveillant peut rapidement exploiter une faille. De plus, le chercheur risque de nuire à sa réputation s’il ne reçoit pas un préavis raisonnable. Les chercheurs expérimentés donnent souvent aux fournisseurs au moins 30 jours pour créer et distribuer un correctif.

De leur côté, les fournisseurs créent souvent des programmes de bug bounty, ou s’associent à des programmes de bug bounty, pour récompenser les chercheurs pour leur travail. Malheureusement, certains fournisseurs ne créditent pas toujours les chercheurs ou ne minimisent pas les dommages qu’une vulnérabilité peut causer. En fait, le mois dernier, Microsoft et un éminent chercheur en cybersécurité se sont lancés dans une dispute publique au sujet d’un de ces incidents présumés.

Un déséquilibre des pouvoirs

Interrogé sur la découverte la plus récente d’Askar, un porte-parole de Microsoft a déclaré : « Nous apprécions le rôle essentiel que joue la communauté de recherche en sécurité dans le renforcement de la sécurité de nos produits, services et de l’écosystème technologique plus large. Tandis que des chercheurs indépendants déterminent quand et comment publier leurs résultats, nous restons déterminés à évaluer rapidement les problèmes signalés, à mobiliser les ressources d’ingénierie et de réponse de sécurité appropriées et à fournir des atténuations, des conseils et des protections le plus rapidement possible pour aider à protéger nos clients. « 

(Contenu associé : le processus de divulgation des vulnérabilités est-il défectueux ?)

Il existe un équilibre entre la coordination de la divulgation avec un fournisseur de logiciels (CVD) et la divulgation complète, nous a expliqué Askar. Mais, a-t-il ajouté, il existe un déséquilibre des pouvoirs. « Un chercheur en sécurité peut consacrer d’innombrables heures à un problème, en s’assurant qu’il développe une bonne preuve de concept et fournit toutes les étapes nécessaires pour recréer le problème. Avec cela, il espère au moins obtenir une reconnaissance pour ses efforts, qu’il pourra utiliser pour améliorer ses antécédents en matière de sécurité ou, dans le meilleur des cas, une récompense monétaire. »

Cependant, a-t-il ajouté, « si les fournisseurs de sécurité ne respectent pas leur part du marché, la divulgation publique est l’une des rares options dont disposent les chercheurs en sécurité (s’ils ne veulent pas s’asseoir sur leurs vulnérabilités ou les vendre sur le marché noir). Cela oblige le fournisseur à reconnaître publiquement le problème de sécurité et conduit généralement à une résolution beaucoup plus rapide que n’importe quelle communication privée. « 

Selon Enderle, cela crée des problèmes pour les entreprises : « Lorsque la bureaucratie des fournisseurs pénalise la divulgation responsable, elle aliène la communauté de la sécurité et impose des abandons publics Zero Day, laissant finalement les entreprises clientes porter le sac. »