if ( !emtpy($headline_subheadline ) ) : ?>
En exploitant la manière dont les agents de codage IA récupèrent et vérifient les plugins, les chercheurs ont pu exécuter du code malveillant même lorsque l’agent était invité à utiliser une version fiable et approuvée.
endif; ?>
Les agents de codage d’IA populaires tels que Codex d’OpenAI, Claude Code d’Anthropic, Gemini CLI de Google et GitHub Copilot, propriété de Microsoft, étaient vulnérables à une attaque sans clic qui permettait aux attaquants d’exécuter du code malveillant, même sans interaction du développeur, en échangeant un plugin fiable d’un marché en ligne contre un plugin malveillant, leur donnant potentiellement un pied dans les environnements de développement d’entreprise.
Les chercheurs de la startup de cybersécurité AIR ont découvert et signalé la faille, qu’ils appellent Plugin4Shell, aux fournisseurs concernés, et la plupart d’entre eux ont maintenant publié un correctif, ont écrit les chercheurs dans un article de blog jeudi.
Il s’agit d’« une faille qu’aucune place de marché ne peut corriger, les utilisateurs doivent donc mettre à jour leur agent », ont écrit les chercheurs.
Comment Claude Code, Codex et GitHub Copilot ont été exploités
Les entreprises utilisent généralement des plugins pour étendre les capacités de leurs agents de codage d’IA, donnant à l’agent l’accès à des outils, commandes et services externes supplémentaires qui peuvent l’aider à effectuer des tâches au-delà de la génération ou de la modification de code.
Lorsqu’un développeur installe un plugin, l’agent télécharge généralement son code à partir d’un référentiel Git et utilise un commit Git pour déterminer s’il exécute une copie approuvée du code, qui a été examinée et effacée par le développeur.
Cette vérification est effectuée à l’aide d’un algorithme de hachage sécurisé (SHA), un identifiant cryptographique unique attribué à chaque commit Git. Les développeurs peuvent donner à l’agent le SHA du commit examiné, lui indiquant d’exécuter cette copie spécifique du plugin.
Cependant, Claude Code, Codex et GitHub Copilot peuvent être amenés à exécuter du code malveillant au lieu du code de plugin de confiance associé au SHA, car ils transmettent le SHA directement à Git pour vérifier le code du plugin mais ne vérifient pas par la suite que Git a effectivement extrait le commit correspondant à ce SHA, ont écrit les chercheurs.
Cela signifie qu’un attaquant qui contrôle le référentiel du plugin, soit en publiant un plugin inoffensif et en le rendant ensuite malveillant, soit en prenant le contrôle du référentiel derrière un plugin fiable existant, peut exploiter cette lacune en créant une nouvelle version du référentiel contenant du code malveillant et en utilisant le SHA du commit légitime comme nom, ont expliqué les chercheurs.
En conséquence, lorsque l’agent demande à Git de vérifier le SHA, Git le résout en version contrôlée par l’attaquant, ce qui oblige l’agent à exécuter le code malveillant même s’il lui a été demandé d’utiliser la validation examinée, ont-ils déclaré.
Comment Plugin4Shell a compromis la CLI Gemini
L’attaque fonctionne différemment dans la CLI de Gemini, bien que le problème sous-jacent de l’agent ne vérifiant pas que Git a extrait la validation demandée reste le même.
Gemini CLI utilise d’abord le SHA pour indiquer à Git quelle version légitime du plugin récupérer. Après l’avoir récupéré, Gemini CLI demande à Git d’extraire ce code en utilisant le nom « FETCH_HEAD ».
Un attaquant qui contrôle le référentiel peut exploiter cela en créant une version malveillante du plugin et en lui donnant le même nom « FETCH_HEAD », créant ainsi une deuxième version que Git peut renvoyer lorsque Gemini CLI demande le code.
La vulnérabilité, découverte pour la première fois en mai et divulguée aux fournisseurs en juin, a depuis été corrigée dans certains des agents de codage concernés. Anthropic a résolu le problème dans la version 2.1.179 de Claude Code et OpenAI l’a résolu dans la version 0.146.0 du Codex, ont écrit les chercheurs. Google a déclaré qu’il avait abandonné la CLI Gemini et ne publierait donc pas de correctif, suggérant plutôt aux utilisateurs de passer à Antigravity.
GitHub n’a pas encore publié de correctif pour son Copilot, ont indiqué les chercheurs.
Un représentant de GitHub a déclaré à The Register qu’il appliquait déjà des restrictions sur la création de noms de versions ou de balises qui ressemblent à des SHA de validation, empêchant ainsi l’exploitation de la vulnérabilité signalée sur GitHub ou sur les plugins de son marché. Cependant, les chercheurs d’AIR ont déclaré à la publication que les restrictions de nommage de GitHub pourraient ne pas suffire à contrecarrer les attaques Plugin4Shell, car les marchés de plugins peuvent également être hébergés sur d’autres plates-formes, telles que Bitbucket.
Plugin4Shell pourrait élargir l’exposition aux systèmes d’entreprise
Selon Pareekh Jain, analyste principal chez Pareekh Consulting, cette lacune, associée à la probabilité que les entreprises exécutant les agents de codage concernés ne les aient pas encore corrigés ou mis à jour, pourrait exposer les environnements de développement à des attaques via des plugins compromis.
« Les entreprises utilisant des agents de codage d’IA avec des plugins tiers sont susceptibles d’être les plus exposées, en particulier lorsque ces agents ont accès au code source, aux informations d’identification, aux systèmes cloud ou aux outils CI/CD, car ces plugins fonctionnent pour la plupart avec le même accès dont dispose le développeur ou l’employé », a-t-il déclaré.
Cela signifie que ces plugins malveillants pourraient aider les attaquants à accéder au code source, à voler des clés API ou des informations d’identification cloud, à modifier des référentiels ou potentiellement à atteindre CI/CD et d’autres systèmes d’entreprise, a ajouté Jain.
Que peuvent faire les entreprises pour atténuer les risques ?
« Les équipes de sécurité doivent examiner les machines qui exécutent ces agents vulnérables. Les signes d’avertissement importants incluent des processus ou des connexions réseau inhabituels, des fichiers de plug-in inattendus, des référentiels sources modifiés, une activité Git suspecte et une utilisation inhabituelle des informations d’identification du développeur ou du cloud », a déclaré Jain.
« EDR, Git, CI/CD, cloud IAM et les journaux d’authentification sont de bons endroits pour enquêter », a-t-il ajouté.
D’autres mesures, selon l’analyste, incluent la vérification si leurs agents de codage se mettent à jour automatiquement pour s’assurer qu’ils ont reçu les correctifs des fournisseurs qui les ont appliqués.
Cependant, ces étapes ne font que réduire le risque mais ne corrigent pas la vulnérabilité sous-jacente.
« La vulnérabilité sous-jacente relève en fin de compte de la responsabilité du fournisseur, car elle découle de la manière dont les agents vérifient le code qu’ils sont chargés d’exécuter. Ils doivent s’assurer que le code en cours d’exécution est bien le code qui a été examiné et approuvé », a déclaré Jain.
« Les entreprises peuvent contrôler l’utilisation des plugins, mais elles ne peuvent pas corriger un défaut dans la manière dont l’agent de codage valide le code qu’il vérifie », a-t-il ajouté.
InfoMonde
