Hoskinson dénonce le code du « sweeper » de Binance alors que le débat sur l'EIP-7702 s'intensifie

Charles Hoskinson, fondateur de Cardano, a mis en garde contre un « code sérieusement dangereux » tout en partageant une analyse accusant la fonctionnalité de délégation EIP-7702 d’Ethereum d’avoir facilité le vidage rapide d’un portefeuille chaud de Binance.

Résumé

• Hoskinson a partagé une analyse technique affirmant que le « sweeper » avait été conçu spécifiquement pour l’infrastructure de portefeuilles de Binance.

• CyberSatoshi affirme que 50 autorisations signées ont permis à l’attaquant de cibler le nonce changeant des transactions du portefeuille chaud.

• L’analyse reconnaît qu’un contrôle des clés privées ou un accès illimité à la signature était nécessaire pour autoriser la délégation.

• La spécification d’Ethereum prévient que le code délégué bénéficie d’un accès sans restriction au compte et exige des vérifications de sécurité rigoureuses.

Dans son message sur X, Hoskinson écrit : « Attention, il circule un code sérieusement dangereux », accompagné d’une analyse publiée par CyberSatoshi.

Le message partagé décrit un bytecode reconstitué d’un prétendu « sweeper » EIP-7702 de Binance, affirmant que le contrat était adapté aux opérations de l’exchange. Le commentaire d’accompagnement d’Hoskinson ne mentionne aucune faille protocolaire précise ni n’explique quelle partie de l’analyse il approuve.

Le compte de CyberSatoshi pose deux questions de sécurité côte à côte : l’une concerne la manière dont l’attaquant a obtenu l’autorisation d’agir au nom du portefeuille ; l’autre, ce que la fonctionnalité de délégation d’Ethereum lui a permis de faire une fois cette autorisation obtenue.

Vous aimerez peut-être aussi : La Fondation Cardano rejoint un groupe suisse pour soutenir les actions tokenisées

Le « sweeper » de Binance aurait contourné les protections du portefeuille

Selon l’analyse de CyberSatoshi, le contrat reconstitué laissait exactement 1 ETH dans le portefeuille lors du vidage de son solde natif, empêchant ainsi la file d’attente automatisée des portefeuilles chauds de Binance de tomber en échec faute de gaz suffisant et de déclencher des alertes.

L’analyse décrit une boucle de traitement des jetons vérifiant les soldes via des appels de bas niveau et poursuivant l’exécution même si certaines opérations échouent. CyberSatoshi affirme que cela permettait au « sweeper » de continuer à traiter les actifs même si un jeton blacklisté ou non réactif ne pouvait pas être transféré.

Une fonction d’exécution personnalisée aurait permis au portefeuille compromis d’appeler un coffre-fort externe détenant 823 millions de dollars américains en USDC. Selon l’explication du poster, ce coffre-fort reconnaissait Binance 14 comme son contrôleur, autorisant ainsi les appels effectués via ce portefeuille à accéder à des fonds situés en dehors de son solde immédiat.

CyberSatoshi qualifie le contrat de spécifiquement conçu pour l’architecture de Binance. Les allégations concernant son impact sur les systèmes internes d’alerte et de trésorerie restent l’interprétation personnelle du poster quant au fonctionnement de l’opération.

L’EIP-7702 exige une autorisation signée pour la délégation

La spécification EIP-7702 d’Ethereum décrit un type de transaction permettant à un compte contrôlé par clé privée de déléguer l’exécution à un code déployé à une autre adresse.

Un compte contrôlé par clé privée fonctionne normalement via des signatures issues de sa clé privée. La délégation lui permet d’exécuter une logique de contrat intelligent dans son propre contexte, ce qui permet notamment de regrouper plusieurs opérations en une seule transaction ou de laisser un autre compte payer les frais.

Chaque autorisation identifie une chaîne, une adresse déléguée et un nonce, accompagnés d’une signature cryptographique. Le protocole récupère le compte auteur à partir de cette signature et vérifie son nonce avant d’appliquer la délégation.

CyberSatoshi a reconnu cette exigence, affirmant que l’attaque présumée nécessitait soit la clé privée brute, soit un accès illimité à la signature au sein de l’infrastructure de sécurité de Binance 14.

La spécification ne précise pas comment les identifiants de signature de Binance ont été obtenus. Son exigence de signature établit toutefois qu’une délégation ne peut pas être attribuée arbitrairement à un compte victime sans autorisation valide.

Les règles du nonce d’Ethereum expliquent le lot présumé

CyberSatoshi a affirmé que l’attaquant avait soumis 50 autorisations pré-signées couvrant des nonces consécutifs afin de surprendre Binance 14 pendant que son nombre de transactions évoluait.

La spécification traite les autorisations dans l’ordre. Si une autorisation échoue à une vérification, le traitement passe à l’entrée suivante. Une entrée valide définit la délégation et incrémente le nonce du compte auteur.

Des autorisations successives pour le même compte peuvent donc devenir valides à mesure que ce nonce augmente. Lorsque plusieurs entrées valides existent, la dernière délégation valide détermine l’adresse du code utilisé.

Ceci est plus précis qu’un lot où une seule autorisation peut prendre effet. Les règles autorisent plusieurs entrées consécutives à réussir, selon le nonce initial du compte et les signatures fournies.

CyberSatoshi a fait valoir que la délégation a compressé les transferts d’actifs en une seule opération, réduisant ainsi le temps disponible pour intervenir. L’affirmation distincte selon laquelle les défenses des bourses auraient sinon stoppé le vol après trois transactions constitue une évaluation contrefactuelle de l’auteur.

Le document de conception d’Ethereum détaille les risques liés à la délégation

Les auteurs de l’EIP mettent explicitement en garde contre l’accès illimité du code autorisé au compte, qui doit faire l’objet d’un audit rigoureux par le portefeuille.

Sa section sécurité énumère les protections requises pour les contrats délégués, notamment l’empêchement des rejeux et des signatures couvrant la valeur, le gaz, la destination et les données d’appel. Une délégation mal implémentée peut laisser un attaquant presque un contrôle total sur le compte signataire.

La délégation persiste au-delà de la transaction qui l’installe. La spécification précise également qu’un échec d’exécution ne remet pas en cause les indicateurs de délégation déjà traités.

Pour supprimer la délégation, le protocole autorise une autorisation valide pointant vers l’adresse zéro, ce qui efface le code de délégation du compte.

En savoir plus : Polymarket lance des marchés or et argent de 15 minutes avec Chainlink