Zoom sur les dix vulnérabilités critiques ciblant les LLM

L'Open Worldwide Application Security Project (OWASP) a publié les 10 vulnérabilités les plus critiques souvent observées affectant les grands modèles de langage (LLM) embarquées dans des applications IA, en soulignant leur impact potentiel, leur facilité d'exploitation et leur prévalence. Parmi les exemples de vulnérabilités figurent les injections rapides, les fuites de données, le sandboxing inadéquat et l'exécution de code non autorisée. Cette liste vise à sensibiliser les développeurs, les concepteurs, les architectes - et plus globalement les entreprises - aux risques de sécurité potentiels lors du déploiement et de la gestion des LLM. Et à suggérer des stratégies de remédiation en améliorant la posture de sécurité des applications LLM.

L'émergence d'interfaces de chat génératives basées sur des LLM et leur impact sur la cybersécurité est un sujet de discussion majeur. Les inquiétudes concernant les risques que ces nouvelles technologies pourraient introduire vont des problèmes potentiels liés au partage d'informations commerciales sensibles avec des algorithmes d'auto-apprentissage avancés, aux acteurs malveillants qui les utilisent pour renforcer considérablement les attaques. Certains pays et entreprises envisagent d'interdire l'utilisation de technologies d'IA générative telles que ChatGPT, ou l'ont déjà fait, pour des raisons de sécurité des données, de protection et de respect de la vie privée. Zoom sur les 10 vulnérabilités les plus critiques affectant les applications LLM et moyens de limiter leurs dégâts potentiels.

1. Attaque par injection d'invite

Les injections d'invites consistent à contourner les filtres ou à manipuler le modèle à l'aide d'invites soigneusement conçues qui font que le modèle ignore les instructions précédentes ou exécute des actions involontaires, fait savoir l'OWASP. « Ces vulnérabilités peuvent avoir des conséquences inattendues, notamment des fuites de données, des accès non autorisés ou d'autres atteintes à la sécurité ». Les failles les plus courantes en matière d'injection d'invite consistent à contourner les filtres ou les restrictions en utilisant des modèles de langage ou des jetons spécifiques, à exploiter les faiblesses des mécanismes de symbolisation ou d'encodage du LLM et à l'induire en erreur pour qu'il effectue des actions non souhaitées en fournissant un contexte trompeur.

Un exemple de scénario d'attaque est celui d'un utilisateur malveillant qui contourne un filtre de contenu en utilisant des modèles de langage, des jetons ou des mécanismes d'encodage spécifiques que le LLM ne parvient pas à reconnaître comme du contenu restreint, ce qui permet à l'utilisateur d'effectuer des actions qui devraient être bloquées, explique l'OWASP. Les mesures préventives pour cette vulnérabilité sont les suivantes :

- Mettre en œuvre une validation d'entrée et un nettoyage strict pour les invites fournies par l'utilisateur ;
- Utiliser un filtrage contextuel et un encodage de sortie pour empêcher la manipulation des invites ;
- Mettre à jour et affiner régulièrement le LLM pour améliorer sa compréhension des entrées malveillantes et des cas limites.

2. Fuite de données

Il y a fuite de données lorsqu'un grand modèle de langage révèle accidentellement des informations sensibles, des algorithmes propriétaires ou d'autres détails confidentiels par le biais de ses réponses. « Cela peut entraîner un accès non autorisé à des données sensibles ou à la propriété intellectuelle, des violations de la vie privée et d'autres atteintes à la sécurité », poursuit l'OWASP.

Un filtrage incomplet ou incorrect des informations sensibles dans les réponses du LLM, la configuration/mémorisation des données sensibles dans le processus de formation du modèle et la divulgation involontaire d'informations confidentielles en raison d'une mauvaise interprétation ou d'erreurs du LLM sont des vulnérabilités courantes en matière de fuite de données. Un attaquant pourrait délibérément interroger le modèle à l'aide d'invites soigneusement conçues, en essayant d'extraire des informations sensibles que le LLM a mémorisées à partir de ses données d'entraînement, ou un utilisateur légitime pourrait par inadvertance poser au modèle une question qui révèle des informations sensibles/confidentielles. Les mesures préventives contre les fuites de données sont les suivantes :

