Crypto et piratage — Les cauchemars des Black Hats

La crypto est souvent dépeinte comme une forteresse de cryptographie, de consensus décentralisé et de registres immuables. Mais la réalité de cette terre promise numérique est bien plus complexe, et plus dangereuse. Les médias grand public traitent généralement du piratage de l'écosystème crypto via l'ingénierie sociale ou des campagnes de phishing, ou simplement d'arnaques où un utilisateur peu méfiant est amené à saisir l'adresse d'une plateforme d'échange ou sa clé privée sur un site malveillant.

Mais cet article ignorera totalement ces défaillances d'origine humaine. Dans cet article, nous parlerons de piratage pur. C'est le domaine de la cybersécurité défaillante et du code profondément imparfait qui entraîne des brèches catastrophiques. Ce sont les rêves des « black hats » où le code est utilisé comme une arme contre ses créateurs, siphonnant des centaines de millions de dollars en quelques minutes sans même tirer un seul coup de feu ; nous confrontant aux extrêmes de la faillibilité logique, des bogues de compilateur et des erreurs de conception architecturale.

L'origine des failles de contrats intelligents

Le piratage pur de contrats intelligents nécessite une explication pour commencer — l'un des cas les plus notoires de l'histoire de la DeFi à l'époque, qui a changé le cours d'Ethereum à jamais. À l'époque des premières blockchains programmables, il existait un projet appelé « The DAO ». Le fonds était censé être une sorte de fonds de capital-risque décentralisé géré totalement par des contrats intelligents — sans aucune intervention humaine.

Le contrat avait attiré des millions de dollars en Ether de la part d'investisseurs espérant voter sur des propositions et obtenir des récompenses. Cependant, les développeurs n'avaient pas implémenté le processus de retrait de manière sécurisée, une faille connue sous le nom de réentrance (reentrancy).

Réentrance — Un contrat intelligent appelle un contrat externe mais ne met pas à jour son état interne. Par exemple, dans The DAO, la fonction de retrait transférait d'abord les fonds demandés à l'utilisateur et ne mettait à jour l'état de l'utilisateur avec le montant retiré qu'ensuite.

Un hacker « black hat » réalise qu'il peut également déployer un contrat intelligent malveillant doté d'une fonction de repli (fallback function).

La fonction de repli est invoquée chaque fois que The DAO envoie des fonds à ce contrat malveillant. La fonction de repli ne s'est pas contentée d'accepter les fonds ; elle a immédiatement rappelé la fonction de retrait de The DAO. Cela a déclenché la fonction de repli une fois de plus, que The DAO a exécutée, car le solde du hacker n'avait pas encore été mis à jour au moment du premier retrait.

Ce processus s'est répété inlassablement, extrayant des millions de dollars de The DAO avant que le réseau ne puisse réagir.

Conséquences et Hard Fork

Les retombées de ce piratage ont été sans précédent. Le réseau risquait de s'effondrer et un pourcentage important de tous les Ethers en circulation a été dérobé. Cela a créé une crise existentielle et technique pour la communauté, ce qui a finalement conduit celle-ci à mettre en œuvre un hard fork afin de réinitialiser l'historique de la blockchain et de restituer les fonds.

Cette décision controversée a provoqué une scission permanente, donnant naissance à Ethereum et Ethereum Classic. Cette vulnérabilité particulière est aujourd'hui bien connue et principalement atténuée par l'utilisation du modèle « Checks-Effects-Interactions ».

Ce modèle stipule qu'un contrat doit d'abord valider toutes les conditions, ce n'est qu'ensuite qu'il pourra mettre à jour son état interne, et il ne doit appeler des contrats externes qu'à la toute dernière étape.

Cependant, bien que la réentrance de base soit désormais très facilement détectée par les outils d'audit automatisés, des attaques de réentrance inter-contrats subtiles peuvent encore survenir dans des circonstances très particulières et de niche, montrant que même des concepts éprouvés peuvent se métamorphoser en de nouvelles attaques.

L'ère de la logique non initialisée et des Delegate Calls

Les leçons tirées de The DAO ont été rapidement assimilées par la communauté des développeurs, qui a depuis développé des systèmes d'une complexité croissante, s'appuyant sur des concepts tels que les contrats de bibliothèque et les modèles de proxy pour économiser du gas et faciliter l'évolutivité. Au sein de cette complexité est apparu un vecteur supplémentaire de piratage pur, l'exemple le plus notoire étant les vulnérabilités du portefeuille multi-signature Parity.

Parity est un client Ethereum largement utilisé qui proposait un contrat intelligent pour un portefeuille multi-signature dont la logique centrale résidait dans un contrat de bibliothèque centralisé. L'objectif était d'optimiser les ressources, puisque de nombreux portefeuilles pouvaient pointer vers la même bibliothèque au lieu de déployer le même code plusieurs fois.

