Sécuriser le grand modèle de langage avant la prochaine faille par injection de requêtes

Le mois dernier, j'ai examiné un rapport d'expertise judiciaire où une société de services financiers avait perdu le contrôle d'un robot de service client interne. L'entreprise disposait d'une infrastructure de sécurité de pointe, pourtant une seule phrase habilement formulée dans un ticket d'assistance a contourné tous les garde-fous. C'est le paradoxe architectural de l'IA moderne. Nous enveloppons ces modèles dans des couches de sécurité traditionnelle, mais nous ne parvenons pas à traiter la vulnérabilité centrale : le modèle est incapable de séparer les données non fiables des instructions de confiance. CrowdStrike a récemment codifié ce problème en cinq nouveaux vecteurs d'attaque distincts que tout architecte de sécurité doit comprendre.

J'ai passé la matinée d'hier dans mon laboratoire à essayer de reproduire l'une de ces techniques sur une version localisée de Llama 3. La simplicité de l'exploit est ce qui le rend dangereux. Du point de vue du risque, nous sommes actuellement dans le Far West de l'IA générative. Les cinq nouvelles menaces d'injection de requêtes (prompt injection) identifiées par CrowdStrike démontrent que les attaquants vont au-delà des simples commandes « ignorez toutes les instructions précédentes ». Ils utilisent désormais la manipulation linguistique et la distribution en plusieurs étapes pour compromettre les systèmes.

L'effondrement de la frontière entre données et instructions

L'injection de requêtes existe en raison de la manière dont les grands modèles de langage traitent l'information. Dans les logiciels traditionnels, le code et les données sont généralement conservés dans des espaces mémoire séparés. Une base de données SQL n'exécute pas accidentellement le nom de famille d'un utilisateur comme une commande, à moins qu'il n'y ait une vulnérabilité spécifique comme l'injection SQL. Dans un LLM, les instructions du développeur et les données de l'utilisateur se trouvent dans la même fenêtre de contexte. Le modèle traite chaque jeton (token) avec un poids similaire.

Ce manque de séparation rend le périmètre réseau aussi obsolète qu'un fossé de château. Si vous autorisez un LLM à lire un e-mail, vous donnez essentiellement à cet e-mail un siège au clavier. Les attaquants exploitent cette conception en intégrant des instructions au sein de données que le modèle finit par traiter comme une directive. La nouvelle taxonomie de CrowdStrike fournit une carte de la manière dont ces attaquants font évoluer leurs méthodes pour garder une longueur d'avance sur le filtrage de mots-clés basique.

Menaces dormantes via des règles activées par déclencheur

La première nouvelle technique est l'ajout de règles activées par déclencheur. Dans ce scénario, un attaquant n'essaie pas de briser le modèle immédiatement. Au lieu de cela, il introduit une nouvelle règle qui semble inoffensive. Par exemple, l'attaquant pourrait dire au modèle de toujours résumer le texte dans un format spécifique s'il voit le mot « bluebird ». En soi, ce n'est pas une violation. Cela ressemble à une personnalisation mineure.

Cependant, l'attaquant peut déclencher cette règle plus tard pour provoquer un comportement étrange ou malveillant. La règle agit comme un agent dormant. Une fois le déclencheur activé, le modèle pourrait rediriger sa sortie vers une API non autorisée ou commencer à divulguer des instructions système sensibles. Comme l'ajout initial de la règle est anodin, il passe à travers la plupart des systèmes de détection de base. La menace reste dormante jusqu'à ce que les conditions spécifiques soient remplies. L'évaluation de la surface d'attaque nécessite de rechercher ces instructions « si-alors » cachées dans les historiques de conversation à long terme ou les instructions système.

Briser le filtre par la suppression cognitive de jetons

La suppression cognitive de jetons est une approche plus technique pour contourner les mesures de sécurité. La plupart des LLM ont des modèles de refus intégrés. Si vous demandez à un modèle de vous aider à écrire un logiciel malveillant, il est entraîné pour dire quelque chose comme « Je ne peux pas répondre à cette demande ». Les équipes de sécurité s'appuient souvent sur ces modèles de refus établis pour maintenir la sécurité du modèle.

Un attaquant utilisant la suppression cognitive de jetons déplace les choix linguistiques du modèle hors de ces schémas. Il peut utiliser des contraintes complexes qui interdisent au modèle d'utiliser les mots « impossible », « refuse » ou « politique ». En dépouillant le modèle de sa capacité à dire non de sa manière habituelle, l'attaquant force le LLM dans un état où il est plus susceptible de répondre à une demande malveillante. C'est une forme de menottes linguistiques. Le modèle est forcé de trouver un chemin à travers la requête qui évite son entraînement de sécurité. Par conséquent, le filtre de sécurité échoue car le modèle n'a plus accès au vocabulaire dont il a besoin pour exprimer un refus.

Cacher la charge utile par décomposition algorithmique

La décomposition algorithmique de la charge utile est une attaque qui repose sur la capacité du modèle à assembler des idées complexes à partir de parties simples. Un attaquant livre un message en plusieurs étapes. Chaque étape est innocente lorsqu'elle est vue isolément. Une requête peut demander au modèle de stocker une chaîne de caractères spécifique. Une seconde requête peut lui demander de définir une certaine fonction.

Une fois combinés, ces morceaux s'assemblent en une seule commande menaçante. C'est le cheval de Troie numérique de l'injection de requêtes. Les outils de sécurité qui scannent les requêtes individuelles à la recherche d'intentions malveillantes ne verront rien de mal. La menace n'émerge qu'au niveau architectural lorsque le modèle intègre toutes les pièces. J'ai vu cela fonctionner efficacement dans des environnements où la fenêtre de contexte est assez large pour contenir plusieurs interactions apparemment sans rapport qui forment finalement une chaîne d'exploitation complète.

