Imaginez un portefeuille d’échange qui détient des centaines de millions de dollars en actifs. En quelques secondes, tout disparaît, sauf un petit solde soigneusement laissé pour ne pas déclencher d’alerte. C’est exactement le scénario que Charles Hoskinson a mis en lumière récemment en partageant une analyse technique détaillée. Le fondateur de Cardano a simplement écrit « Attention, il y a du code sérieusement dangereux dehors » avant de relayer le travail d’un chercheur indépendant. Derrière cette alerte se cache un débat bien plus large sur la nouvelle fonctionnalité de délégation d’Ethereum appelée EIP-7702 et sur la façon dont elle pourrait transformer des failles d’accès en vols ultra-rapides.
L’alerte de Charles Hoskinson et le code reconstruit
Tout a commencé par un post simple sur le réseau social X. Charles Hoskinson, figure bien connue de l’écosystème blockchain, a partagé une analyse signée CyberSatoshi. Le chercheur y reconstruit le bytecode d’un contrat malveillant qui aurait servi à vider un hot wallet de Binance. Hoskinson n’a pas détaillé chaque ligne de l’analyse. Il a simplement souligné le danger. Cette discrétion relative a pourtant suffi à relancer les discussions autour de la sécurité des comptes externes sur Ethereum.
L’analyse en question décrit un « sweeper » conçu spécifiquement pour l’infrastructure de l’échange. Selon le chercheur, le contrat n’agissait pas de manière générique. Il était taillé pour contourner les garde-fous internes de Binance. L’un des détails les plus frappants concerne le solde natif : le contrat laissait exactement 1 ETH dans le portefeuille. Pourquoi ? Pour éviter que le système automatisé de file d’attente du hot wallet ne tombe en panne par manque de gaz et ne déclenche une alarme.
Cette précision technique donne une idée de la sophistication de l’attaque alléguée. Il ne s’agissait pas d’un simple script de drainage. L’attaquant semblait connaître le fonctionnement interne des systèmes de l’échange et avait anticipé les mécanismes de détection basés sur les soldes insuffisants.
Un contrat taillé sur mesure pour Binance
CyberSatoshi affirme que le code reconstruit montrait une boucle de traitement des tokens particulièrement résistante. Le contrat effectuait des appels de bas niveau pour vérifier les soldes. Si une opération échouait – par exemple à cause d’un token blacklisté ou non réactif – le processus continuait simplement. Cette approche permettait de ne pas s’arrêter sur un actif problématique et de balayer le maximum d’avoirs possibles.
Plus troublant encore, une fonction d’exécution personnalisée aurait permis d’appeler un vault externe détenant 823 millions de dollars en USDC. Ce vault reconnaissait l’adresse « Binance 14 » comme contrôleur. En passant par le portefeuille compromis, l’attaquant pouvait donc atteindre des fonds situés en dehors du solde immédiat du hot wallet. L’ensemble du dispositif apparaît, selon l’analyse, comme un outil construit pour l’architecture précise de l’échange.
Ces affirmations restent bien sûr celles du chercheur. Elles n’ont pas été confirmées officiellement par Binance dans le cadre de cette discussion technique. Elles illustrent cependant le niveau de connaissance interne que l’attaquant aurait dû posséder pour concevoir un tel outil.
Deux questions de sécurité qui se croisent
L’analyse de CyberSatoshi place côte à côte deux interrogations distinctes. La première concerne l’accès initial : comment l’attaquant a-t-il obtenu la permission d’agir au nom du portefeuille ? La seconde porte sur ce que la fonctionnalité de délégation d’Ethereum a permis une fois cette permission obtenue. Hoskinson n’a pas tranché entre ces deux points. Son alerte met simplement en lumière le second aspect, celui du code dangereux qui peut s’exécuter une fois la délégation en place.
Cette distinction est essentielle. EIP-7702 n’accorde pas magiquement l’accès à un compte. Il nécessite toujours une autorisation signée valide. Mais une fois cette autorisation obtenue, les possibilités offertes par la délégation changent radicalement la dynamique d’une attaque.
Comment fonctionne réellement EIP-7702
EIP-7702 introduit un nouveau type de transaction qui permet à un compte contrôlé par une clé privée (EOA) de déléguer son exécution à un code déployé à une autre adresse. Normalement, un EOA ne peut que signer des transactions. Avec la délégation, il peut exécuter de la logique de smart contract dans son propre contexte de compte.
Cette fonctionnalité ouvre la porte à des usages pratiques : regrouper plusieurs opérations en une seule transaction, permettre à un autre compte de payer les frais de gaz, ou encore améliorer l’expérience utilisateur des portefeuilles. Chaque autorisation précise une chaîne, une adresse de délégué et un nonce, le tout accompagné d’une signature cryptographique. Le protocole récupère le compte autorisant à partir de la signature et vérifie le nonce avant d’appliquer la délégation.
CyberSatoshi reconnaît explicitement cette exigence. L’attaque alléguée nécessitait soit la clé privée brute, soit un accès non restreint à l’infrastructure de signature de Binance 14. La spécification d’Ethereum n’explique pas comment ces credentials ont été obtenus. Elle établit simplement qu’une délégation ne peut pas être imposée à un compte arbitraire sans autorisation valide.
Le rôle crucial des nonces et du lot d’autorisations
Un élément technique central de l’analyse concerne la gestion des nonces. CyberSatoshi affirme que l’attaquant a soumis 50 autorisations pré-signées couvrant des nonces consécutifs. L’objectif était de « rattraper » le portefeuille Binance 14 alors que son compteur de transactions évoluait.
La spécification traite les autorisations dans l’ordre. Si une autorisation échoue à une vérification, le protocole passe simplement à la suivante. Une entrée valide fixe la délégation et incrémente le nonce du compte autorisant. Des autorisations successives pour le même compte peuvent donc devenir valides au fur et à mesure que le nonce avance. Lorsque plusieurs entrées valides existent, c’est la dernière délégation valide qui détermine l’adresse du code utilisé.
Ce mécanisme est plus subtil qu’un simple lot où une seule autorisation peut prendre effet. Les règles permettent à plusieurs entrées consécutives de réussir, selon le nonce de départ du compte et les signatures fournies. L’attaquant aurait ainsi pu s’assurer que la délégation s’applique même si le portefeuille émettait des transactions pendant l’attaque.
CyberSatoshi ajoute que la délégation a compressé les transferts d’actifs en une seule opération. Cela aurait réduit le temps disponible pour une intervention humaine ou automatisée. L’affirmation selon laquelle les défenses de l’échange auraient autrement stoppé le vol après trois transactions relève de l’évaluation contre-factuelle du chercheur. Elle n’en reste pas moins intéressante pour comprendre pourquoi la rapidité offerte par EIP-7702 est perçue comme un facteur aggravant.
Les risques explicitement reconnus par Ethereum
Les auteurs de l’EIP n’ont pas caché les dangers. La documentation officielle avertit clairement que le code autorisé reçoit un accès non restreint au compte. Ce code doit être audité avec la plus grande attention par le propriétaire du portefeuille. La section sécurité de la spécification liste les protections que les contrats délégués doivent intégrer : prévention des rejeux, signatures couvrant la valeur de la transaction, le gaz, la destination et les données d’appel.
Une délégation mal implémentée peut laisser un attaquant avec un contrôle quasi total sur le compte signataire. De plus, la délégation persiste au-delà de la transaction qui l’installe. Un échec d’exécution n’annule pas les indicateurs de délégation déjà traités. Pour retirer une 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.
Ces mises en garde figurent dans le document de conception lui-même. Elles montrent que les développeurs d’Ethereum étaient conscients des implications de sécurité dès le départ. Le débat actuel ne porte donc pas sur une faille imprévue, mais sur la façon dont ces risques se matérialisent dans un environnement réel d’échange centralisé.
Pourquoi cette affaire dépasse le simple cas Binance
Même si l’analyse se concentre sur un portefeuille précis, les implications touchent l’ensemble de l’écosystème. Les hot wallets des exchanges représentent des cibles de choix. Ils doivent rester liquides pour traiter les retraits des utilisateurs, tout en étant suffisamment sécurisés pour résister à des attaques sophistiquées. L’introduction d’une fonctionnalité qui permet d’exécuter du code arbitraire dans le contexte du compte change la surface d’attaque.
Avant EIP-7702, un attaquant qui obtenait la clé d’un EOA devait encore envoyer des transactions individuelles pour chaque transfert. Cela multipliait les opportunités de détection et d’intervention. Avec la délégation, l’ensemble des opérations peut être regroupé. Le temps de réaction se réduit dramatiquement.
Les équipes de sécurité des plateformes d’échange devront désormais intégrer cette nouvelle dimension dans leurs modèles de menace. Les systèmes de monitoring qui se basaient sur le nombre de transactions ou sur des patterns de mouvements de fonds devront être recalibrés. Un seul appel de contrat peut désormais masquer des dizaines de transferts.
Les leçons pour les utilisateurs et les développeurs
Pour les utilisateurs individuels, le message est clair. La délégation de compte n’est pas une fonctionnalité anodine. Elle doit être traitée avec le même niveau de prudence que la signature d’un contrat intelligent complexe. Avant d’autoriser une délégation, il faut comprendre exactement quel code sera exécuté et quelles permissions il reçoit.
Les développeurs de portefeuilles et de smart contracts ont une responsabilité particulière. Les contrats destinés à être utilisés comme délégués doivent intégrer des mécanismes de sécurité robustes. La prévention des rejeux, la limitation des appels autorisés et la possibilité de révoquer facilement la délégation ne sont pas des options. Ce sont des exigences minimales.
Les échanges, de leur côté, devront revoir leurs procédures de signature. L’accès non restreint aux systèmes de signature devient encore plus critique. Un compromis à ce niveau, combiné à EIP-7702, peut transformer une brèche limitée en un drainage massif et quasi instantané.
Le débat technique continue
L’alerte de Hoskinson n’est pas une condamnation pure et simple d’EIP-7702. Elle souligne plutôt la nécessité d’une vigilance accrue. La fonctionnalité apporte des avantages indéniables en termes d’expérience utilisateur et d’efficacité. Mais ces avantages s’accompagnent d’une surface d’attaque élargie.
Dans les jours qui ont suivi le partage de l’analyse, la communauté a commencé à discuter des meilleures pratiques. Certains proposent des listes blanches strictes pour les codes délégués. D’autres insistent sur l’importance d’audits indépendants systématiques. D’autres encore explorent des mécanismes de délégation temporaires qui expireraient automatiquement après un certain nombre de blocs.
Ces discussions sont saines. Elles montrent qu’Ethereum continue d’évoluer en tenant compte des retours du terrain. Chaque nouvelle fonctionnalité, aussi utile soit-elle, doit être confrontée à la réalité des menaces existantes.
Une sophistication qui inquiète
Ce qui frappe dans l’analyse de CyberSatoshi, c’est le niveau de personnalisation du code. Le sweeper n’était pas un outil générique réutilisable. Il semblait conçu pour une infrastructure précise. Laisser exactement 1 ETH, gérer les tokens non réactifs sans s’arrêter, appeler un vault externe via le contrôleur reconnu : tout cela témoigne d’une connaissance approfondie de la cible.
Cette sophistication soulève des questions plus larges sur la sécurité des grands acteurs centralisés. Les hot wallets restent des points de concentration de valeur. Même avec des procédures de sécurité multi-niveaux, un accès à la couche de signature combiné à une fonctionnalité comme EIP-7702 peut créer une fenêtre d’opportunité très courte mais extrêmement dangereuse.
Les équipes de sécurité devront désormais simuler ce type de scénarios dans leurs exercices de red team. Les modèles de détection basés uniquement sur le volume de transactions ou sur des seuils de solde risquent de devenir obsolètes face à des opérations compressées en un seul appel.
Persistance de la délégation et possibilités de révocation
Un point technique souvent sous-estimé concerne la persistance. Une fois installée, la délégation reste active même après la transaction initiale. Cela signifie qu’un attaquant qui réussit à placer son code peut continuer à l’utiliser dans des transactions ultérieures, tant que la délégation n’est pas explicitement retirée.
La révocation passe par une autorisation pointant vers l’adresse zéro. Ce mécanisme est simple en théorie. En pratique, il suppose que le propriétaire légitime du compte conserve encore la capacité de signer une telle autorisation. Si l’attaquant a obtenu un contrôle total sur les systèmes de signature, la révocation devient évidemment beaucoup plus difficile.
Cette réalité renforce l’importance des contrôles d’accès stricts autour des infrastructures de signature des grands acteurs. La délégation ne crée pas la faille initiale. Elle amplifie considérablement les conséquences une fois la faille exploitée.
Vers une nouvelle culture de la prudence
L’épisode illustré par l’alerte de Hoskinson devrait servir de catalyseur. Les développeurs d’applications décentralisées, les équipes de portefeuilles et les exchanges doivent intégrer EIP-7702 dans leurs analyses de risque de manière systématique. Les utilisateurs, même s’ils ne manipulent pas directement ces mécanismes, doivent rester informés des évolutions qui touchent la sécurité de leurs actifs.
La blockchain Ethereum a toujours progressé par itérations. Chaque hard fork, chaque nouvelle EIP apporte son lot d’améliorations et de nouveaux défis. EIP-7702 ne fait pas exception. Sa puissance en matière d’expérience utilisateur s’accompagne d’une responsabilité accrue pour tous les acteurs de l’écosystème.
Dans les semaines et mois à venir, on peut s’attendre à voir apparaître de nouveaux outils d’audit spécialisés dans les contrats de délégation, des recommandations de bonnes pratiques émises par des groupes de travail, et peut-être même des mises à jour de la spécification elle-même pour renforcer certains garde-fous. Ces évolutions seront le signe d’une communauté qui apprend et s’adapte.
En attendant, le message de Charles Hoskinson reste d’actualité. Il existe du code sérieusement dangereux. Et la meilleure défense commence par la compréhension fine des mécanismes qui le rendent possible. La délégation de compte n’est ni bonne ni mauvaise en soi. Elle devient dangereuse lorsqu’elle est utilisée sans les précautions nécessaires. C’est précisément ce que l’analyse partagée par le fondateur de Cardano a mis en lumière, et c’est ce débat qui mérite d’être suivi de près dans les mois qui viennent.
Les échanges d’actifs numériques évoluent rapidement. Les outils offensifs évoluent tout aussi vite. Seule une vigilance constante, associée à une compréhension technique approfondie, permettra de maintenir un équilibre acceptable entre innovation et sécurité. L’affaire du sweeper allégué et de l’alerte Hoskinson constitue un rappel utile de cette réalité permanente.
