L’année dernière, l’Open Worldwide Application Security Project (OWASP) a publié plusieurs versions du « OWASP Top 10 pour les grands modèles de langage« , atteignant un document 1.0 en août et un document 1.1 en octobre. Ces documents démontrent non seulement la nature évolutive rapide des grands modèles linguistiques, mais aussi les manières évolutives dont ils peuvent être attaqués et défendus. Nous allons en parler dans ce article sur quatre éléments de ce top 10 qui sont les plus susceptibles de contribuer à la divulgation accidentelle de secrets tels que des mots de passe, des clés API, etc.
Nous savons déjà que les LLM peuvent révéler des secrets parce que cela s’est produit. Début 2023, GitGuardian a signalé avoir trouvé plus de 10 millions de secrets dans les commits publics de Github. L’outil de codage Copilot AI de Github a été formé sur des engagements publics, et en septembre 2023, des chercheurs de l’Université de Hong Kong ont publié un article sur la façon dont ils ont créé un algorithme qui a généré 900 invites conçues pour amener Copilot à révéler les secrets de ses données de formation. Lorsque ces invites ont été utilisées, Copilot a révélé plus de 2 700 secrets valides.
La technique utilisée par les chercheurs est appelée « injection rapide ». Il est n°1 dans le Top 10 OWASP pour les LLM et ils le décrivent comme suit : [blockquote]
« Cela manipule un grand modèle de langage (LLM) via des entrées astucieuses, provoquant des actions involontaires de la part du LLM. Les injections directes écrasent les invites du système, tandis que les injections indirectes manipulent les entrées provenant de sources externes. »
Vous êtes peut-être plus familier avec l’injection rapide du bug révélé l’année dernière qui faisait que ChatGPT commençait à cracher des données d’entraînement si vous lui demandiez de répéter certains mots pour toujours.
Astuce 1 : faites pivoter vos secrets
Même si vous ne pensez pas avoir accidentellement publié des secrets sur GitHub, un certain nombre de secrets qu’il contient ont été commis lors d’un premier commit et écrasés dans un commit plus récent, ils ne sont donc pas immédiatement apparents sans examiner l’intégralité de votre historique de commit, pas seulement l’état actuel de vos référentiels publics.
Un outil de GitGuardian, appelé Mon secret a-t-il été divulgué, vous permet de chiffrer un secret actuel, puis de soumettre les premiers caractères du hachage pour déterminer s’il y a des correspondances dans leur base de données avec ce qu’ils trouvent dans leurs analyses de GitHub. Une correspondance positive ne garantit pas que votre secret a été divulgué, mais offre une probabilité potentielle que cela se soit produit afin que vous puissiez enquêter plus en profondeur.
Les mises en garde concernant la rotation des clés/mots de passe sont que vous devez savoir où ils sont utilisés, ce qui pourrait se briser lorsqu’ils changent et avoir un plan pour atténuer cette rupture pendant que les nouveaux secrets se propagent aux systèmes qui en ont besoin. Une fois la rotation terminée, vous devez vous assurer que les anciens secrets ont été désactivés.
Les attaquants ne peuvent pas utiliser un secret qui ne fonctionne plus et si vos secrets qui pourraient se trouver dans un LLM ont été modifiés, ils ne deviennent alors rien d’autre que des chaînes inutiles à haute entropie.
Astuce 2 : Nettoyez vos données
L’élément n°6 du Top 10 de l’OWASP pour les LLM est « Divulgation d’informations sensibles » :
Les LLM peuvent révéler par inadvertance des données confidentielles dans leurs réponses, entraînant un accès non autorisé aux données, des violations de la vie privée et des failles de sécurité. Il est crucial de mettre en œuvre une désinfection des données et des politiques utilisateur strictes pour atténuer ce problème.
Bien que des invites délibérément conçues puissent amener les LLM à révéler des données sensibles, elles peuvent également le faire accidentellement. La meilleure façon de garantir que le LLM ne révèle pas de données sensibles est de s’assurer qu’il ne le sache jamais.
Ceci est plus ciblé lorsque vous formez un LLM destiné à être utilisé par des personnes qui n’ont pas toujours à cœur vos meilleurs intérêts ou des personnes qui ne devraient tout simplement pas avoir accès à certaines informations. Qu’il s’agisse de vos secrets ou de votre sauce secrète, seuls ceux qui ont besoin d’y avoir accès devraient y avoir… et votre LLM ne fait probablement pas partie de ces personnes.
L’utilisation d’outils open source ou de services payants pour analyser vos données de formation à la recherche de secrets AVANT de transmettre les données à votre LLM vous aidera à supprimer les secrets. Ce que votre LLM ne sait pas, il ne peut pas le dire.
Astuce 3 : appliquez régulièrement des correctifs et limitez les privilèges
Récemment, nous avons vu un article sur l’utilisation des fichiers .env et des variables d’environnement comme moyen de garder les secrets disponibles pour votre code, mais en dehors de votre code. Mais que se passerait-il si l’on pouvait demander à votre LLM de révéler des variables d’environnement… ou de faire quelque chose de pire ?
Cela combine à la fois l’élément n°2 (« Gestion des sorties non sécurisées ») et l’élément n°8 (« Agence excessive »).
- Gestion des sorties non sécurisées : Cette vulnérabilité se produit lorsqu’une sortie LLM est acceptée sans examen minutieux, exposant les systèmes backend. Une mauvaise utilisation peut entraîner de graves conséquences telles que XSS, CSRF, SSRF, une élévation de privilèges ou l’exécution de code à distance.
- Agence excessive : Les systèmes basés sur LLM peuvent entreprendre des actions entraînant des conséquences inattendues. Le problème provient d’une fonctionnalité, d’autorisations ou d’une autonomie excessives accordées aux systèmes basés sur LLM.
Il est difficile de les séparer les uns des autres car ils peuvent s’aggraver mutuellement. Si un LLM peut être amené à faire quelque chose et que son contexte de fonctionnement dispose de privilèges inutiles, le risque qu’une exécution de code arbitraire puisse causer des dommages majeurs se multiplie.
Chaque développeur a vu le « Exploits d’une maman » dessin animé où un garçon nommé `Robert »); DROP TABLE Students; »` efface la base de données des étudiants d’une école. Bien qu’un LLM semble intelligent, il n’est vraiment pas plus intelligent qu’une base de données SQL. Et comme votre frère « comédien » qui demande à votre neveu de répéter de gros mots à grand-mère, de mauvaises entrées peuvent créer mauvais résultats. Les deux doivent être nettoyés et considérés comme peu fiables.
De plus, vous devez mettre en place des garde-fous autour de ce que le LLM ou l’application peut faire, en tenant compte des principe du moindre privilège. Essentiellement, les applications qui utilisent ou activent le LLM et l’infrastructure LLM ne doivent avoir accès à aucune donnée ou fonctionnalité dont elles n’ont pas absolument besoin afin de ne pas les mettre accidentellement au service d’un pirate informatique.
L’IA peut encore être considérée comme en est à ses balbutiements et, comme pour tout bébé, elle ne devrait pas avoir la liberté de se déplacer dans une pièce que vous n’avez pas sécurisée. Les LLM peuvent mal comprendre, halluciner et être délibérément égarés. Lorsque cela se produit, de bons verrous, de bons murs et de bons filtres devraient les empêcher d’accéder ou de révéler des secrets.
En résumé
Les grands modèles de langage sont un outil formidable. Ils sont appelés à révolutionner de nombreux métiers, processus et industries. Mais ils sont loin d’une technologie mature, et beaucoup les adoptent imprudemment par peur d’être laissés pour compte.
Comme vous le feriez avec tout bébé suffisamment mobile pour avoir des ennuis, vous devez le surveiller et verrouiller toutes les armoires dans lesquelles vous ne voulez pas qu’il entre. Procédez avec des modèles de langage volumineux, mais procédez avec prudence.