- Mettre en œuvre un filtrage strict des données de sortie et des mécanismes contextuels pour empêcher le LLM de révéler des informations sensibles ;
- Utiliser des techniques de confidentialité différentielle ou d'autres méthodes d'anonymisation des données pendant le processus de formation du LLM afin de réduire le risque d'adaptation excessive ou de mémorisation ;
- Auditer et examiner régulièrement les réponses du LLM pour s'assurer que des informations sensibles ne sont pas divulguées par inadvertance.

3. Un bac à sable inadéquat

Si un LLM n'est pas correctement isolé lorsqu'il a accès à des ressources externes ou à des systèmes sensibles, un sandboxing inadéquat peut conduire à une exploitation potentielle, à un accès non autorisé ou à des actions involontaires de la part du modèle. Une séparation insuffisante entre l'environnement LLM et d'autres systèmes ou magasins de données critiques, des restrictions inappropriées permettant au modèle d'accéder à des ressources sensibles, et des LLM effectuant des actions au niveau du système/interagissant avec d'autres processus sont des vulnérabilités courantes d'un sandboxing LLM inadéquat, selon l'OSWAP.

Un exemple d'attaque serait un acteur malveillant qui exploiterait l'accès d'un LLM à une base de données sensible en créant des invites qui demanderaient au système d'extraire et de révéler des informations confidentielles. Les mesures préventives sont les suivantes :

- Isoler l'environnement LLM des autres systèmes et ressources critiques ;
- Restreindre l'accès du LLM aux ressources sensibles et limiter ses capacités au minimum requis pour l'objectif visé ;
- Auditer et examiner régulièrement l'environnement du LLM et les contrôles d'accès pour s'assurer que l'isolement approprié est maintenu.

4. Exécution de code non autorisé

L'exécution de code non autorisé se produit lorsqu'un attaquant exploite un LLM pour exécuter un code malveillant, des commandes ou des actions sur le système sous-jacent par le biais d'invites en langage naturel. Les vulnérabilités les plus courantes sont les suivantes : entrée utilisateur non nettoyée ou restreinte qui permet aux attaquants de créer des invites qui déclenchent l'exécution d'un code non autorisé, restrictions insuffisantes sur les capacités du grand modèle de langage et exposition involontaire de fonctionnalités ou d'interfaces au niveau du système à l'IA.

L'OWASP a cité deux exemples d'attaques : un attaquant élaborant une invite qui demande au LLM d'exécuter une commande qui lance un shell inversé sur le système sous-jacent, accordant à l'attaquant un accès non autorisé, et le LLM étant involontairement autorisé à interagir avec une API au niveau du système, qu'un attaquant manipule pour exécuter des actions non autorisées sur le système. Les équipes peuvent contribuer à empêcher l'exécution de code non autorisé grâce à ces actions :

- Mettre en œuvre des processus stricts de validation et d'assainissement des entrées pour empêcher que des invites malveillantes ou inattendues ne soient traitées par le LLM ;
- Assurer un sandboxing approprié et restreindre les capacités du LLM pour limiter sa capacité à interagir avec le système sous-jacent.

5. Vulnérabilités liées à la falsification des requêtes serveur

Les vulnérabilités liées à la falsification des requêtes côté serveur (SSRF) se produisent lorsqu'un attaquant exploite un LLM pour effectuer des requêtes involontaires ou accéder à des ressources restreintes telles que des services internes, des API ou des magasins de données. La validation insuffisante des entrées, qui permet aux attaquants de manipuler les invites du LLM pour lancer des requêtes non autorisées, et les mauvaises configurations des paramètres de sécurité du réseau ou de l'application, qui exposent les ressources internes au LLM, sont des vulnérabilités SSRF courantes, a déclaré l'OWASP. Pour exécuter une attaque, un cyberpirate pourrait créer une invite qui ordonne au LLM de faire une demande à un service interne, en contournant les contrôles d'accès et en obtenant un accès non autorisé à des informations sensibles. Il peut également exploiter une mauvaise configuration des paramètres de sécurité de l'application qui permet au LLM d'interagir avec une API restreinte, accédant ainsi à des données sensibles ou les modifiant. Les mesures préventives sont les suivantes :

- Mettre en œuvre une validation et un nettoyage rigoureux des entrées afin d'empêcher les invites malveillantes ou inattendues d'initier des requêtes non autorisées ;
- Vérifier et examiner régulièrement les paramètres de sécurité du réseau et des applications afin de s'assurer que les ressources internes ne sont pas exposées par inadvertance au LLM.

