La signature vide qui a cassé Bonzo Lend : Une analyse post-mortem de l'exploitation de 9 M$ sur Hedera
2026/07/15 11:18:00
En mathématiques et en informatique, zéro représente l'absence — l'absence absolue de valeur. Mais dans l'écosystème fragile et hyperconnecté de la finance décentralisée (DeFi), un paramètre « zéro » non vérifié est récemment devenu une clé maîtresse numérique. En quelques minutes, cette unique valeur vide non vérifiée a déverrouillé et vidé plus de 9 millions de dollars d'une plateforme de prêt renommée.
La victime de cette exploitation dévastatrice était Bonzo Lend, le plus grand protocole de prêt opérant sur le réseau Hedera. En juillet 2026, le protocole a vu sa Valeur Totale Verrouillée (TVL) chuter de 77 % en un instant. Alors que la panique se répandait dans la communauté Hedera, les observateurs ont cherché désespérément la source de la fuite.
Il est important de noter que cette catastrophe n’est pas survenue parce que le consensus du réseau sous-jacent de Hedera a échoué, ni parce que les calculs de prêt principaux de Bonzo Lend étaient incorrects. Au contraire, le désastre est né d’une vulnérabilité d’intégration fatale : une faille critique de validation de signature au sein de leur fournisseur tiers de flux de prix, Supra Oracles. Voici l’analyse post-mortem de la manière dont une petite erreur logique concernant « rien » a fait tomber un géant DeFi.
Chronologie de l'attaque : de 5 $ à 9 000 000 $ en quelques secondes
L'exécution de l'exploitation Bonzo Lend a été brillante par sa simplicité, nécessitant un capital de départ minimal et se déroulant en seulement quelques étapes transactionnelles.
Pour initier le hold-up, l'attaquant a déposé une quantité minuscule et négligeable de garantie sur Bonzo Lend — précisément 250 jetons SAUCE. Au moment du dépôt, cette garantie ne valait que quelques dollars, à peine assez pour acheter une tasse de café. Selon les règles normales du protocole, cette petite somme permettrait à l'utilisateur d'emprunter seulement une fraction de sa valeur en autres actifs numériques.
Ensuite, l'attaquant a lancé l'exploitation en contournant les vérifications du price oracle. Ils ont créé et soumis une transaction de mise à jour de prix falsifiée au contrat de validation de l'oracle. Cette transaction contenait des données hautement malveillantes : elle a artificiellement gonflé le prix du jeton SAUCE de 12 ordres de grandeur — indiquant ainsi au protocole qu'un seul jeton SAUCE valait soudainement des milliards de dollars.
Pour faire passer ce prix falsifié, le système exigeait une signature cryptographique provenant d’un nœud oracle autorisé. Au lieu d’essayer de casser la cryptographie complexe ou de voler une clé privée, l’attaquant a simplement laissé le champ de signature complètement vide, en soumettant une chaîne de zéros à la place d’une signature cryptographique.
En raison d'une faille critique dans la logique de validation, le contrat a accepté la signature vide comme valide. Instantanément, le système d'évaluation de Bonzo a enregistré les 250 SAUCE en garantie de l'attaquant comme un actif d'une valeur monumentale. Exploitant cette richesse soudaine et artificielle, le pirate a rapidement retiré 6,63 millions d'USDC et 34,50 millions de HBAR emballés (wHBAR) des piscines de liquidité de Bonzo, vidant avec succès le protocole avant que toute alerte ne puisse être déclenchée.
Démystifier la faille « Zero-Signature » : comment le code a échoué
Pour comprendre comment cette exploitation a été possible, nous devons démystifier les mathématiques des signatures numériques. Dans les réseaux décentralisés, les signatures cryptographiques agissent comme des cachets de cire numériques. Lorsqu'un nœud oracle publie une mise à jour de prix, il signe les données en utilisant une clé privée. Le contrat intelligent à l'extrémité réceptrice utilise un algorithme de vérification pour confirmer que la signature correspond à la clé publique autorisée du nœud oracle.
Normalement, si un utilisateur soumet une signature invalide, la bibliothèque de vérification tente de traiter l'entrée et échoue. Lorsque les bibliothèques de vérification cryptographique rencontrent des entrées malformées, vides ou entièrement nulles, elles ne lèvent pas toujours une erreur active. Au lieu de cela, de nombreuses bibliothèques standard sont conçues pour produire une valeur par défaut lorsque la signature ne peut pas être analysée. Dans contrats intelligents, cette valeur par défaut est presque toujours une adresse nulle représentée par une longue chaîne de zéros.
La vulnérabilité fatale dans le contrat de validation de l'oracle résidait dans la manière dont il gère cette adresse nulle par défaut. Le contrat était programmé pour vérifier si le signataire récupéré correspondait à une adresse de nœud oracle autorisée. Cependant, les développeurs ont oublié d'inclure une règle de base : rejeter toute entrée dont la longueur de la signature est nulle ou où l'adresse récupérée retourne une valeur nulle.
De plus, si l'état du signataire autorisé dans le contrat était non initialisé ou configuré de manière à permettre des vérifications nulles, le contrat comparait l'adresse nulle retournée par la signature échouée à ses paramètres internes et déclarait une correspondance. Étant donné que la logique de validation n'a pas réussi à distinguer entre une « récupération de signature échouée » et un « signataire autorisé valide », le contrat a traité la signature vide comme une autorisation absolue, approuvant le flux de prix contrefait.
Le dilemme de l'oracle : pourquoi les Lego DeFi ne sont aussi solides que leur maillon le plus faible
Le DeFi est souvent célébré pour sa « compositabilité » — la capacité de différents protocoles, jetons et outils à se connecter comme des « Legos financiers » pour construire des applications financières complexes. Bien que la compositabilité permette une innovation rapide, elle introduit également une fragilité systémique. Un seul défaut dans un bloc de construction fondamental peut faire s’effondrer toute la pile structurelle.
L'exploitation de Bonzo Lend illustre parfaitement cette vulnérabilité. Bonzo Lend lui-même était un protocole de prêt bien structuré ayant subi des audits de sécurité. Toutefois, le protocole devait faire confiance à sa dépendance externe en oracle pour fournir des prix précis. Dès que le système de validation de l'oracle a accepté le prix falsifié, les contrats de prêt de Bonzo ont été exécutés exactement comme ils étaient écrits, permettant à l'utilisateur « riche » fortement garanti d'emprunter des actifs.
Le tableau ci-dessous détaille la répartition des responsabilités structurelles pendant l'attaque, illustrant où la ligne défensive s'est effondrée :
| Composant | Rôle systémique prévu | Performance pendant l'exploit | Leçon structurelle |
| Couche de consensus Hedera | Maintenez l'état du registre sécurisé, ordonnez les transactions et assurez la disponibilité du réseau. | Exécuté parfaitement sans aucun temps d'arrêt ni exploitation au niveau du réseau. | Une couche de consensus réseau sécurisée ne garantit pas la sécurité au niveau de l'application. |
| Supra Oracle | Fournir des données de prix d'actifs signées, cryptographiquement vérifiées et précises. | Échec du rejet d'une signature nulle, publication d'un prix corrompu. | Les dépendances doivent être traitées selon des paradigmes de validation à confiance nulle. |
| Bonzo Prêter | Gérez les actifs déposés, surveillez les ratios de santé des prêts et traitez les emprunts. | A fait confiance aux données de prix entrantes sans restriction, négligeant de limiter les pics soudains de prix. | Les contrats intelligents doivent implémenter une logique défensive pour survivre aux défaillances de dépendance. |
L'intervention du chapeau blanc : une course de 1 million de dollars contre le pirate
Alors que l'exploitation se déroulait sur le registre public, un événement secondaire spectaculaire s'est produit. Sur les blockchains publiques, les transactions sont visibles dans le « mempool » avant d'être finalisées. Cette transparence permet à d'autres acteurs, aussi bien malveillants qu'éthiques, d'analyser les attaques en temps réel.
Peu après que l'attaquant principal ait commencé à vider le protocole, un chercheur en sécurité indépendant—souvent appelé « hacker à chapeau blanc »—a repéré l'exploit actif. Reconnaissant que l'ensemble du protocole allait être vidé, le hacker à chapeau blanc a rapidement exécuté exactement la même vulnérabilité sans signature pour retirer environ 1 million de dollars en actifs.
Cette tactique, connue sous le nom de « front-running », est une manœuvre défensive courante en matière de sécurité Web3. En prenant les fonds en premier, le white hat a empêché l'acteur malveillant de voler cette partie de la piscine de liquidité.
Après le retrait réussi, le white hat a immédiatement pris contact avec l'équipe de Bonzo Lend. Après avoir confirmé leur identité et leurs intentions, le hacker éthique a restitué en toute sécurité les 1 million de dollars entiers aux adresses de récupération du protocole. Bien que l'attaquant principal ait toujours réussi à s'échapper avec la majorité des fonds, cette intervention rapide a préservé une partie essentielle des actifs de la communauté et démontré la nature unique et collaborative de la sécurité Web3.
À la poursuite des millions : Comment les fonds volés ont quitté l'écosystème Hedera
Une fois que le pirate a réussi à emprunter des millions de dollars en USDC et wHBAR contre ses collatéraux falsifiés, son objectif principal est de quitter l'écosystème Hedera avant que le protocole ne puisse suspendre ses contrats.
L'attaquant n'a pas conservé les actifs volés dans leur forme d'origine. En utilisant SaucerSwap, une plateforme d'échange décentralisée populaire sur Hedera, le pirate a rapidement échangé les jetons empruntés contre des stablecoins et des actifs natifs hautement liquides pour éviter les mécanismes de gel centralisés.
Immédiatement après l’échange des jetons, l’attaquant a utilisé des ponts cross-chain, en acheminant spécifiquement les fonds via LayerZero. En reliant les actifs, le pirate a transféré plus de 5 millions de dollars de fonds volés directement sur le mainnet Ethereum.
Une fois les actifs transférés sur un réseau très liquide et massif comme Ethereum, les suivre et les récupérer devient exponentiellement plus difficile. Les fonds peuvent être répartis sur des centaines d'adresses nouvelles, déposés dans des mixeurs de confidentialité décentralisés ou échangés contre des monnaies de confidentialité non custody. Cette voie de fuite rapide et automatisée souligne pourquoi la surveillance en temps réel et les pauses d'urgence immédiates sont les seules défenses viables contre les exploitations interchaînes modernes.
Les leçons difficiles : comment les protocoles DeFi peuvent se protéger contre les désastres d'oracles
La perte de 9 millions de dollars est une leçon extrêmement coûteuse, mais elle offre des connaissances inestimables aux développeurs de contrats intelligents cherchant à sécuriser leurs applications contre de futures erreurs d'intégration.
Pour prévenir les vulnérabilités liées aux signatures nulles, les développeurs doivent adopter des pratiques de codage strictes et défensives. Les améliorations structurelles clés incluent :
-
Vérification explicite de l’adresse nulle : Ne supposez jamais qu’une fonction de vérification de signature a réussi. Chaque routine de validation cryptographique doit vérifier explicitement que la longueur de la signature est supérieure à zéro et confirmer que l’adresse de sortie ne résout pas vers une valeur nulle (
0x00...00). Si une valeur nulle est retournée, la transaction doit être immédiatement annulée. -
Architectures oracles redondantes : Faire confiance à un seul fournisseur d'oracle crée un point unique de défaillance. Les protocoles DeFi robustes doivent récupérer les prix des actifs à partir de plusieurs réseaux oracles indépendants (tels que Chainlink, Pyth et Supra simultanément). Si un flux s'écarte significativement de la médiane des autres, le protocole doit signaler l'incohérence et suspendre automatiquement les opérations.
-
Circuits de protection des prix sur chaîne : les protocoles de prêt doivent mettre en œuvre des limites de taux et des seuils de déviation des prix. Même si une oracle affirme que la valeur d'un token a augmenté d'un trillion de fois en un seul bloc, le circuit de protection interne du contrat intelligent doit rejeter cette mise à jour comme une anomalie, en arrêtant toute action d'emprunt ou de liquidation jusqu'à ce qu'une vérification administrative manuelle soit effectuée.
L'avenir des audits de contrats intelligents : pourquoi nous devons tester les limites
L'exploitation de Bonzo Lend révèle une limitation critique des pratiques d'audit actuelles en Web3. De nombreux audits de sécurité se concentrent fortement sur la vérification du fonctionnement de la logique métier d'un contrat dans des conditions attendues — souvent appelée test « happy-path ».
Cependant, les attaquants du monde réel ne suivent pas le chemin idéal. Ils recherchent spécifiquement les conditions limites, les états non initialisés et les entrées inattendues. L'industrie de la sécurité doit adopter des tests agressifs sur les cas limites pour révéler les failles cachées avant le déploiement sur le mainnet.
Pour y parvenir, les protocoles doivent rendre les méthodologies de test avancées, telles que le fuzzing et la vérification formelle, des normes obligatoires. Le fuzzing consiste à utiliser des outils automatisés pour inonder les contrats intelligents de millions d’entrées aléatoires, malformées et vides — y compris des chaînes de bytes vides et des signatures nulles. Si le contrat de vérification avait été soumis à un fuzzing rigoureux, la contournement par signature nulle aurait été immédiatement détecté.
Finalement, les fournisseurs tiers d'oracles doivent également adopter des normes de sécurité plus élevées. Étant donné que ces flux de données constituent la base de centaines de millions de dollars d'activités économiques, leur code de vérification doit être soumis au même niveau de rigueur que les réseaux de couche un qu'ils soutiennent.
Conclusion : Rétablir la confiance dans un écosystème sans confiance
L'exploitation de Bonzo Lend est un rappel saisissant de la nature impitoyable des contrats intelligents. Dans Web3, le code est loi, et l'EVM ne se soucie pas de vos intentions. Un petit défaut de logique concernant « rien » peut effacer instantanément des années de développement et des millions de dollars de confiance des utilisateurs.
Dans la foulée de l'attaque, Bonzo Lend et Supra Oracles ont rapidement corrigé la vulnérabilité et sécurisé l'infrastructure restante. Bien que cet incident ait été douloureux, les leçons tirées mèneront inévitablement à des normes d'intégration plus sécurisées dans tout le paysage DeFi. Pour les développeurs et les investisseurs alike, la leçon principale est simple : ne jamais considérer la sécurité de l'intégration comme acquise, tester les limites de votre code et toujours vérifier ce qui se passe lorsque vous n'entrez rien dans vos systèmes.
FAQ :
Q1 : La faille « Zero-Signature » signifie-t-elle que la cryptographie de la blockchain est compromise ?
Non. Les principes mathématiques à la base des signatures numériques et de la cryptographie à clé publique restent entièrement sécurisés. L'exploitation a été causée par une faille logique de programmation dans le contrat intelligent qui gère la sortie de la bibliothèque cryptographique. La bibliothèque a agi correctement en retournant une valeur nulle lorsqu'elle recevait une signature vide, mais le contrat a interprété incorrectement cette valeur nulle comme une vérification réussie.
Q2 : Pourquoi Bonzo Lend a-t-il automatiquement fait confiance à un prix aussi absurde pour SAUCE ?
Les protocoles de prêt sont conçus de manière modulaire, ce qui signifie qu'ils déléguent la tâche complexe de la fixation des prix à des réseaux d'oracles dédiés. Étant donné que Bonzo Lend a été conçu pour accepter le flux de prix de l'oracle comme vérité absolue, sans aucune vérification locale indépendante ni limites de déviation des prix, il a accepté l'augmentation artificielle du prix par un facteur d'un trillion et a autorisé la transaction d'emprunt à se poursuivre.
Q3 : Que peuvent faire les utilisateurs quotidiens de DeFi pour se protéger contre les attaques liées aux oracles ?
Bien que les utilisateurs ne puissent pas contrôler le code d'un protocole, ils peuvent gérer leur propre risque. Pour protéger votre capital, diversifiez vos actifs sur plusieurs plateformes indépendantes, évitez les protocoles qui dépendent d'une seule source d'oracle pour des actifs spécialisés, et privilégiez les plateformes ayant intégré publiquement des systèmes d'oracle multi-sources et des dispositifs d'arrêt d'urgence robustes sur chaîne.
Clause de non-responsabilité : Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil en investissement. Les investissements en cryptomonnaies comportent des risques. Veuillez effectuer vos propres recherches (DYOR).
Avertissement : Pour votre confort, cette page a été traduite à l'aide de la technologie IA. Pour obtenir les informations à la source, consultez la version anglaise originale.