Une faille dans l’assistant Duo de GitLab remet en lumière la sécurité des LLM

Sombre héros

En fin de semaine dernière, des chercheurs ont montré comment on pouvait détourner l’assistant Duo de GitLab pour déclencher des attaques et fuites de données. La fonction, dopée à l’IA est vulnérable aux injections de messages, mais souligne le problème plus général des assistants, faisant entrer la communauté de la sécurité dans un nouveau domaine à part entière.

Duo est un assistant IA commercialisé par GitLab pour faciliter – comme toujours – les opérations liées au développement. Il est basé sur les modèles Claude d’Anthropic et permet, dans sa version premium, de fournir des suggestions de code, de contrôler les publications, d’analyser tous les commits pour générer une liste de tâches liées, etc. Des capacités désormais courantes pour les assistants accompagnant ces plateformes, comme Copilot chez GitHub.

Le 15 mai, des chercheurs de Legit Security ont présenté les résultats de leurs travaux sur la sécurité de Duo. La conclusion est peu glorieuse : « Un commentaire caché a suffi pour que GitLab Duo fuite du code source privé et injecte du HTML non fiable dans ses réponses ». L’équipe ajoute que le problème a été corrigé par GitLab, leur permettant de détailler la technique utilisée, basée sur cinq failles du TOP 10 du OWASP 2025 pour les grands modèles de langage.

Pour comprendre ce qu’ont fait les chercheurs, il faut rappeler le type d’attaque le plus courant auquel sont soumis les LLM : l’injection de messages. Le principe est simple, puisqu’il faut amener le modèle à interpréter une demande pour lui faire effectuer une tâche ayant un débouché malveillant. La source de l’attaque elle-même est donc facile à placer, car il peut s’agir d’une simple ligne de code ou même en langage naturel, que l’on trouvera dans le code d’un programme à analyser ou dans un texte quelconque, comme le contenu d’un e-mail. Et puisque les assistants IA brassent des quantités parfois énormes d’informations provenant de multiples sources, le champ est vaste.

Ce qu’ont fait les chercheurs

Puisque les sources peuvent être nombreuses, les chercheurs n’ont eu que l’embarras du choix : commits, demandes de fusion, descriptions, code source, commentaires dans le code, etc. Leur objectif a été de démontrer comment, en se servant de ces sources, ils pouvaient amener Duo à réaliser des actions malveillantes.

Une variante de l’attaque a ainsi consisté à introduire une instruction, au travers d’un simple commentaire, demandant à Duo d’inspecter le code source et de décrire son fonctionnement.

L’instruction était d’insérer dans la réponse un lien vers un site, qui se trouvait être malveillant. La description elle-même paraissait inoffensive. Le lien était écrit en caractères Unicode, invisibles pour l’œil humain, mais qui étaient quand même interprétés par Duo. L’attaque se servait du langage Markdown pour générer du texte brut, les URL générées étant par ailleurs cliquables.

Jusqu’à l’exfiltration de données

Le code en Markdown est analysé de manière asynchrone. Traduction, le rendu des instructions est réalisé ligne par ligne, au fur et à mesure, plutôt que d’attendre que l’analyse soit allée jusqu’au bout pour effectuer tout le rendu d’une traite. C’est l’une des plus grosses faiblesses pointées par les chercheurs puisqu’elle permet d’ajouter des balises HTML comme <img> et <form>, ouvrant la voie à d’autres types d’attaques basées sur des images et des formulaires.

Ces possibilités autorisent également l’exfiltration d’informations normalement privées. Par exemple, il est possible d’intégrer une instruction dans le code ou dans une demande de fusion pour réclamer l’accès à des informations. Puisque Duo accède aux ressources du développeur qui l’utilise, l’instruction va y accéder, les convertir en code base64 et ajouter le résultat dans la balise d’une requête GET envoyée à un site contrôlé par la personne visée. Ce code va alors apparaître dans les journaux (logs) du site, permettant sa récupération.

Pour donner une idée, les chercheurs ont été capables, via ces techniques, d’exfiltrer du code source de dépôts privés, ou encore des rapports confidentiels sur la sécurité. Puisque Duo y avait accès du côté des utilisateurs visés, il pouvait transmettre ces informations.

Les assistants IA amènent leur propre surface d’attaque

Sans surprise, les chercheurs ont signalé ces comportements à GitLab le 12 février dernier. L’entreprise a confirmé peu de temps après la vulnérabilité de son service aux injections HTML et qu’il s’agissait d’un problème de sécurité. Environ un mois plus tard, la version duo-ui!52 a été publiée, venant colmater la faille. Le problème a été réglé en empêchant désormais Duo d’effectuer le rendu de certaines balises comme <img> et <form> quand elles pointent vers des domaines externes. Les chercheurs ont confirmé dans leur compte rendu que leur chaine d’attaque ne fonctionnait plus depuis cette version.

Il s’agit cependant d’un cas très représentatif, selon les chercheurs, de la nature « à double-tranchant » des assistants de type IA, notamment du fait de leur intégration profonde dans les flux de travail. Ainsi, « ils héritent non seulement du contexte, mais aussi du risque ». Ils indiquent que la solution adoptée par GitLab est classique dans ce contexte et a été également choisie par d’autres entreprises proposant ce type d’assistant.

Mais même si les assistants rendent des services parfois puissants et corrigent leurs failles, la conclusion des chercheurs est que ces fonctions « font désormais partie de la surface d’attaque de votre application ». Selon eux, il faut partir du principe que tout système permettant à des LLM d’ingérer du contenu contrôlé par un utilisateur doit traiter les entrées liées « comme non fiables et potentiellement malveillantes ».

Une lumière plus crue sur la sécurité des LLM

Certains aspects de ce problème sont plus évidents que d’autres pour les développeurs, selon Legit Security, notamment tout ce qui touche au code proprement dit. Dans le cadre d’un outil comme Duo cependant, l’assistant accède aussi à de nombreuses données moins évidentes selon le degré d’entrainement, comme les discussions internes, les informations de sécurité ou encore les rapports d’incidents. Par exemple, un contributeur ouvre une question privée décrivant une vulnérabilité 0-day tout juste découverte. Avec le processus décrit dans le rapport, il était possible de récupérer ces informations et de les utiliser.

La puissance des outils dopés à l’IA est donc certaine, mais demande également d’aborder la sécurité sous un nouvel angle. Comme n’importe quel autre programme, ils amènent leur propre surface d’attaque, avec un danger proportionnel aux informations qu’ils doivent traiter. Les chercheurs recommandent donc, comme on s’en doute, la prudence.

La découverte de Legit Security se fait dans un contexte plus général « d’éveil » à ces risques. Comme l’indique par exemple The Hacker News, d’autres travaux explorent plus spécifiquement ces problèmes de sécurité. Par exemple, des recherches publiées le 15 mai portent sur la menace croissante des « LLM sombres » ou « non alignés ». Il s’agit de modèles conçus spécifiquement sans garde-fous et autres barrières éthiques ou modifiés par des techniques de jailbreak, ces derniers faisant sauter les verrous. Ils indiquaient avoir découvert une méthode pour se débarrasser de ces barrières sur « plusieurs modèles de pointe », leur permettant alors de répondre à n’importe quelle question. Microsoft avertissait également de ce problème début décembre 2024.

Auteur : Vincent Hermann

Aller à la source