Attaques sur les Large Language Models (LLM) : comprendre les nouveaux enjeux de la cybersécurité

Avec l’essor des LLM comme GPT-3, GPT-4 et d’autres, l’intelligence artificielle a fait des avancées majeures, transformant de nombreux secteurs et usages. Toutefois, l’intégration croissante de ces modèles dans les applications quotidiennes s’accompagne de nouveaux enjeux, notamment de cybersécurité. Les LLM sont de plus en plus la cible d’attaques sophistiquées qui exploitent leurs vulnérabilités inhérentes. Dans cette série d’articles, nous explorerons en détail douze principales typologies d’attaques identifiées contre les LLM (dont le Top 10 OWASP). Ces attaques, allant des manipulations subtiles des réponses aux fuites d’informations sensibles, représentent des vulnérabilités majeures pour les organisations qui dépendent ou utilisent ces technologies.

Identifier et comprendre les attaques sur les LLM (Top 10 OWASP et plus) pour mieux les protéger

Se prémunir des usages malveillants des LLM

Les LLM, bien qu’incroyablement puissants, sont loin d’être infaillibles. En plus d’être neuves, leurs architectures complexes et leur capacité à apprendre de grandes quantités de données exposent ces modèles à une variété de menaces nouvelles, souvent mal comprises ou sous-estimées. Parmi les attaques les plus préoccupantes, on trouve les injections de prompt, l’extraction de données confidentielles, ou encore les attaques adversariales qui visent à altérer le comportement des modèles pour en tirer un avantage malveillant.

Maîtriser les 12 typologies d’attaques sur les LLM

Chaque type d’attaque présente ses propres mécanismes et conséquences, et il est crucial pour les professionnels de la cybersécurité de bien les comprendre pour développer des stratégies de défense efficaces. Dans les articles à venir, nous plongerons dans chacune de ces attaques pour examiner comment elles fonctionnent, pourquoi elles sont possibles et comment les atténuer.

Parmi les typologies que nous aborderons, citons :

• Injection de prompt : manipulation des instructions pour fausser les résultats.
• Divulgation d’informations sensibles : récupération d’informations confidentielles stockées dans le modèle.
• Empoisonnement des données : corruption des données pour altérer le comportement du modèle.
• Chaine d’approvisionnement : perturbation du modèle via des inputs spécialement conçus.

…et bien d’autres.