6. Dépendance excessive à l'égard du contenu LLM généré

Selon l'OSAWP, une confiance excessive dans le contenu généré par les LLM peut conduire à la propagation d'informations trompeuses ou incorrectes, à une diminution de l'apport humain dans la prise de décision et à une réduction de la pensée critique. Et de prévenir : « les entreprises et les utilisateurs peuvent faire confiance au contenu généré par les MFR sans vérification, ce qui entraîne des erreurs, des communications erronées ou des conséquences inattendues. Les problèmes courants liés à une confiance excessive dans le contenu généré par le LLM comprennent l'acceptation du contenu généré par le LLM comme un fait sans vérification, la supposition que le contenu généré par le LLM est exempt de parti pris ou de désinformation, et le fait de s'appuyer sur le contenu généré par le LLM pour des décisions critiques sans intervention humaine ou supervision ».

Par exemple, si une entreprise se fie à un LLM pour générer des rapports et des analyses de sécurité et que le LLM génère un rapport contenant des données incorrectes que l'entreprise utilise pour prendre des décisions critiques en matière de sécurité, il pourrait y avoir des répercussions importantes en raison de la confiance accordée au contenu inexact généré par le LLM. Rik Turner, analyste principal en cybersécurité chez Omdia, parle d'hallucinations du LLM : « Si le contenu revient en disant des bêtises et que l'analyste peut facilement l'identifier comme tel, il ou elle peut l'annuler et aider l'algorithme à se perfectionner. Mais que se passe-t-il si l'hallucination est très plausible et ressemble à la réalité ? En d'autres termes, le LLM pourrait-il en fait renforcer la crédibilité d'un faux positif, avec des conséquences potentiellement désastreuses si l'analyste se lance dans la mise hors service d'un système ou bloque le compte d'un client fortuné pendant plusieurs heures ? ».

7. Alignement inadéquat de l'IA

L'alignement inadéquat de l'IA se produit lorsque les objectifs et le comportement du LLM ne sont pas alignés sur le cas d'utilisation prévu, ce qui entraîne des conséquences indésirables ou des vulnérabilités. Selon l'OWASP, les problèmes les plus fréquents sont les suivants : objectifs mal définis qui conduisent le LLM à donner la priorité à des comportements indésirables ou nuisibles, fonctions de récompense ou données d'entraînement mal alignées qui entraînent un comportement involontaire du modèle, insuffisance des tests et de la validation du comportement du LLM. Si un LLM conçu pour aider aux tâches d'administration du système est mal aligné, il pourrait exécuter des commandes nuisibles ou donner la priorité à des actions qui dégradent les performances ou la sécurité du système. Les équipes peuvent prévenir les vulnérabilités liées à un alignement inadéquat de l'IA en prenant les mesures suivantes :

- Définir les objectifs et le comportement prévu du LLM au cours du processus de conception et de développement ;
- Veiller à ce que les fonctions de récompense et les données d'entraînement soient alignées sur les résultats souhaités et n'encouragent pas un comportement indésirable ou nuisible ;
- Tester et valider régulièrement le comportement du LLM dans un large éventail de scénarios, d'entrées et de contextes afin d'identifier et de résoudre les problèmes d'alignement.

8. Contrôles d'accès insuffisants

Des contrôles d'accès insuffisants se produisent lorsque les contrôles d'accès ou les mécanismes d'authentification ne sont pas correctement mis en œuvre, ce qui permet à des utilisateurs non autorisés d'interagir avec le LLM et d'exploiter potentiellement les vulnérabilités. D'après l'OWASP, le fait de ne pas appliquer des exigences strictes en matière d'authentification pour accéder au LLM, une mise en œuvre inadéquate du contrôle d'accès basé sur les rôles (RBAC) permettant aux utilisateurs d'effectuer des actions au-delà de leurs autorisations prévues, et le fait de ne pas fournir de contrôles d'accès appropriés pour le contenu et les actions générés par le LLM sont autant d'exemples courants.

Un exemple d'attaque est celui d'un acteur malveillant qui obtient un accès non autorisé à un LLM en raison de la faiblesse des mécanismes d'authentification, ce qui lui permet d'exploiter les vulnérabilités ou de manipuler le système, explique l'organisme. Les mesures préventives sont les suivantes :