Ce type de vulnérabilité était dû à une mauvaise compréhension de la fonction delegatecall et des variables d'état non initialisées. La fonction delegatecall permet à un contrat d'exécuter une fonction d'un autre contrat tout en donnant à cette fonction l'accès au stockage du contrat appelant. Au sein du contrat de bibliothèque de Parity se trouvait une fonction permettant d'initialiser les propriétaires du portefeuille.

Mais le contrat de bibliothèque lui-même n'a jamais été réellement initialisé. Un hacker a découvert qu'il pouvait appeler la fonction d'initialisation directement sur le contrat de la bibliothèque et s'en proclamer propriétaire. Après avoir pris le contrôle de la bibliothèque, il a invoqué une fonction pour l'autodétruire.

Gel des portefeuilles multi-signatures

Les portefeuilles multi-signatures qui dépendaient de cette bibliothèque sont immédiatement devenus inopérants lorsque celle-ci a été détruite. Toute la logique nécessaire pour traiter une transaction, permettre un retrait ou même simplement consulter un solde a été perdue. Au cours de ce processus, en raison d'une pure erreur d'architecture, des centaines de millions de dollars en Ether n'ont pas été volés, mais physiquement gelés.

Cela a mis en lumière le danger extrême des contrats de logique non initialisés et les risques subtils associés aux fonctions delegatecall — un ensemble de risques qui semble aujourd'hui de notoriété publique, mais qui n'était pas aussi bien compris à l'époque. Pour y remédier, les développeurs s'appuient désormais sur des modificateurs d'initialisation spéciaux qui garantissent qu'un contrat ne peut être initialisé qu'une seule fois, et ils placent fréquemment des valeurs fictives dans l'état du contrat de logique du déployeur afin que personne ne puisse réclamer de paiement.

Bien qu'une En raison du volume considérable d'actifs qu'ils détenaient, ils constituaient de véritables pots de miel pour les hackers black hat.

L'exploit du pont Wormhole est un rappel terrifiant de la manière dont un simple détail omis lors de l'implémentation peut entraîner l'échec d'une vérification cryptographique complexe. Wormhole permettait le transfert d'actifs entre Solana et Ethereum. Cela impliquait qu'un groupe de gardiens surveille un événement sur une chaîne et signe un message pour le prouver. Ces signatures étaient ensuite vérifiées par la chaîne de destination avant de frapper lesdits jetons sous forme de nouveaux actifs.

La faille résidait dans la vérification des signatures au sein du smart contract sur Solana. La vérification cryptographique était effectuée par un programme natif de Solana appelé par le contrat. Cependant, les développeurs de Wormhole n'ont pas vérifié si le programme appelé était bien le programme système officiel. Le hacker a également créé un programme qui renvoyait systématiquement un message de succès, quel que soit l'input fourni.

Ensuite, le contrat Wormhole a été instruit d'utiliser cette fausse application pour la validation. Les répercussions ont été considérables, nécessitant un renflouement de la part des soutiens du projet afin d'éviter un effondrement systémique de l'écosystème DeFi de Solana.

Une telle vulnérabilité pourrait se reproduire à l'avenir en raison des caractéristiques uniques du paradigme de développement des contrats intelligents, en particulier dans les environnements reposant fortement sur un modèle de comptes comme Solana, si les développeurs n'effectuent pas une validation et une vérification rigoureuses des comptes et des programmes pour chaque entité externe invoquée au sein de leurs contrats intelligents.

L'exploit du pont Nomad

Alors que Wormhole était une attaque coordonnée dans une direction spécifique, l'exploit du pont Nomad a prouvé à quel point il est facile pour une simple faille logique de plonger un protocole dans un chaos total, semblable à une foire d'empoigne généralisée. Pour mettre en œuvre cette messagerie inter-chaînes, Nomad utilisait un modèle de rollup optimiste s'appuyant sur un arbre de Merkle pour démontrer la validité des messages. Les développeurs ont commis une erreur cruciale lors de l'initialisation de la racine de confiance au moment du déploiement d'une mise à jour du protocole.

Cela s'est produit car ils ont défini la racine de confiance sur un hash zéro — la valeur par défaut d'une variable non initialisée dans Solidity. En conséquence, tout message qui n'était pas explicitement validé se voyait attribuer par défaut un hash zéro, lequel était désormais considéré comme une racine de confiance valide par le contrat. En substance, un hacker a réalisé qu'il pouvait créer une transaction demandant au contrat de retirer des fonds et, puisque la preuve correspondait au hash zéro, le contrat l'acceptait systématiquement.

