Piratage de Binance : ce que révèle la délégation de code sur Ethereum

Une autorisation donne des fonctions au compte

L’analyse du piratage de Binance met en lumière une fonction d’Ethereum : EIP-7702 permet à un compte ordinaire de désigner du code dont il exécutera les instructions. Cette délégation repose sur une autorisation signée par le compte concerné. Elle peut servir à ajouter des fonctions programmables à un portefeuille, mais son effet dépend du programme choisi. Dans le cas étudié par Hacken et d’autres analystes, le compte identifié comme Binance 14 a été associé à un programme destiné à déplacer ses actifs vers l’attaquant.

La spécification explique qu’une délégation peut persister au-delà de la transaction qui l’installe. Le portefeuille ne revient donc pas automatiquement à son comportement initial après la première exécution. Cette propriété donne un sens particulier à la révocation ou au remplacement d’une autorisation. Elle ne signifie pas que toutes les applications utilisant cette fonction sont compromises : le risque dépend du code autorisé et de la façon dont la signature est obtenue. EIP-7702 ne doit pas non plus être décrit comme un simple protocole de multisignature.

Le compteur explique la série d’autorisations

Hacken rapporte la présence de 50 autorisations préparées pour des valeurs consécutives du compteur du portefeuille. Ce compteur, souvent appelé nonce, permet notamment d’ordonner les opérations d’un compte. Une autorisation n’est applicable que si ses conditions correspondent à l’état attendu. Pour un portefeuille opérationnel utilisé fréquemment, cet état peut changer entre la préparation et l’exécution. Une série de valeurs successives augmente donc les possibilités de rencontrer la valeur correcte, sans démontrer que les règles de validation du réseau ont été contournées ou que des signatures ont été forgées.

Ce déroulement n’explique cependant pas tous les transferts de l’incident. Les analyses distinguent la délégation observée sur Ethereum des mouvements ordinaires signés sur d’autres réseaux et depuis d’autres portefeuilles. Réduire l’ensemble du piratage à cette seule fonction laisserait de côté cette dimension multichaîne. L’observation publique montre ce qui a été autorisé et exécuté ; elle ne révèle pas directement l’organisation interne des systèmes de Binance, les accès obtenus en amont ou l’ensemble des validations qui auraient dû empêcher les instructions malveillantes.

Une signature valide ne révèle pas toute l’intrusion

Une clé extraite et un dispositif de signature légitime détourné peuvent produire des transactions portant une signature valide. La chaîne permet de vérifier cette validité, mais pas de départager automatiquement ces scénarios. Binance indique, dans ses déclarations d’enquête, ne pas avoir trouvé de preuve de fuite de clés privées à ce stade. Cette formulation doit conserver sa portée limitée : elle décrit les conclusions provisoires de l’opérateur, sans transformer l’absence de preuve publiée en démonstration définitive de ce qui s’est produit dans ses systèmes.

Le rapport technique complet devra relier les observations publiques aux éléments internes : origine de l’accès, droits obtenus, processus de signature et contrôles de retrait. En attendant, il est possible d’expliquer la délégation utilisée et les risques d’un programme autorisé à agir sur un compte, sans attribuer au protocole Ethereum une faille qui n’a pas été établie. Le point central reste l’obtention des autorisations nécessaires. Comprendre leur utilisation aide à reconstituer l’exécution ; cela ne remplace ni l’identification de la cause initiale ni la vérification de toutes les hypothèses d’enquête.