Une extension VS Code piégée a volé 3 800 dépôts internes de GitHub

GitHub enquête sur un accès non autorisé à ses dépôts internes et confirme qu’un attaquant a réussi à exfiltrer des données depuis environ 3 800 d’entre eux. L’intrusion est arrivée par une extension piégée de Visual Studio Code installée par un salarié, donnant à l’attaquant l’accès à cette machine puis, depuis elle, à du code interne qui devait rester derrière les murs de l’entreprise.

La frontière que GitHub désigne, entre les dépôts internes et la plateforme tournée vers les clients, est la seule chose qui sépare un incident contenu d’une urgence mondiale de chaîne d’approvisionnement. GitHub héberge environ 100 millions de développeurs et une part significative du code open source sur lequel repose l’internet moderne. Quand l’entreprise dit « interne », elle parle du code de sa propre plateforme, de ses outils, de sa configuration opérationnelle, de la matière avec laquelle GitHub se construit et s’exécute lui-même. Les organisations clientes, les entreprises et les dépôts publics ou privés que ces clients stockent sur GitHub se trouvent, selon l’entreprise, hors du rayon d’impact de cette intrusion.

Cette distinction fait un travail considérable dans le communiqué publié par l’entreprise sur son compte X officiel. « Bien que nous n’ayons actuellement aucune preuve d’impact sur les informations clients stockées en dehors des dépôts internes de GitHub », peut-on y lire, « nous surveillons étroitement notre infrastructure pour toute activité ultérieure ». La formulation est précise, et la précision dans un avis de violation signifie généralement que l’enquête est toujours en cours. « Aucune preuve d’impact » n’est pas équivalent à « aucun impact ». Les incidents touchant les grandes plateformes ont l’habitude de croître à mesure que l’analyse forensique rattrape l’activité de l’attaquant, et la ligne entre systèmes internes et systèmes orientés clients est rarement un mur physique propre. C’est un ensemble de contrôles d’accès, d’identifiants et de comptes de service qu’il faut traiter un à un.

Vous pourriez aussi aimerUne IA a écrit un exploit zero-day fonctionnel — Google l’a intercepté à temps

Le mécanisme est la partie de cette histoire qui devrait inquiéter chaque développeur. Visual Studio Code est l’éditeur de code dominant de la planète, présent dans presque toutes les grandes organisations d’ingénierie. Sa place de marché d’extensions fonctionne sur la confiance communautaire : n’importe qui peut publier, et la plupart des ingénieurs installent des plug-ins avec la même légèreté qu’ils ajoutent des favoris dans leur navigateur. Une extension piégée diffusée par ce canal et exécutée sur une machine de développeur donne à l’attaquant accès à tout ce que la session de ce développeur peut atteindre : dépôts, tokens, registres de paquets, services internes. Le nom précis de l’extension utilisée dans ce cas n’a pas encore été rendu public, mais le schéma n’est pas nouveau. Nx Console, une extension populaire d’outillage pour développeurs, a subi une compromission similaire.

Le groupe qui se fait appeler TeamPCP a revendiqué l’intrusion et propose le jeu de données à la vente sur des forums clandestins avec un plancher à cinquante mille dollars. Le cadrage du groupe, « ce n’est pas une rançon », est en soi un signal. Ils ne cherchent pas à extorquer directement GitHub. Ils traitent du code source interne volé comme d’autres criminels traitent les dumps de cartes bancaires : une marchandise avec des acheteurs. Quiconque finira avec cette archive de 3 800 dépôts la peignera pour trouver des identifiants intégrés, des secrets codés en dur, des détails utiles à une attaque contre l’infrastructure propre de GitHub et tout ce qui peut servir à compromettre des cibles en aval. Le même groupe est rattaché au ver Mini Shai-Hulud qui a frappé le paquet durabletask sur PyPI, ce qui souligne le vrai sujet de cette histoire : les attaques sur la chaîne d’approvisionnement du développement sont passées du scénario théorique à l’artisanat opérationnel.

La réponse de confinement, dans la propre description de GitHub, a été rapide. La machine compromise a été isolée. L’extension malveillante a été retirée. L’entreprise affirme avoir fait tourner des secrets critiques en priorisant les identifiants à plus fort impact, et qu’elle préviendra les clients affectés par ses canaux d’incident-response habituels si l’enquête s’élargit. La filiale de Microsoft n’a pas identifié le salarié de GitHub dont la machine a été compromise, n’a pas nommé l’extension et n’a pas précisé pendant combien de temps l’attaquant a eu accès avant la détection. Ces détails apparaissent généralement dans le rapport post-incident plus long, publié plusieurs semaines après l’avis initial.

Pour le reste du secteur, la leçon pratique est plus simple que l’emballage de threat intelligence ne le laisse entendre. Toute organisation d’ingénierie n’est qu’à une installation d’extension négligente du même incident. Toute personne ayant déjà installé une extension VS Code recommandée dans un fil de forum a couru le même risque qui s’est abattu sur un salarié de GitHub. Les défenses qui fonctionnent sont connues et inégalement appliquées : restreindre l’installation d’extensions à une liste autorisée vérifiée, isoler les postes de développeur des identifiants de production, faire tourner les secrets à cadence rapide. Cette violation va les pousser en haut de la liste des priorités dans les entreprises qui les avaient repoussées.

GitHub n’a pas donné de calendrier pour un post-mortem public complet. Les enquêtes de cette taille sur des plateformes de cette échelle prennent généralement plusieurs semaines pour révéler toute leur portée, et les mises à jour arriveront par les canaux officiels de l’entreprise au fur et à mesure. Le prochain élément à surveiller est de savoir si l’archive de 3 800 dépôts apparaît réellement à la vente et à quel prix le plancher se déplace une fois que le marché clandestin a eu quelques jours pour examiner l’index.

Plus comme ceci

Une faille de connexion laisse 70 millions de sites cPanel ouverts à n’importe qui

Un balayage de 380 000 applis construites avec l’IA en trouve des milliers sans aucune authentification