Le risque d'injection de jetons spéciaux

L'injection de jetons spéciaux est une technique qui cible les commutateurs de contrôle du LLM. Les modèles utilisent des jetons spéciaux pour marquer la fin d'une pensée ou le début d'une instruction système. Ces jetons sont comme les boutons sur le tableau de bord d'un pilote. Si un attaquant peut injecter ces jetons dans sa propre saisie, il peut tromper le modèle en lui faisant croire que le contenu de l'utilisateur est en réalité une directive système de haute priorité.

Cette attaque introduit une confusion qui incite le modèle à élever le contenu utilisateur non fiable. C'est un assaut direct contre la logique interne du modèle. En usurpant ces commutateurs de contrôle, l'attaquant acquiert la capacité d'écraser les instructions originales du développeur. Le modèle commence à traiter l'attaquant comme l'administrateur. Ceci est particulièrement dangereux pour les modèles connectés à des outils ou des bases de données externes. Une fois que le modèle croit que l'attaquant est une voix système de confiance, il exécutera des actions avec des privilèges élevés.

Tromper l'utilisateur avec l'injection de données de contexte

L'injection involontaire de données de contexte par l'utilisateur est peut-être la menace la plus répandue dans cette nouvelle liste. Cet exploit s'appuie sur la frontière entre les données de confiance et les instructions exécutables. L'utilisateur est celui qui introduit l'instruction malveillante, mais il le fait sans le savoir. Cela se produit lorsqu'un utilisateur télécharge un document, transfère un e-mail ou ajoute du contenu Web que l'IA traite ultérieurement.

En coulisses, l'instruction malveillante est cachée à l'intérieur du document ou de l'e-mail. La requête que l'utilisateur écrit peut être inoffensive, telle que « résumer ce PDF ». Le PDF lui-même contient une ligne de texte cachée qui dit au modèle d'ignorer le résumé et d'envoyer à la place le jeton de session de l'utilisateur à un serveur externe. L'utilisateur est le véhicule de livraison de l'attaque. En termes d'intégrité des données, c'est un cauchemar. Cela signifie que chaque information touchée par un LLM est un vecteur potentiel de compromission.

Construire une architecture de défense résiliente

Les équipes de sécurité peuvent se prémunir contre de telles attaques de plusieurs manières. De manière proactive, la première étape est la modélisation des menaces pour chaque endroit d'où le contexte du modèle peut provenir. Vous devez traiter chaque entrée comme un actif toxique. Cela inclut les fichiers téléchargés par les utilisateurs, les e-mails récupérés dans une boîte de réception et les données extraites des bases de données internes.

CrowdStrike recommande d'étendre les tests pour inclure ces cinq vecteurs spécifiques. Le « red teaming » devrait se concentrer sur les attaques composites plutôt que sur les échecs de requêtes uniques. Vous devez voir si votre modèle peut être trompé par la décomposition ou la suppression. Au-delà des correctifs, la véritable solution réside dans l'ingénierie de détection granulaire. Nous avons besoin de systèmes capables de surveiller l'état interne du modèle et d'alerter lorsqu'il commence à ignorer ses instructions de base.

Le « Zero Trust » doit être appliqué aux données circulant vers le LLM. Considérez cela comme un videur de club VIP à chaque porte interne. Ne faites jamais confiance aux données, même si elles proviennent d'un utilisateur connecté. Le videur doit vérifier que le contenu ne contient pas d'instructions cachées avant qu'il ne soit autorisé dans la fenêtre de contexte du modèle. C'est le seul moyen de construire un système résilient capable de résister à la prochaine génération d'injections de requêtes.

Du point de vue de l'expertise judiciaire, vous devriez également maintenir des journaux détaillés de la fenêtre de contexte complète pour chaque interaction. En cas de faille, ces journaux sont essentiels pour comprendre comment un attaquant a contourné vos filtres. Si vous ne consignez que le résultat final, il vous manque la partie la plus importante de la chaîne d'attaque.

Points clés à retenir pour les responsables de la sécurité

• Auditer les sources de contexte : Identifiez toutes les entrées de données qui atteignent vos LLM et traitez-les comme des instructions non fiables.
• Tester les contournements linguistiques : Utilisez le red teaming pour voir si votre modèle est vulnérable à la suppression cognitive de jetons ou à la décomposition algorithmique.
• Surveiller les jetons spéciaux : Implémentez des filtres qui détectent et suppriment les jetons de contrôle des données fournies par l'utilisateur.
• Éduquer les utilisateurs sur les risques de contexte : Informez les employés que le résumé de documents non fiables peut entraîner une compromission du système.
• Mettre en œuvre l'ingénierie de détection : Allez au-delà de la simple correspondance de mots-clés et commencez à rechercher des anomalies comportementales dans les réponses du modèle.

L'IA est un outil puissant, mais c'est aussi un nouveau type de surface d'attaque. En comprenant ces cinq nouvelles menaces, vous pouvez commencer à construire une défense aussi intelligente que les modèles que vous essayez de protéger.

Sources : CrowdStrike Falcon Intelligence, NIST AI Risk Management Framework, MITRE ATLAS.

Avertissement : Cet article est fourni à des fins d'information et d'éducation uniquement et ne remplace pas un audit professionnel de cybersécurité ou un service de réponse aux incidents.