MIS À JOUR Un autre chasseur de bogues lésé a divulgué une vulnérabilité affectant un produit Microsoft après avoir été déçu par la manière dont l’entreprise gère les rapports de sécurité.
Ammar Askar a abandonné un exploit de preuve de concept (PoC) pour une faille de Visual Studio Code (VS Code) moins d’une heure après l’avoir divulgué à « un ancien contact » sur la plate-forme open source, selon son récit.
La vulnérabilité qu’il a exposée implique que des attaquants configurent des dépôts, qu’ils soient de leur propre initiative ou qu’ils ont compromis séparément, pour pousser des extensions VS Code malveillantes via sa fonctionnalité Workspace Recommendations, qui volent ensuite des jetons OAuth qu’ils peuvent ensuite utiliser pour lire/écrire des dépôts GitHub publics et privés.
AD ENREGISTREMENT
Cela affecte toute personne ayant déjà utilisé github.dev, une fonctionnalité qui permet aux utilisateurs d’ouvrir un dépôt GitHub dans une version basée sur un navigateur de VS Code.
AD ENREGISTREMENT
Askar a déclaré que la fonctionnalité est activée par github.com transmettant un jeton OAuth à github.dev et, surtout, ce jeton n’est pas limité au dépôt à partir duquel github.dev a été créé. Cela signifie que ce jeton peut donner à un attaquant l’accès à n’importe quel autre dépôt – public ou privé – auquel la cible a également accès.
L’exploit dépend de la capacité d’un attaquant à modifier le fichier .vscode/extensions.json d’un dépôt et à recommander une extension contrôlée par l’attaquant pour l’instance VS Code basée sur un navigateur.
Dans des scénarios normaux, une fenêtre contextuelle apparaîtrait demandant à un utilisateur d’accepter l’installation de cette extension, ce qui pourrait l’avertir d’un acte criminel.
Cependant, en raison de la manière dont l’attaquant fournit le dépôt à la cible, il dispose déjà d’un fichier Jupyter Notebook en cours d’exécution dans le github.dev de la cible avant que l’extension ne soit installée.
L’attaquant doit d’abord amener la cible à ouvrir son dépôt à l’aide d’un lien github.dev qui pointe vers ce fichier ipynb, que VS Code ouvre immédiatement dans une vue Web.
À l’intérieur du Jupyter Notebook se trouve un extrait HTML caché dans une cellule Markdown qui, une fois chargé, permet l’exécution du code JavaScript contrôlé par l’attaquant. Ce code déclenche un raccourci clavier simulé, que VS Code transmet à l’éditeur principal, incitant le système à accepter automatiquement la fenêtre contextuelle d’extension malveillante.
L’extension contrôlée par l’attaquant s’exécute ensuite avec accès à l’environnement du navigateur et vole le jeton OAuth, qui peut être utilisé pour lire et modifier n’importe quel dépôt public ou privé.
Askar a déclaré que les expériences négatives passées avec Microsoft Security Response Center (MSRC) ont influencé sa décision de ne pas passer par le processus de divulgation responsable typique, en publiant le PoC environ une heure après avoir informé son contact GitHub.
AD ENREGISTREMENT
« Pour résumer la dernière fois que j’ai interagi avec MSRC concernant le signalement d’un bug VSCode, ce fut une expérience horrible où ils ont corrigé silencieusement le bug que j’avais signalé sans aucun crédit », a-t-il écrit.
« Ils l’ont également marqué comme n’ayant aucun impact sur la sécurité. Comme je l’ai mentionné dans cet article, à l’avenir, je divulguerai publiquement tous les bogues de sécurité que j’ai trouvés dans VSCode. En jetant un coup d’œil à un rapport récent de Starlabs sur un bogue VSCode XSS marqué comme inéligible et de faible gravité, il ne semble pas que MSRC se soit amélioré en ce qui concerne les bogues VSCode.
« Je suis sûr que l’équipe de VSCode aurait apprécié une plus longue réflexion sur ce sujet pour trouver des solutions. Il y a légitimement un équilibre UI/UX ici qui doit être trouvé avec les problèmes de sécurité. Pour ces gens, je suis désolé, mais c’est l’un des rares leviers dont je dispose pour essayer d’influencer MSRC et la posture de sécurité de VSCode. Trouver et développer pleinement des bogues de sécurité en preuves de concept comme celle-ci prend du temps et des efforts de la part des chercheurs en sécurité qui ne doivent pas être manqués de respect ou pris pour compte. accordé. »
L’approche d’Askar n’est pas sans rappeler celle d’un chercheur connu sous le nom de Nightmare Eclipse, un ancien employé présumé de Microsoft qui a beaucoup attiré l’attention ces dernières semaines pour avoir divulgué des données Zero Day sans en informer Microsoft au préalable.
Le chercheur a jusqu’à présent publié six zero-day, dont trois ont été rapidement confirmés comme étant exploités par des attaquants sauvages.
En ce qui concerne leur motivation pour lancer cette attaque contre Microsoft, Nightmare Eclipse a déjà fait allusion à avoir été poignardé dans le dos et à se retrouver sans abri après un accord qui n’a pas été respecté – tout cela est très vague.
Après le sixième jour zéro, Microsoft a vaguement menacé le chercheur avec son unité de criminalité numérique, qui travaille en étroite collaboration avec les forces de l’ordre, avant de rapidement reculer après une vague de réponses négatives. ®
Mis à jour pour ajouter le 4 juin :
Microsoft a été en contact avec une déclaration : « 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 conclusions, nous restons déterminés à évaluer rapidement les problèmes signalés, à mobiliser les ressources d’ingénierie et de sécurité appropriées, et à fournir des mesures d’atténuation, des conseils et des protections le plus rapidement possible pour aider à protéger nos clients.
Un porte-parole de Microsoft nous a également déclaré que le problème signalé par Askar « a été atténué et qu’aucune action du client n’est requise ».
