L’exploit, d’une grande technicité, a exploité la frontière entre la logique de vérification des preuves zero-knowledge (ZK) et le traitement des transactions sur la couche 1 d’Ethereum. D’après CertiK, l’une des fonctions de vérification du contrat ne contrôlait que le début de la preuve soumise, ce qui signifie que les paramètres utilisés pour autoriser les transferts de tokens n’ont jamais été totalement validés . L’attaquant a ainsi pu présenter une preuve qui passait les premiers tests tout en dissimulant des instructions de retrait malveillantes dans la suite des données.
L’analyse menée ensuite par la société SlowMist a identifié une cause racine dans les limites de parcours de la boucle de règlement L1 au sein du contrat RollupV3. Le pirate a exploité un écart entre numRealTxs et decoded_slots, ce qui lui a permis de soumettre 31 emplacements vides à la racine d’état de la couche 2 (L2) via une preuve ZK, tout en contournant la vérification complète sur la couche 1 (L1) . Au total, l’attaquant a construit 14 preuves ZK-rollup ; les sept dernières ont vidé le contrat de sept actifs différents, en des transactions séparées
.
Ce qui rend cette affaire unique, c’est que l’attaque était structurellement impossible à stopper, et ce, par conception. Aztec Connect a été mis hors service en mars 2023, et les utilisateurs ont disposé de plus d’un an pour retirer leurs fonds . En 2024, Aztec Labs est allé plus loin en renonçant volontairement à toutes les clés d’administration et au contrôle du système. Les contrats sont devenus totalement immuables : pas de mécanisme de mise à niveau, pas de propriétaire et, surtout, pas de fonction de pause
.
« Aztec Connect a été abandonné il y a 3 ans. Aztec Labs ne détient aucune clé d’administration ni aucun contrôle sur le système ; il ne peut être ni mis en pause, ni mis à niveau », a sobrement déclaré l’équipe sur X quelques heures après l’exploit, confirmant le transfert d’environ 2,1 millions de dollars depuis le contrat immuable . Ils ont tenu à préciser que le réseau Aztec actuel et son token AZTEC (ERC-20) n’étaient pas affectés, tout en reconnaissant qu’il n’existait aucun moyen de récupérer les fonds perdus
.
Malgré une fenêtre de retrait prolongée et les communications autour de l’arrêt du service, environ 2,1 millions de dollars d’actifs résiduels d’utilisateurs sont restés bloqués dans ces anciens contrats jusqu’à l’attaque . Ces fonds étaient dans une sorte de no man’s land numérique : personne ne pouvait plus les récupérer légitimement sans interagir avec le rollup abandonné, et personne ne pouvait non plus intervenir lorsque la faille a été déclenchée.
L’affaire Aztec Connect est une illustration quasi parfaite du problème des « contrats zombies » (ou zombie contracts) dans la finance décentralisée. Les smart contracts immuables ne disparaissent pas quand un projet s’arrête. Ils persistent sur la blockchain avec leur logique – et leurs cryptomonnaies –, retenant parfois des fonds pour une durée indéfinie. Quand, par souci de décentralisation totale, on renonce aux clés d’administration, ce contrat devient un « pot de miel » (honeypot) permanent et impossible à corriger : la moindre faille non découverte se mue en bombe à retardement, prête à exploser des années plus tard sans aucun recours .
Ce risque est asymétrique. Les projets qui renoncent à tout contrôle gagnent en crédibilité, mais les utilisateurs qui ne retirent pas leurs fonds à temps portent seuls le risque. Le cas Aztec montre que même après trois ans, des millions de dollars peuvent rester bloqués dans un contrat que tout le monde croyait mort.
Pour les équipes DeFi qui prévoient d’abandonner un protocole, la leçon est claire. Avant de rendre les clés, il faut soit forcer la finalisation de tous les retraits, soit mettre en place un mécanisme d’urgence temporisé (timelock) ne nécessitant pas un contrôle administratif à long terme. Sans ces garde-fous, des infrastructures abandonnées mais immuables continueront inévitablement d’attirer des attaquants prêts à fouiller à la recherche de failles impossibles à réparer .
Comments
0 comments