PIDP-Attack: Combining Prompt Injection with Database Poisoning Attacks on Retrieval-Augmented Generation Systems

1. Problématique et Contexte

Les modèles de langage (LLM) souffrent souvent de connaissances obsolètes et d'hallucinations. Pour pallier ces défauts, les systèmes RAG (Retrieval-Augmented Generation) ont été développés, combinant un LLM à une base de connaissances externe pour générer des réponses factuelles et à jour.

Cependant, l'architecture RAG élargit la surface d'attaque. Les recherches précédentes ont identifié deux vecteurs d'attaque principaux, mais chacun présente des limites majeures :

• L'empoisonnement de données (Data Poisoning) : Des attaques comme PoisonedRAG injectent des passages malveillants dans la base de données. Leur limite est qu'elles nécessitent une connaissance préalable exacte de la requête de l'utilisateur pour créer un poison ciblé, ce qui les rend peu flexibles dans des scénarios réels où les requêtes sont dynamiques.
• L'injection de prompt (Prompt Injection) : Des attaques comme GGPP ou GCG manipulent la requête utilisateur pour détourner le modèle. Leur limite est qu'elles manquent souvent de persistance et de "preuves" contextuelles (les documents récupérés), ce qui réduit leur taux de réussite face à des modèles robustes.

Le problème central : Il n'existe pas encore d'attaque capable de manipuler la réponse d'un système RAG vers une réponse cible arbitraire sans connaître la requête de l'utilisateur à l'avance, tout en maintenant un taux de réussite élevé et une grande furtivité.

2. Méthodologie : PIDP-Attack

Les auteurs proposent PIDP-Attack (Prompt Injection and Database Poisoning Attack), une attaque composite novatrice qui combine les deux vecteurs précédents pour créer une synergie offensive.

A. Modèle de Menace

L'attaquant dispose de deux surfaces d'attaque orthogonales :

1. Manipulation du chemin de requête (Query-path) : L'attaquant peut ajouter un suffixe malveillant ($\delta$) à n'importe quelle requête utilisateur ($q$) au moment de l'inférence (via un proxy compromis, un plugin, etc.), sans connaître la requête originale.
2. Manipulation du chemin de corpus (Corpus-path) : L'attaquant peut insérer un petit nombre de passages empoisonnés ($n$) dans la base de connaissances de récupération.

B. Mécanisme d'Attaque

L'objectif est de forcer le système à répondre à une question cible spécifique ($S$) avec une réponse incorrecte choisie ($a^-$), quelle que soit la question réelle de la victime ($q$).

Le processus se déroule en deux phases :

1. Préparation Hors Ligne (Empoisonnement du Corpus) :

   • L'attaquant choisit une question cible $S$ et une réponse fausse $a^-$.
   • Il génère $n$ passages empoisonnés. Chaque passage commence par la question cible $S$ (pour maximiser la similarité sémantique lors de la récupération) suivi d'un corps de texte argumentant la fausse réponse $a^-$.
   • Ces passages sont injectés dans la base de données.

2. Attaque en Ligne (Injection de Requête) :

   • Pour toute requête utilisateur $q$, l'attaquant l'altère en $q' = q \oplus \delta(S)$, où $\delta(S)$ est un suffixe d'injection contenant la question cible $S$.
   • Double effet :
     • Récupération : Le suffixe $\delta(S)$ modifie l'embedding de la requête, orientant le récupérateur vers les passages empoisonnés liés à $S$, même si $q$ est sans rapport.
     • Génération : Le suffixe agit comme une instruction prioritaire pour le LLM, lui ordonnant de répondre à $S$ plutôt qu'à $q$, en s'appuyant sur les preuves (les passages empoisonnés) présentes dans le contexte récupéré.

3. Contributions Clés

1. Nouvelle Stratégie Composite : PIDP-Attack est la première attaque à combiner efficacement l'injection de prompt et l'empoisonnement de base de données pour contourner la nécessité de connaître la requête de la victime à l'avance.
2. Efficacité avec un Petit Budget : L'attaque ne nécessite l'insertion que d'un nombre très limité de passages empoisonnés ($n$), souvent égal à la valeur $k$ (le nombre de documents récupérés), pour manipuler n'importe quelle requête.
3. Évaluation Rigoureuse : Les auteurs ont testé leur méthode sur trois jeux de données de référence (Natural Questions, HotpotQA, MS-MARCO) et huit LLMs d'état de l'art, démontrant une supériorité constante par rapport aux attaques à vecteur unique.

4. Résultats Expérimentaux

Les expériences montrent que PIDP-Attack surpasse systématiquement les méthodes existantes (PoisonedRAG, GGPP, GCG, etc.) :

• Taux de Réussite d'Attaque (ASR) : PIDP-Attack atteint un ASR moyen de 98,125 % sur l'ensemble des modèles et des jeux de données.
• Amélioration par rapport à l'état de l'art : Sur les tâches de questions-réponses en domaine ouvert, la méthode améliore le taux de réussite de 4 % à 16 % par rapport à PoisonedRAG (l'attaque d'empoisonnement la plus performante précédemment).
• Robustesse :
  • Même avec un budget d'empoisonnement faible ($n=1$ à $5$), l'attaque atteint une saturation rapide sur des corpus comme Natural Questions et HotpotQA.
  • L'attaque reste efficace même lorsque le nombre de documents récupérés ($k$) varie, bien qu'une augmentation excessive de $k$ puisse diluer l'effet des passages empoisonnés dans certains cas (comme sur MS-MARCO).
• Analyse des Composantes : Les études d'ablation confirment que ni l'injection seule ni l'empoisonnement seul ne suffisent à garantir un taux de réussite élevé et fiable. C'est la combinaison des deux (manipulation de la récupération + hijacking de l'instruction) qui rend l'attaque si puissante.

5. Signification et Implications

• Vulnérabilité End-to-End : L'article démontre que la sécurité des systèmes RAG ne peut pas être assurée en sécurisant uniquement le modèle ou uniquement la base de données. La chaîne de traitement complète (de la requête à la récupération, puis à la génération) doit être protégée.
• Menace Réaliste : Contrairement aux attaques théoriques nécessitant un accès aux poids du modèle (white-box) ou une connaissance parfaite des requêtes futures, PIDP-Attack opère en boîte noire et est applicable dans des scénarios réels où les requêtes sont imprévisibles.
• Défense : Les auteurs suggèrent que les contre-mesures doivent inclure :
  • La validation de la provenance des passages récupérés.
  • Le nettoyage des suffixes de requêtes suspects.
  • La séparation stricte entre les instructions système et le contenu utilisateur/contextuel.
  • La surveillance des motifs d'injection dans les contextes récupérés.

En conclusion, PIDP-Attack révèle une faille critique dans l'architecture RAG actuelle : la confiance implicite accordée aux documents récupérés et la capacité des requêtes utilisateur à influencer la récupération peuvent être exploitées conjointement pour détourner complètement le comportement du système, même sans connaître la question de l'utilisateur.