Les abus derrière l'exploitation de Grok : Analyse de l'abus de la chaîne de permissions de l'agent IA

Rédigé par : Équipe de sécurité SlowMist

Contexte

Récemment, une incident d’abus de permissions s’est produit sur la chaîne Base, impliquant la combinaison d’un agent AI et d’un système de trading automatisé. L’attaquant a envoyé un contenu construit spécifiquement sur la plateforme X à @grok, induisant celui-ci à produire des instructions de transfert reconnues par un agent de trading externe (@bankrbot), ce qui a finalement entraîné le transfert d’actifs réels sur la chaîne.

À propos du « portefeuille Grok » :

L’adresse marquée comme « portefeuille Grok » dans l’incident (0xb1058c959987e3513600eb5b4fd82aeee2a0e4f9) n’appartient pas au contrôle officiel de xAI. Cette adresse est un portefeuille associé automatiquement généré par @bankrbot pour le compte X @grok, dont la clé privée est hébergée par un service de portefeuille tiers dépendant de Bankr, le contrôle réel étant entre les mains de Bankr. BaseScan a corrigé l’étiquette de cette adresse de « Grok » à une autre identification liée à Bankr, comme Bankr 1.

()

Ce portefeuille détient une grande quantité de DRB (environ 3 milliards), également issue du mécanisme de Bankr : plus tôt cette année, un utilisateur a demandé à Grok des suggestions pour nommer un jeton, et Grok a répondu « DebtReliefBot » (abrégé DRB). Par la suite, le système Bankr a analysé cette réponse comme un signal de déploiement, déclenchant le processus de création du jeton sur la chaîne Base, et en suivant ses règles Launchpad, a attribué la part du créateur à ce portefeuille associé.

Processus d’attaque

L’attaque se divise principalement en deux phases clés : la montée en permissions et l’injection d’instructions, formant une chaîne complète de « entrée non fiable → sortie AI → exécution par un agent externe → transfert d’actifs ».

1. Phase de montée en permissions

L’attaquant (adresse associée ilhamrafli.base.eth) a activé via un mécanisme centralisé l’adhésion au Bankr Club pour ce portefeuille. Cette opération a débloqué l’accès à l’ensemble des outils à haute permission de @bankrbot (ensemble d’outils agentiques), lui fournissant les permissions nécessaires pour effectuer des transferts ultérieurs.

2. Phase d’exécution de l’injection de prompt

L’attaquant a envoyé à @grok un code Morse soigneusement construit. Après traduction/décodage selon la demande de l’utilisateur, Grok a produit une instruction en clair et l’a envoyée à @bankrbot. Ce dernier a considéré la réponse publique de Grok comme une commande exécutable valide, lançant directement une opération de transfert sur la chaîne Base.

()

L’attaquant a ensuite rapidement échangé le DRB contre USDC/ETH. Après l’attaque, le compte concerné a rapidement supprimé le contenu et s’est déconnecté.

Ce qui rend cette attaque astucieuse, c’est qu’elle exploite pleinement la caractéristique de « réponse utile » de Grok, contournant le filtrage habituel des sources d’instructions par @bankrbot, et construisant une boucle fermée entre la sortie de l’IA et l’exécution sur la chaîne.

Situation de récupération des fonds

Après l’incident, la communauté et l’équipe Bankr ont suivi la situation, montrant qu’environ 80% à 88% de la valeur des fonds a été récupérée via des négociations (principalement sous forme de USDC et ETH). La partie restante, selon les parties concernées, a été traitée comme une récompense de bug informelle. Bankrbot a confirmé publiquement les détails de l’attaque et a pris des mesures restrictives en conséquence.

Analyse des causes profondes

Défaut du modèle de confiance : Bankrbot mappe directement la sortie en langage naturel de Grok en instructions financières exécutables, sans vérifier suffisamment la source, l’intention ou la présence de modes anormaux (comme le code Morse ou d’autres encodages non standard).

Manque d’isolation des permissions : l’activation de la qualification de membre donne directement accès à des outils à haut risque, sans confirmation secondaire ou limite de quota.

Fuzzy boundary entre agents : Grok, en tant qu’IA conversationnelle, ne devrait pas voir sa sortie comme une autorisation financière, mais elle est considérée comme un signal fiable par la couche d’exécution.

Risques liés au traitement des entrées : les modèles LLM sont vulnérables aux injections de prompts ou à la contournement par encodages non standard, ce qui est un problème connu, mais qui peut entraîner des pertes importantes lorsqu’il est combiné avec des couches d’exécution de vrais actifs.

Il est important de souligner que Grok ne détient pas de clés privées ni n’effectue directement des opérations sur la chaîne ; il s’agit plutôt d’un maillon intermédiaire exploité, la véritable entité d’exécution étant le système de trading automatisé @bankrbot.

Leçons de sécurité

Cet incident fournit une leçon pratique importante pour le domaine AI + agents crypto :

Les sorties en langage naturel doivent être strictement découplées des actions financières ;

Les opérations de haute valeur doivent inclure une vérification multiple, un contrôle de quota, une détection d’anomalies (type d’encodage, seuils de montant, liste blanche des sources, etc.) ;

L’interaction entre agents doit privilégier des protocoles structurés et vérifiables plutôt que des instructions en texte brut ;

Les modèles de menace d’injection de prompt doivent être intégrés dans la conception de l’ensemble du système d’agents, y compris l’utilisation indirecte d’autres IA.

Résumé

Il s’agit d’un incident classique de sécurité de la chaîne de permissions des agents AI. Bien que Grok ait été exploité via une injection de prompt, le problème fondamental réside dans le fait que : dans le système Bankrbot, la sortie de l’IA est faiblement liée à la couche d’exécution des actifs réels. Cet incident constitue un cas pratique très précieux pour le domaine AI + agents crypto, et envoie un signal clair : lorsque l’agent se voit confier la capacité d’exécution sur la chaîne, il faut établir des frontières de confiance strictes et des mécanismes de contrôle de sécurité. À l’avenir, la sécurité des infrastructures connexes doit continuer à être renforcée pour faire face à ce type de nouvelles attaques inter-systèmes et inter-sémantiques.