Les 10 principales vulnérabilités des modèles GPT

Alors que les cyberattaques prolifèrent et que l’adoption d’applications reposant sur des grands modèles de langage à la GPT (LLM) progresse rapidement, la question de leur sécurité inquiète. Forts de leurs compétences, les groupes de cybercriminels pourraient non seulement exploiter les capacités des LLM pour développer des attaques - on pense notamment à la production automatisée de messages de phishing personnalisés - , mais aussi cibler les vulnérabilités des LLM pour atteindre les utilisateurs professionnels et privés et leurs données.

Dans son décret pour encadrer l’IA publié fin octobre, la Maison Blanche demande ainsi que les entreprises concevant les systèmes d’IA «les plus puissants» lui communiquent les résultats de leurs tests de sécurité. Et des sociétés s’invitent déjà sur le créneau à l’image de la start-up suisse Lakera qui a développé une API permettant de protéger les LLM contre certains scénarios d’attaque.

Le top 10 des vulnérabilités des LLM

Spécialisé dans la cybersécurité, l’Open Worldwide Application Security Project (OWASP) a réuni les contributions d’e plus d’une centaine d’experts pour dresser une liste des 10 vulnérabilités les plus critiques des applications reposant sur des grands modèles de langage (LLM). «La rapidité avec laquelle les équipes de développement adoptent les LLM a dépassé la mise en place de protocoles de sécurité complets, laissant de nombreuses applications vulnérables à des problèmes à haut risque. Le besoin d'une ressource unifiée traitant de ces problèmes de sécurité dans les LLM était évident. Les développeurs, peu familiarisés avec les risques spécifiques associés aux LLM, se retrouvaient avec des ressources dispersées, et la mission de l'OWASP semblait parfaitement adaptée pour contribuer à l'adoption plus sûre de cette technologie », explique la fondation.

Dans sa mise à jour, d’octobre dernier, OWASP présente les risques qui suivent. Les exemples indiqués proviennent également du billet de blog de Lakera consacré à ce top10.

1. Prompt injection. C’est sans conteste la technique dont on parle le plus. Le pirate élabore des prompts causant des actions indésirables de la part du modèle: fuite de données, exécution de code, génération de contenus offensants, etc. L’injection peut servir à forcer le modèle à contourner les protections mises en place par ses concepteurs. La manipulation peut être réalisée directement avec un prompt (« oublie toutes instructions »). Des chercheurs ont par exemple montré récemment qu’avec des prompts bien choisis, il est aisé de « forcer» une IA générative à produire des images à caractère sexuel. La manipulation peut aussi être réalisée indirectement en donnant au LLM une source tierce contrôlée par le pirate. Un pirate pourrait par exemple élaborer un CV contenant des instructions, de telle sorte que quand un recruteur voudra en faire un résumé avec un LLM, ce dernier appliquera les instructions et indiquera qu’il s’agit d’un excellent candidat.

2. Traitement non-sécurisé des outputs. Ce scénario implique que les contenus générés par le LLM alimentent directement une application. Dès lors que le prompt détermine l’output du modèle, un acteur malveillant pourrait s’en servir pour générer du code exécuté ensuite par l’application ou le navigateur (XSS), quand bien même il ne dispose pas des privilèges correspondants. OWASP donne l’exemple d’un LLM permettant d’élaborer des requêtes SQL à une base de données en back-end via une interface chat, et dont un utilisateur pourrait se servir pour demander d’effacer toutes les tables de ladite base.

3. Empoisonnement des données d’entraînement. Dans ce type d’attaque le pirate manipule les données d’entraînement ou de fine-tuning pour introduire des vulnérabilités, backdoors et autres biais dans le modèle en résultant. Signalons que ce même scénario peut être employé par des auteurs souhaitant nuire à des modèles d’IA génératives exploitant leurs oeuvres de façon indue.

4. Déni de service du modèle. Comme dans une attaque DDoS, un acteur malveillant peut inonder le LLM de requêtes, causant ainsi la saturation de ses ressources et pénalisant les autres utilisateurs. OWASP donne de multiples exemples de techniques permettant de surcharger le modèle, comme bombarder le modèle d’inputs excédant la taille limite autorisée ou au contraire des séries d’inputs juste dans la limite.

5. Vulnérabilités de la supply chain. Au même titre que les autres applications, l’ensemble de la chaîne de production des LLM peut présenter des vulnérabilités: les packages applicatifs tiers, les modèles pré-entraînés, les données d’entraînement (voir point 3), les modèles obsolètes ou non-maintenus, les plug-ins (voir point 7), ainsi que les conditions d’utilisation des données des entreprises opérant les modèles. OWASP donne l’exemple réel de pirates ayant exploité le dépôt de paquets open source Python PyPi pour inciter les développeurs à télécharger un paquet compromis pour exfiltrer des données dans un environnement de développement de modèles. En septembre, on apprenait aussi que l’équipe de recherche en IA de Microsoft avait involontairement donné accès à 38 téraoctets de données privées, dont les sauvegardes des stations de travail de deux employés. > Sur le sujet: notre dossier consacré à la sécurité de la supply chain logicielle