Ce hack était unique en raison de sa simplicité et du chaos indescriptible qui s'ensuivit. Après que le premier hacker a réalisé l'exploit, d'autres utilisateurs lui ont emboîté le pas. Aucune compétence technique en piratage n'était requise ; il suffisait de copier et coller les informations de la transaction du hacker, de remplacer l'adresse de destination par la sienne et de soumettre le tout au réseau.

Des centaines d'acteurs différents ont drainé le pont Nomad de près de deux cents millions de dollars en l'espace de quelques heures.

C'était un cas d'école de faille de cybersécurité : une seule ligne de code d'initialisation mal configurée qui a contourné l'intégralité du système de sécurité cryptographique. Cela a été corrigé en rectifiant la logique d'initialisation de la racine zéro et en la rejetant explicitement en tant que racine valide. Les utilisateurs du pont en ont payé le prix, et ce fut un rappel brutal que lors du développement de contrats intelligents, un caractère manquant ou une valeur par défaut erronée peut effectivement mettre en péril un protocole entier.

Ce bug particulier est facile à éviter avec des tests rigoureux, pourtant la catégorie plus large des erreurs d'initialisation continue de sévir activement dans les systèmes.

Bugs de compilateur et manipulation de marché

L'un des types de piratage pur les plus terrifiants est celui où la faille ne réside pas dans le code du développeur, mais dans les outils utilisés pour le compiler. Nous en avons eu un rappel lors de l'exploit de Curve Finance qui a fait trembler les fondations de la DeFi. DEX de premier plan pour les stablecoins, une grande partie des contrats principaux de Curve ont été écrits en Vyper, un Le compilateur a traduit avec succès le code Vyper lisible par l'humain en un bytecode lisible par machine destiné à être implémenté sur l'Ethereum Virtual Machine, mais il n'a pas réussi à répartir correctement le verrou de réentrance sur plusieurs fonctions.

Le code était sécurisé, les développeurs l'avaient écrit exactement comme il se devait, mais le compilateur les a trahis en produisant un bytecode comportant des vulnérabilités. Cela signifie qu'un hacker black hat l'a remarqué et a compris que certains pools de liquidité de Curve étaient sensibles à la réentrance inter-fonctions. Ils en ont profité pour dérober des dizaines de millions de dollars dans les pools.

Ce piratage était particulièrement insidieux car il n'y aurait eu aucun moyen de le détecter par un audit de code source traditionnel ; le code source était correct. La vulnérabilité n'était présente que dans le bytecode compilé. Cet événement a contraint l'ensemble de l'industrie à reconsidérer sa confiance envers les compilateurs et l'infrastructure. Le problème a été résolu par une mise à jour du compilateur Vyper et par la migration des pools vulnérables vers de nouveaux contrats compilés de manière sécurisée.

Le résultat fut une crise de confiance majeure et la reconnaissance du fait que la sécurité doit s'étendre à l'ensemble de la pile technologique. Les bugs de compilateur sont rares, bien sûr, mais aussi presque impossibles à prévoir, de sorte qu'un tel cauchemar au niveau de l'infrastructure pourrait facilement se reproduire.

Les flash loans — une nouvelle catégorie d'instruments financiers apparue avec le développement de la finance décentralisée — ont fondamentalement transformé la nature même du piratage pur. Les flash loans permettent à un utilisateur d'emprunter une quantité quasi illimitée de cryptomonnaies sans collatéral, à condition que le prêt soit remboursé avant la fin de cette même transaction. Si les fonds ne sont pas réglés, l'intégralité de la transaction est annulée — comme si elle n'avait jamais eu lieu.

Les flash loans (prêts instantanés), généralement destinés à l'arbitrage ou aux liquidations, ont fourni aux hackers « black hat » la liquidité nécessaire pour exploiter des failles logiques profondes dans les mécanismes du marché. En prenant le hack d'Euler Finance comme étude de cas, Euler était un protocole de prêt permettant d'effectuer des dépôts et de générer des profits. Les utilisateurs pouvaient également faire don de leurs actifs déposés aux réserves du protocole, via une fonction nommée donateToReserves au sein du protocole.

Mais les développeurs ont omis une vérification de solvabilité (health check) cruciale dans cette fonction précise. Ils n'ont pas non plus vérifié si le compte à partir duquel le donateur retirait des fonds resterait à l'équilibre après le don. L'attaquant a emprunté une quantité importante d'actifs via un flash loan et les a déposés sur Euler. Ensuite, il a appelé la fonction donateToReserves pour donner une partie de son dépôt.

En l'absence de vérification de solvabilité, le protocole a approuvé le don, poussant le compte du hacker vers un état de faillite totalement artificiel. Le hacker a ensuite procédé à la liquidation de son propre compte. Cependant, les calculs mathématiques derrière les bonus de liquidation d'Euler sont complexes et le flash loan était colossal, si bien que le liquidateur a fini par extraire plus de valeur du protocole qu'il n'en déposait.

