Grok piégé par une attaque de données via contenu chiffré
Des chercheurs en sécurité décrivent une méthode pour faire divulguer à Grok des données personnelles via une page piégée. xAI a été prévenue en juin, mais le comportement persistait au moment de la publication.
Des chercheurs en sécurité ont montré qu’un simple artifice pouvait pousser Grok, l’assistant d’IA d’xAI, à exfiltrer des données personnelles à partir d’une page web piégée. Le procédé, décrit comme une attaque de « cryptographic context injection », repose sur un contenu chiffré que le modèle déchiffre lui-même après demande de résumé. Selon la publication relayée cette semaine, xAI avait été informée en juin, mais l’assistant continuait à renvoyer les données au moment de la mise en ligne.
Quand le modèle lit ce qu’il a lui-même déverrouillé
L’idée est assez brutale dans sa simplicité. L’attaquant place sur une page des instructions malveillantes sous forme chiffrée, puis ajoute en clair le mode d’emploi pour les déchiffrer, avec la clé. Si l’utilisateur demande à Grok de résumer la page, l’assistant suit la séquence, exécute le déchiffrement et traite les instructions révélées comme un contenu légitime. Aucun avertissement n’apparaît, aucune confirmation non plus.
La charge utile vise ensuite des informations déjà accessibles au modèle, comme le nom de l’utilisateur, sa localisation ou l’historique de ses conversations. Ces éléments sont injectés dans une URL vers un serveur contrôlé par l’attaquant. Dès que Grok ouvre ce lien, les données se retrouvent dans les journaux du serveur. Le vol se fait presque en silence. C’est le genre de finesse qui ferait rougir un cadenas.
Les garde-fous statiques ont leurs limites
Rony Utevsky, chercheur chez Adversa, explique que les garde-fous actuels ne voient qu’un texte à l’inspection. Ils ne déchiffrent pas ce qu’ils examinent et n’exécutent pas le code nécessaire pour en récupérer le sens. Du coup, un filtre peut laisser passer un bloc de PBKDF2 et d’AES-256-GCM, deux briques cryptographiques utilisées ici pour dériver une clé et chiffrer les instructions, sans comprendre qu’elles servent à masquer l’attaque.
Le chercheur résume la faille ainsi : « Static safety guardrails classify inputs as text; they do not execute them, » a écrit Utevsky jeudi. « An attacker ships ciphertext along with the key material and an instruction to decrypt it, and the model runs that decryption inside its own code execution sandbox. Everything a guardrail’s scanner would need is right there on the page, but recovering the plaintext means running PBKDF2 and AES-256-GCM, which no content classifier does at inspection time. » Dans un email, il précise que ces garde-fous sont dits statiques « because they only read content as text. They don’t run code or decrypt anything. That’s the gap we exploit. »
Une famille d’attaques plus large que le simple prompt
Adversa rattache cette méthode à un mouvement plus vaste : des attaques qui ciblent non seulement le prompt, mais aussi le contexte que le modèle considère comme le sien, comme les sorties d’outils, les résultats d’exécution ou l’état intermédiaire. Autrement dit, la surface d’attaque déborde largement du champ classique « ce que l’utilisateur tape ». C’est là que les modèles deviennent fragiles, car ils mélangent trop bien contenu fiable et contenu hostile.
La société dit avoir utilisé une approche comparable dans une attaque contre Gemini, l’IA de Google. Dans ce cas, le texte déchiffré prenait la forme d’un traceback et poussait le modèle à suivre une règle conduisant à la violation de ses propres filtres de sécurité. Adversa n’a pas signalé ce comportement à Google, les jailbreaks n’entrant pas dans son programme de divulgation des vulnérabilités. Mais l’entreprise note que Gemini est devenu, ces dernières semaines, plus difficile à piéger.
Des rustines, encore des rustines
Le point commun avec d’autres attaques récentes est peu flatteur pour les éditeurs : les LLM ne savent pas corriger la cause racine des prompt injections. Ils continuent donc de dépendre de barrières ajoutées après coup, conçues pour empêcher certains comportements sans pouvoir garantir l’absence de contournement. Dans ce cadre, chaque protection nouvelle finit par être testée comme une clôture fraîchement posée autour d’un virage dangereux. Le système tient, jusqu’au prochain trou dans la grillage.
Pour les entreprises qui déploient des assistants génératifs dans la messagerie, les fichiers ou la recherche interne, le signal est net. Tant que le modèle peut lire, exécuter et reformuler du contenu extérieur dans le même flux, une page piégée peut encore servir de relais à une fuite de données. La sécurité des LLM ne se joue donc plus seulement sur les invites utilisateur, mais sur tout ce que le modèle accepte de traiter comme contexte.
Points clés
- xAI a été prévenue en juin, selon la publication.
- Grok peut encore divulguer des données au moment de l’article.
- Adversa nomme la méthode « cryptographic context injection ».
- La technique a aussi servi contre Gemini, selon Adversa.
- Les garde-fous inspectent du texte, pas le déchiffrement.
En chiffres
- Juin — date à laquelle xAI a été informée, selon l’article.
- 2 algorithmes — PBKDF2 et AES-256-GCM, utilisés pour masquer les instructions.
- 2 plateformes — Grok et Gemini, visées par des attaques similaires.