Sur son compte X, Hoskinson a exhorté la communauté à rester prudente concernant ce qu’il appelle les outils de code critiques circulant dans l’écosystème. Son message citait directement une reconstruction de bytecode effectuée par un analyste technique connu sous le nom de CyberSatoshi.
Le rapport affirme que l’attaquant a déployé un contrat de balayage automatisé spécifiquement adapté à l’infrastructure de l’échange. Cependant, Hoskinson n’a pas précisé les vulnérabilités techniques directes du protocole Ethereum, ni précisé quels aspects exacts du rapport il a approuvé.
La discussion technique a structuré le débat autour de deux éléments distincts. D’une part, les enquêteurs étudient comment les attaquants ont obtenu l’autorisation de signer des transactions au nom du portefeuille concerné ; d’autre part, ils évaluent la portée opérationnelle que la norme de délégation d’Ethereum permettait une fois les informations d’identification obtenues.
D’après la reconstitution technique présentée par CyberSatoshi, le code malveillant maintenait un équilibre d’exactement 1 ETH dans le portefeuille tout au long du processus de drainage des actifs. L’évaluation de l’analyste suggère que cette condition visait à empêcher les systèmes de surveillance automatisés de Binance de signaler des défaillances dues à un solde insuffisant pour les frais de gaz.
L’analyse souligne également que le contrat a exécuté une boucle utilisant des appels de bas niveau pour vérifier les soldes de jetons dans le Adresse Binance 14. Cette structure permettait à la séquence de transactions de continuer à traiter d’autres actifs même si un contrat individuel échouait ou était mis sur liste noire.
De plus, le document technique indiquait qu’une fonction d’exécution personnalisée interagissait avec un coffre-fort externe 823 millions de dollars en USDC. D’après les données fournies par CyberSatoshice contrat reconnaissait l’adresse Binance 14 en tant qu’administrateur légitime, facilitant les directives sur les fonds externes à son solde immédiat en chaîne.
Mécanismes techniques de délégation et règles de consensus
La proposition EIP-7702 définit un type de transaction qui permet à un compte externe (EOA) de déléguer temporairement son exécution à la logique d’un contrat intelligent.
Sous traditionnel Éthereum Dans cette architecture, un compte externe fonctionne exclusivement grâce aux signatures générées par sa clé privée. Avec le déploiement de cette norme, le compte peut exécuter une logique contractuelle avancée dans son propre contexte opérationnel, facilitant ainsi le traitement des transactions par lots.
La spécification technique du protocole établit que chaque autorisation doit inclure l’identifiant de la chaîne, l’adresse du délégué et le compte nonce, accompagnés d’une signature cryptographique. Lors de la validation, les nœuds du réseau vérifient la correspondance des signatures avant d’appliquer la délégation demandée.
Dans son rapport, CyberSatoshi a reconnu cette règle fondamentale de sécurité des réseaux. L’analyste a déterminé que l’attaque nécessitait strictement l’accès à la clé privée d’origine ou des autorisations de signature illimitées au sein des systèmes internes de la bourse.
La documentation d’Ethereum ne précise pas comment les identifiants d’accès de Binance ont été compromis. Néanmoins, les exigences cryptographiques confirment que le réseau ne permet pas d’attribuer des délégations à des comptes tiers sans une autorisation dûment signée.
Concernant le traitement par lots, le rapport indique que l’attaquant a soumis 50 autorisations consécutives avec des noms occasionnels progressifs pour accélérer les modifications de la séquence de transactions sur le compte Binance 14. Éthereum les spécifications traitent ces entrées dans un ordre séquentiel, en incrémentant le nonce et en exécutant la dernière délégation valide reçue.
La documentation officielle rédigée par les auteurs de la norme met explicitement en garde contre le fait que les contrats délégués obtiennent un accès illimité aux actifs du compte. Par conséquent, le cadre technique exige que le logiciel de portefeuille audite minutieusement tout code autorisé pour empêcher les transferts illicites.
Les développeurs de la proposition notent en outre que la délégation reste active sur le compte jusqu’à ce que le propriétaire diffuse une autorisation pointant explicitement vers l’adresse zéro. Des audits techniques et des enquêtes médico-légales sont en cours pour déterminer le vecteur de compromission des informations d’identification institutionnelles.