Il a remboursé le flash loan et s'est enfui avec environ deux cents millions de dollars. Il ne s'agissait pas d'une faille cryptographique ou d'un bug de compilateur, mais plutôt d'un simple défaut de logique financière dans le code. Dans ce cas précis, les développeurs ont simplement oublié d'insérer une seule ligne de code vérifiant la solvabilité du compte après une action donnée. Le correctif a consisté à intégrer la vérification de solvabilité appropriée et à remanier complètement la logique de gestion des risques du protocole.

Cela a eu de graves répercussions, entraînant l'interruption du protocole et nécessitant des mois de négociations pour récupérer une partie du capital." De tels exploits logiques, où des mécanismes financiers complexes interagissent de manière imprévue, représentent aujourd'hui la forme de piratage pur la plus répandue et la plus dangereuse. La complexité des protocoles va s'accroître, et ce type d'omission logique sera, selon toute vraisemblance, pratiquement certain de se reproduire.

Une lutte permanente entre le code et ses conséquences

Si l'on revient sur l'historique de ces brèches gigantesques, on discerne aisément une tendance récurrente. Ces vulnérabilités sont rarement le résultat d'une défaillance des mécanismes de consensus sous-jacents de la blockchain. Non, il s'agit de défaillances de la logique humaine inscrite dans un code immuable. Qu'il s'agisse d'une mise à jour d'état défaillante, d'un chemin de code non documenté pour un proxy, d'une vérification cryptographique omise, d'une erreur de compilateur ou de l'absence de vérification d'invariance financière, le problème de fond réside toujours, avant tout, dans une erreur de conception du smart contract.

Pour éliminer ces risques, l'industrie dispose d'un système de défense approfondi. Celui-ci comprend :

1. Des audits de code humains réalisés par des sociétés de sécurité indépendantes. 2. Des outils de vérification formelle qui prouvent mathématiquement que le code s'exécute exactement comme prévu. 3. Des programmes de « bug bounty » très importants qui rémunèrent les hackers « white hat » pour trouver des failles avant les acteurs malveillants. 4. L'utilisation de verrous temporels (timelocks) et de contrôles de clés d'administration multisignatures (multi-sig) pour ralentir le déploiement d'une mise à jour malveillante. 5. L'utilisation de protocoles d'assurance décentralisés pour fournir une couverture en cas de brèche.

Cependant, le piratage « black hat » persiste, même si ces mesures défensives sont devenues plus sophistiquées. Le postulat de départ du développement logiciel est que la complexité engendre des opportunités de défaillance.

La complexité croissante de la finance décentralisée, avec des développeurs concevant des protocoles complexes intégrant des dizaines d'autres contrats intelligents et fonctionnant sur plusieurs blockchains, crée de nouvelles voies d'attaque sans précédent.

Puisque les attaquants ne sont limités que par leur propre imagination, il leur suffit de trouver un seul vecteur fonctionnel pour réussir ; la défense est ainsi toujours en réaction et accuse perpétuellement un train de retard. Ce sera une lutte perpétuelle où les bâtisseurs de l'avenir décentralisé s'affrontent aux exploitants de failles. Les cauchemars de piratages généralisés continueront de muter comme un rappel constant : dans un monde où le code fait loi, une simple faute de frappe peut tout emporter.

Avec chaque ligne de code valant littéralement des centaines de milliers de dollars, l'efficacité et la précision des opérations quotidiennes sont tout aussi cruciales que la sécurité pour garantir le plus haut niveau de performance. Les utilisateurs sont régulièrement confrontés aux frictions liées aux frais de réseau lors de la gestion d'actifs numériques, en particulier les stablecoins. Désormais, chaque fois que vous envoyez de l'USDT, s'il s'agit d'une opération fréquente pour transférer du capital, vous savez que le coût de cette transaction USDT peut varier considérablement, au point d'entamer votre capital.

En tant que participant actif de l'écosystème, trouver une méthode de transfert économique pour l'USDT est crucial. C'est là que des outils spécifiques vous procurent des avantages. Le service netts : USDT Transfer Calculator a été créé précisément pour optimiser ces usages.

Lorsque vous transférez du Tether sur le réseau TRON, cela consomme de l'Énergie et de la Bande passante. Si vous n'en disposez pas, le réseau brûlera vos TRX en fonction des frais USDT.

L'estimateur Netts, qui calcule à l'avance l'Énergie et la Bande passante exactes nécessaires, permet aux utilisateurs de réaliser des économies massives en louant de l'énergie au lieu de brûler des TRX, garantissant une gestion de vos actifs aussi efficace que possible dans un monde où chaque fraction de jeton compte.