- Mettre en œuvre des mécanismes d'authentification forte, tels que l'authentification multifactorielle (MFA), pour s'assurer que seuls les utilisateurs autorisés peuvent accéder au LLM ;
- Mettre en œuvre des contrôles d'accès appropriés pour le contenu et les actions générés par le LLM afin d'empêcher tout accès ou manipulation non autorisé.

9. Traitement inapproprié des erreurs

Il y a mauvaise gestion des erreurs lorsque les messages d'erreur ou les informations de débogage sont exposés d'une manière qui pourrait révéler des informations sensibles, des détails du système ou des vecteurs d'attaque potentiels à un acteur de la menace. Les vulnérabilités les plus courantes en matière de gestion des erreurs comprennent l'exposition d'informations sensibles ou de détails du système par le biais de messages d'erreur, la fuite d'informations de débogage qui pourraient aider un pirate à identifier des vulnérabilités ou des vecteurs d'attaque potentiels, et le fait de ne pas gérer les erreurs de manière gracieuse, ce qui peut entraîner un comportement inattendu ou des pannes du système.

Par exemple, un attaquant pourrait exploiter les messages d'erreur d'un LLM pour recueillir des informations sensibles ou des détails du système, ce qui lui permettrait de lancer une attaque ciblée ou d'exploiter des vulnérabilités connues. Par ailleurs, un développeur pourrait accidentellement laisser des informations de débogage exposées dans la production, ce qui permettrait à un attaquant d'identifier des vecteurs d'attaque potentiels ou des vulnérabilités dans le système, signale l'OWASP. Ces risques peuvent être atténués par les actions suivantes :

- Mettre en œuvre des mécanismes de gestion des erreurs appropriés pour s'assurer que les erreurs sont détectées, enregistrées et traitées ;
- Veiller à ce que les messages d'erreur et les informations de débogage ne révèlent pas d'informations sensibles ou de détails du système ;
- Envisager d'utiliser des messages d'erreur génériques pour les utilisateurs, tout en consignant des informations d'erreur détaillées pour les développeurs et les administrateurs.

10. Empoisonnement des données d'entraînement

L'empoisonnement des données d'entraînement se produit lorsqu'un attaquant manipule les données d'entraînement ou les procédures de réglage fin d'un LLM pour introduire des vulnérabilités, des portes dérobées ou des biais qui pourraient compromettre la sécurité, l'efficacité ou le comportement éthique du modèle, a écrit l'OWASP. Les problèmes courants d'empoisonnement des données d'entraînement comprennent l'introduction de portes dérobées ou de vulnérabilités dans le LLM par le biais de données d'entraînement manipulées de manière malveillante et l'injection de biais dans le LLM l'amenant à produire des réponses biaisées ou inappropriées. Les actions suivantes peuvent aider à prévenir ce risque :

- Garantir l'intégrité des données d'entraînement en les obtenant auprès de sources fiables et en validant leur qualité ;
- Mettre en œuvre des techniques robustes d'assainissement et de prétraitement des données pour éliminer les vulnérabilités ou les biais potentiels des données d'apprentissage ;
- Utiliser des mécanismes de surveillance et d'alerte pour détecter un comportement inhabituel ou des problèmes de performance dans le LLM, indiquant potentiellement un empoisonnement des données de formation.

Une responsabilité à assumer

Les responsables de la sécurité et les entreprises sont responsables de l'utilisation sécurisée des LLM
Les experts s'accordent à dire que ces derniers sont responsables des interfaces de chat d'IA générative qui s'appuient sur des LLM. « Les équipes de sécurité et les équipes juridiques devraient collaborer pour trouver la meilleure voie à suivre pour leurs organisations afin d'exploiter les capacités de ces technologies sans compromettre la propriété intellectuelle ou la sécurité », a récemment déclaré Chaim Mazal, RSSI de Gigamon.

Les chatbots alimentés par l'IA ont besoin de mises à jour régulières pour rester efficaces contre les menaces et la supervision humaine est essentielle pour garantir le bon fonctionnement des LLM, a ajouté de son côté  Joshua Kaiser, responsable IA et CEO de Tovie AI. « En outre, les LLM ont besoin d'une compréhension contextuelle pour fournir des réponses précises et détecter tout problème de sécurité, et doivent être testés et évalués régulièrement pour identifier les faiblesses ou les vulnérabilités potentielles ».