Ces douze types d’attaques comprennent celles du Top 10 de l’OWASP (avec la nomenclature “LLM ##”) ainsi que 2 autres qui, selon nous, sont suffisamment importantes pour les ajouter à ce Top 10 et créer un « Top 12 ».

Développer une compréhension exhaustive des attaques sur les LLM (Top 10 OWASP)

Face à la menace qui pèse sur les LLM I-TRACING a développé son propre framework d’audit spécialisé, pour ainsi auditer et évaluer la couverture sécurité des applications LLMs. Sur la base de notre expertise et de notre expérience éprouvée sur la sécurité des IA, notre objectif est de vous apporter une compréhension claire et accessible de chaque attaque, tout en proposant des recommandations pratiques pour renforcer la sécurité des LLM. Que vous soyez un professionnel de la cybersécurité, un développeur travaillant avec l’IA, ou simplement un passionné de technologie, cette série vous offrira un aperçu essentiel des défis à relever face à ces nouvelles menaces.

Restez avec nous pour explorer en profondeur chaque typologie d’attaque et découvrir comment protéger vos modèles de langage des dangers qui se cachent derrière ces puissants outils.

Le Top 10 OWASP des cyberattaques sur les LLM

OWASP LLM01 : Injection de prompt

L’injection de prompt consiste à manipuler les entrées du modèle pour le faire exécuter des actions non prévues par le développeur. On distingue l’injection directe et l’injection indirecte de prompt. Cette attaque constitue le principal vecteur pour exploiter les différentes vulnérabilités présentes dans les LLM.

Cela peut permettre la compromission du système par exécution de commandes non autorisées, la fuite et/ou l’exfiltration de données sensibles, l’utilisation du modèle pour des actions malveillantes sans détection ou encore la manipulation des sorties de l’IA pour tromper les utilisateurs ou compromettre d’autres systèmes. Ces différentes techniques sont utilisées pour tester une grande partie des autres attaques citées ci-dessous.

Conséquences d’une attaque sur les LLM par injection de prompt :

• Exfiltration de données
• Exécution de code non autorisé
• Contournement des mécanismes de sécurité
• Manipulation des résultats du modèle.

Remédiation à une attaque sur les LLM par injection de prompt :

• Implémenter des contrôles d’accès stricts pour les fonctionnalités backend
• Ajouter une validation humaine pour les opérations critiques
• Séparer le contenu externe des prompts utilisateurs
• Établir des limites de confiance entre le LLM, les sources externes et les fonctionnalités extensibles

---

💡Bon à savoir : la différence entre l’injection directe et indirecte de prompt

Injection directe de prompt

Un attaquant soumet directement des instructions malveillantes dans le prompt de l’IA, contournant les sécurités mises en place. Par exemple, en ajoutant des commandes spécifiques qui modifient le comportement de l’IA ou extraient des données sensibles. Cette technique est possible dès lors qu’il y a une interface dans l’application où l’utilisateur peut entrer une requête transmise au LLM ou lorsque la requête envoyée par l’application au LLM peut être interceptée et altérée.

Injection indirecte de prompt

Cette attaque se fait par des sources externes comme des fichiers ou des sites web. L’attaquant intègre des instructions malveillantes dans ces sources, qui sont ensuite traitées par l’IA. Ces instructions sont souvent invisibles pour l’œil humain mais lisible par le LLM (une police de couleur blanche sur une fond blanc par exemple).

---

💡Bon à savoir : la différence entre l’injection de prompt et le jailbreak

Les attaques de prompt injection et jailbreak sont souvent confondues entre elles ou considérées comme similaires, mais la différence entre les deux est notable.

Le jailbreak est une classe d’attaques qui vise à contourner les filtres de sécurité et les limitations éthiques ou politiques imposées au modèle par ses développeurs. Ces restrictions sont souvent mises en place pour empêcher les LLM de générer des contenus inappropriés, illégaux ou contraires aux politiques d’utilisation (par exemple, contenus haineux, explicites ou dangereux).

Les prompt injections exploitent la concaténation ou la composition de prompts entre des instructions de confiance (celles définies par les développeurs) et des entrées non fiables (généralement fournies par l’utilisateur). Le modèle LLM est manipulé pour interpréter des instructions inattendues ou non voulues en modifiant ou en injectant du texte dans le prompt initial.

La différence est donc que pour le prompt injection l’attaquant manipule le flux d’entrée, en jouant avec le prompt lui-même pour faire exécuter au modèle des actions qui n’étaient pas prévues, souvent dans le cadre de l’application en amont ; tandis que pour le jailbreak l’attaquant vise à bypasser les restrictions imposées au modèle directement, en le poussant à enfreindre ses politiques d’usage éthique ou de sécurité.

Dans le cadre d’un audit de sécurité généralement le jailbreak n’est pas considéré comme une vulnérabilité. Il peut l’être dans le cadre d’un audit touchant aussi l’alignement du modèle, ou si l’application est destinée à un public où le jailbreak serait néfaste ou dangereux (scolaire, légal…).

OWASP LLM02 : Traitement non sécurisé des sorties

L’absence de vérification et de filtrage des sorties générées par le modèle avant leur utilisation ou affichage peut exposer le système à des informations incorrectes ou dangereuses. Cette négligence rend également le système vulnérable aux attaques par insertion de scripts ou de commandes malveillantes dans les réponses de l’IA, compromettant ainsi la sécurité et l’intégrité des données traitées. Dans le cas de l’interprétation de la sortie du LLM par un navigateur ou un serveur,  il peut parfois en résulter une faille XSS ou une RCE

Conséquences d’un traitement non sécurisé des sorties des LLM :

• Exposition à des informations incorrectes ou dangereuses.
• Vulnérabilité aux attaques par insertion de scripts ou de commandes dans les réponses de l’IA
• Exposition à de l’exécution de code à distance

Remédiation à un traitement non sécurisé des sorties des LLM :

• Traiter le modèle comme un utilisateur non fiable et appliquer une validation appropriée
• Suivre les directives OWASP pour la validation et l’assainissement des entrées
• Encoder les sorties du modèle pour atténuer l’exécution de code indésirable

OWASP LLM03 : Empoisonnement des données

La manipulation des données de pré-entraînement des LLM ou des données impliquées dans les processus de fine-tuning ou d’intégration des LLM a pour objectif d’introduire des vulnérabilités, des portes dérobées ou des biais.

Conséquences d’une attaque sur les LLM par empoisonnement des données :

• Compromission de la sécurité, de l’efficacité ou du comportement éthique du modèle
• Génération de résultats biaisés ou malveillants
• Dégradation des performances

Remédiation à une attaque sur les LLM par empoisonnement des données :

• Vérifier rigoureusement les sources de données d’entraînement
• Implémenter des techniques de détection d’anomalies et de robustesse adverse
• Utiliser des pipelines MLOps sécurisés pour le suivi des données, des modèles et de l’utilisation

OWASP LLM04 : Déni de service

Il est possible d’exploiter des ressources du système d’IA des LLM pour le surcharger et provoquer un déni de service. Dans le cas d’utilisation d’un outil d’IA tiers, cela peut aussi impacter le coût de cet outil.

Conséquences d’une attaque par déni de service sur les LLM :

• Indisponibilité du service pour les utilisateurs légitimes.
• Potentielles pertes financières et de réputation
• Dégradation des performances

Remédiation à une attaque par déni de service sur les LLM :

• Implémenter des limites de taux (nombre de requêtes par user/IP par exemple, …) et de ressources (réservation de traitement par requête)
• Utiliser des techniques de détection d’anomalies pour identifier les attaques
• Mettre en place une surveillance continue des performances du modèle

OWASP LLM05 : Vulnérabilités de la chaîne d’approvisionnement

Les attaquants peuvent tirer profit de composants ou services vulnérables pour compromettre le cycle de vie de l’application LLM.

Conséquences de vulnérabilités sur la chaine d’approvisionnement des applications LLM :

• Introduction de vulnérabilités dans l’application
• Accès non autorisé aux systèmes
• Compromission de l’intégrité du modèle

Remédiation pour préserver les applications LLM d’attaque de la chaine d’approvisionnement:

• Maintenir un inventaire à jour des composants avec un SBOM (Software Bill of Materials)
• Effectuer des analyses de vulnérabilités régulières
• Implémenter une politique de correctifs pour les composants vulnérables ou obsolètes

OWASP LLM06 : Divulgation d’informations sensibles

Un attaquant peut exploiter des fonctionnalités de l’IA pour extraire des données sensibles traitées par le modèle et entraîner la fuite de données confidentielles ou personnelles. Il peut ainsi récupérer des données présentes dans le jeu de données d’entraînements, dans les RAGs (sources de connaissances externes) ainsi que des données utilisateur.

Conséquences d’une attaque sur les LLM par divulgation d’informations sensibles :

• Fuite de données confidentielles ou personnelles.
• Atteinte à la réputation et potentielles sanctions légales​
• Perte de la propriété intellectuelle

Remédiation à une attaque sur les LLM par divulgation d’informations sensibles :

• Mettre en œuvre des techniques adéquates d’assainissement et de nettoyage des données
• Appliquer un contrôle d’accès strict aux sources de données externes
• Limiter l’accès du modèle aux données sensibles
• Implémenter la DP pour les données confidentielles

OWASP LLM07 : Conception de plugin non sécurisé           

La présence de vulnérabilités dans la conception des plugins LLM, notamment des entrées non sécurisées et un contrôle d’accès insuffisant, les rendent plus faciles à exploiter.

Conséquences de plugins LLM non sécurisés :

• Exécution de code à distance
• Accès non autorisé à des fonctionnalités
• Manipulation des résultats du modèle

Remédiation aux plugins LLM non sécurisés :

• Appliquer une validation et un assainissement stricts des entrées
• Concevoir les plugins de sorte à minimiser l’impact de l’exploitation des paramètres d’entrées non sécurisés
• Utiliser une authentification et une autorisation appropriées pour les plugins

OWASP LLM08 : Permissivité excessive

Lors de l’interconnexion entre le LLM et les autres systèmes de l’application, l’octroi de permissions et d’autonomie excessives à l’IA peut lui permettre d’exécuter des actions potentiellement dommageables.

Conséquences d’une permissivité excessive dans un LLM :

• Exécution d’actions non souhaitées ou dangereuses.
• Risque de compromission de systèmes interconnectés​

Remédiation à la permissivité excessive dans un LLM :

• Limiter les plugins/outils que les agents LLM sont autorisés à appeler
• Restreindre les fonctions implémentées dans les plugins/outils LLM au minimum nécessaire
• Utiliser un contrôle humain pour approuver les actions critiques

OWASP LLM09 : Surdépendance pour prise de décision

La confiance excessive en l’IA pour des décisions critiques sans supervision humaine suffisante peut conduire à des décisions erronées ou dangereuses fondées sur des sorties incorrectes ou inappropriées de l’IA. Cette confiance excessive réduit la capacité de contrôle et d’intervention humaine en cas de défaillance, augmentant les risques pour la sécurité et l’efficacité des opérations. Cela se produit notamment lorsque l’IA doit analyser des documents non vérifiés au préalable.

Conséquences d’une surdépendance à l’IA pour la prise de décision :

• Prise de décisions erronées ou dangereuses fondées sur des sorties incorrectes de l’IA.
• Réduction de la capacité de contrôle et d’intervention humaine en cas de défaillance
• Vulnérabilités de sécurité dues à un contenu incorrect ou inapproprié généré par les LLM

Remédiation à une surdépendance à l’IA pour la prise de décision :

• Mettre en place des mécanismes de validation continue des sorties du LLM
• Recouper les informations générées par le LLM avec des sources externes fiables
• Communiquer clairement les risques et les limites associés à l’utilisation des LLM

OWASP LLM10 : Vol du modèle

L’extraction des paramètres et des poids du modèle d’IA, généralement par des attaques ciblées, peut entraîner une perte de propriété intellectuelle. Cela permet aux attaquants de reproduire le modèle ou d’identifier des vulnérabilités, compromettant ainsi la sécurité de ce dernier. En effet, la mise au point de ces techniques avancées sur les modèles d’IA nécessite normalement d’avoir la connaissance totale du modèle, mais elles peuvent aussi être développées sur une copie du modèle et transférées sur l’original. 

Conséquences d’un vol de model du LLM :

• Perte de propriété intellectuelle et d’avantage concurrentiel.
• Possibilité pour les attaquants de reproduire le modèle ou d’identifier des vulnérabilités
• Accès potentiel à des informations sensibles contenues dans le modèle

Remédiation à la possibilité de vol de modèle du LLM:

• Mettre en œuvre des contrôles d’accès fort et des mécanismes d’authentification robustes
• Surveiller et auditer régulièrement les accès aux dépôts de modèles LLM
• Implémenter des techniques de tatouage numérique pour les modèles

Les autres types de cyberattaques possibles sur les applications LLM

LLM11 : Extraction du pré-prompt

L’attaquant tente d’extraire le pré-prompt (i.e. instructions et les contextes initiaux, souvent cachés, du modèle) ajouté par l’organisation pour améliorer la réponse du modèle grâce à des techniques d’injection de prompt.

Conséquences de l‘extraction du pré-prompt:

• Divulgation de la logique interne et des instructions de sécurité du modèle
• Utilisation de ces informations pour affiner d’autres attaques​

Remédiation à l’extraction du pré-prompt:

• Concevoir un pré-prompt ne contenant que des informations strictement nécessaires
• Entrainer le modèle contre les attaques adverses

LLM12 : Hallucination

Les hallucinations dans les modèles de langage (LLM) font référence à la génération de contenus incorrects ou non fondés par le modèle, souvent sous la forme de faits inventés, de citations erronées, ou d’incohérences logiques. Ces hallucinations peuvent survenir même lorsque le modèle est interrogé sur des sujets pour lesquels il est supposé avoir des données fiables. Elles sont particulièrement dangereuses dans des contextes où la précision et la fiabilité des informations sont cruciales, telles que les domaines médicaux, juridiques, ou financiers. De plus, ces hallucinations peuvent être exploitées par des attaquants pour induire en erreur les utilisateurs ou manipuler les décisions prises sur la base des informations générées par le LLM.

Conséquences des hallucinations du LLM :

• Diffusion d’informations incorrectes ou trompeuses, pouvant nuire à la crédibilité et à la confiance en l’application.
• Risques accrus de prises de décisions erronées basées sur des données incorrectes générées par le LLM.
• Possibilité pour des acteurs malveillants d’exploiter ces hallucinations pour influencer ou manipuler les utilisateurs.
• Impact potentiel sur la sécurité, en particulier si des actions sont prises en réponse à des informations incorrectes fournies par le modèle (cf. OWASP LLM09).

Remédiation aux hallucinations du LLM :

• Validation croisée des informations générées : mettre en place des mécanismes de vérification ou de validation humaine pour les informations critiques produites par le LLM.
• Renforcement des données d’entraînement : utiliser des jeux de données plus complets et représentatifs pour minimiser les risques d’hallucinations, en particulier dans les domaines sensibles.
• Mise en œuvre de modèles de détection des incohérences : déployer des modèles auxiliaires ou des systèmes de surveillance pour détecter et signaler les incohérences logiques ou factuelles dans les réponses du LLM.
• Transparence et éducation des utilisateurs : informer les utilisateurs des potentiels risques liés aux hallucinations et leur fournir des outils ou des processus pour vérifier la véracité des informations fournies.
• Limitations d’accès contextuel : restreindre les domaines d’application du LLM à ceux où il est démontré qu’il fournit des réponses fiables, ou ajouter des garde-fous lorsqu’il est utilisé dans des contextes critiques.

Conclusion

La sécurité des Large Language Models (LLM) est un enjeu majeur à l’avènement de l’IA générative. Face aux 12 typologies d’attaques identifiées, il est essentiel pour les organisations de comprendre et d’anticiper ces menaces pour protéger efficacement leurs applications LLM. I-TRACING ayant développé son framework d’audit spécialisé, offre des services d’audit et d’analyse pour évaluer la couverture sécurité des applications en se basant sur ce référentiel.

References

• OWASP Top 10 for Large Language Model Applications : https://owasp.org/www-project-top-10-for-large-language-model-applications/
• Checklist https://owasp.org/www-project-top-10-for-large-language-model-applications/llm-top-10-governance-doc/LLM_AI_Security_and_Governance_Checklist-v1.1.pdf
• ANSSI. Recommandations de sécurité pour un système d’IA générative. https://cyber.gouv.fr/publications/recommandations-de-securite-pour-un-systeme-dia-generative
• Matrice ATLAS https://atlas.mitre.org/matrices/ATLAS
• Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. NIST. January 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2023.pdfdf
• MIT https://airisk.mit.edu/ 

Auteur

Gustave Julien, Auditeur Sécurité

14 novembre 2024