Illustration des différentes menaces pesant sur les grands modèles de langage. (Source: OWASP)

6. Fuite d’informations sensibles. Les applications recourant aux LLM peuvent révéler des informations sensibles ou protégées, des données confidentielles ou encore des algorithmes propriétaires. Dès lors que des données servent à entraîner les modèles, elles peuvent se retrouver dans leurs réponses, comme l’ont montré des chercheurs de l’EPFL avec des modèles de génération d’0images. Le risque est d'autant plus grand que les modèles sont « sur-entraînés » sur des données spécifiques (overfitting). C’est ce risque qui a conduit certaines entreprises à bannir l’emploi de LLM dans leur environnement, comme Samsung ou Microsoft! Les spécialistes de Lakera donnent l’exemple d’un utilisateur demandant à ChatGPT de prétendre être sa grand-mère et de lui réciter des clés de Windows 10 pour l’aider à s’endormir… Soulignons à ce titre que les extraordinaires capacités des LLM permettent aussi de découvrir automatiquement des informations sur des personnes qu’elles n’ont pourtant pas dévoilées.

7. Conception non-sécurisée de plug-ins. Au mois de mars, OpenAI annonçait l’arrivée de plug-ins permettant d’ajouter des fonctionnalités spécifiques à ChatGPT. Si elles ne sont pas développées dans les règles de l’art, ces extensions peuvent rendre le modèle vulnérable, en ne vérifiant pas assez les inputs et les autorisations. Lakera souligne que le plug-in devrait être protégé comme une API REST. OWASP donne l’exemple d’un plug-in acceptant une URL de base et demande au LLM de la combiner avec une requête pour obtenir des prévisions météorologiques servant à traiter la requête de l'utilisateur. Un utilisateur malveillant pourrait élaborer une requête de telle sorte que l'URL pointe vers un domaine qu'il contrôle, ce qui lui permet d'injecter son propre contenu dans le système LLM par l'intermédiaire de son domaine.

8. Autonomie excessive. Dans certains cas, le LLM peut être amené a exécuter des tâches et, si  son champs d’action n’est pas limité, cette autonomie peur causer des dommages. L’excès peut concerner aussi bien les privilèges accordés à l’agent LLM que ses fonctionnalités. Dévoilé au printemps dernier, AutoGPT était particulièrement sujet à de tels excès - un développeur en profitant d’ailleurs pour en créer la version maléfique ChaosGPT. OWASP donne l’exemple d’un assistant personnel basé sur un LLM ayant accès à la boîte mail d’une personne via un plug-in afin de résumer le contenu des messages électroniques entrants. Pour réaliser cette tâche, le plug-in doit être capable de lire les messages, mais le plug-in utilisé par le développeur du système est aussi capable d'envoyer des messages. Le LLM est dès lors vulnérable à une attaque par prompt injection indirecte, par laquelle un e-mail entrant malveillant incite le modèle à exploiter le plug-in pour envoyer du spam à partir de la boîte aux lettres de l'utilisateur.

9. Excès de confiance. Si les systèmes alimentés par les outputs des LLM peuvent être vulnérables (point 2), les personnes s’appuyant sur les informations générées peuvent être victimes d’excès de confiance. Les risques peuvent être importants lorsque des décisions sont prises à partir des informations fournies par les modèles ou lorsque le contenu généré est employé tel quel sans vérification. OWASP donne l’exemple d’un média utilisant intensément un modèle génératif et qui serait ciblé par un acteur malveillant qui alimenterait le modèle avec de fausses informations pour que celles-ci soient ensuite diffusées. Ou le cas d’un développeur faisant confiance au code suggéré par le modèle alors que celui-ci contient un package malveillant.

10. Vol du modèle. Dernier des dix scénarios mis en avant par OWASP, le modèle peut être lui-même dérobé par des pirates, par exemple en le compromettant, mais aussi en le copiant ou en extrayant ses poids et paramètres pour en créer un équivalent fonctionnel. « L'impact du vol d'un modèle de LLM peut inclure une perte économique et de réputation, l'érosion de l'avantage concurrentiel, l'utilisation non autorisée du modèle ou l'accès non autorisé à des informations sensibles contenues dans le modèle », avertit OWASP.

Outre la description de ces différentes vulnérabilités, le document d’OWASP disponible en ligne fournit également de nombreuses mesures pour les atténuer.