Une attaque par réentrance est une vulnérabilité des contrats intelligents où un contrat malveillant exploite un appel de fonction externe pour réintégrer le contrat appelant avant la fin de son exécution initiale, permettant ainsi à l'attaquant de vider les fonds ou de manipuler les variables d'état de manière répétée. Cette attaque se produit lorsqu'un contrat envoie de l'Ether ou des jetons à une adresse externe, généralement via une méthode de bas niveau. call Cette méthode, avant de mettre à jour son propre état interne, crée une fenêtre pendant laquelle la fonction de repli ou de réception du destinataire peut appeler récursivement le contrat vulnérable.
Le mécanisme classique fonctionne comme suit : un contrat victime gère un solde et une fonction de retrait. Lorsqu'un utilisateur appelle cette fonction, le contrat envoie de l'Ether à l'adresse de l'appelant avant de remettre son solde à zéro. Si l'appelant est un contrat malveillant doté d'une fonction de repli qui appelle immédiatement à nouveau la fonction de retrait, le solde du contrat victime affiche toujours le montant initial, car la mise à jour de l'état n'a pas encore eu lieu. Cette réentrée récursive continue de drainer les fonds jusqu'à épuisement du solde d'Ether du contrat victime ou jusqu'à ce que la limite de la pile d'appels soit atteinte.
Les attaques par réentrance exploitent une propriété fondamentale de la machine virtuelle Ethereum (EVM) : les appels externes transfèrent le contrôle d'exécution à l'appelé avant même l'exécution des instructions suivantes de l'appelant. Cette caractéristique fait de la réentrance l'une des vulnérabilités les plus dangereuses et les plus étudiées dans le développement des contrats intelligents. Ce type d'attaque est responsable de certaines des plus importantes pertes financières de l'histoire de la finance décentralisée, notamment le piratage tristement célèbre de la DAO en 2016, qui a entraîné des pertes d'environ 60 millions de dollars et a finalement conduit au hard fork d'Ethereum, donnant naissance à Ethereum Classic.
Les variantes modernes de réentrance s'étendent au-delà du simple modèle à fonction unique pour inclure la réentrance inter-fonctions (où le rappel réentre dans une fonction différente qui lit l'état obsolète), la réentrance inter-contrats (où le rappel cible un contrat différent qui partage un état avec le contrat vulnérable) et la réentrance en lecture seule (où le rappel exploite un état obsolète dans des fonctions de vue utilisées par d'autres protocoles pour les calculs de tarification ou de garanties).
Origine & Histoire
2015 : Ethereum a été lancé avec Solidity comme langage principal pour ses contrats intelligents. La conception de la machine virtuelle Ethereum (EVM), où les appels externes transfèrent le contrôle d'exécution et permettent l'exécution de code arbitraire par le destinataire, a créé les conditions propices aux vulnérabilités de réentrance. La documentation initiale de Solidity n'a pas suffisamment mis en garde contre les risques liés aux appels externes effectués avant les mises à jour d'état.
2016 juin : La DAO, une organisation autonome décentralisée qui avait levé environ 150 millions de dollars en ETH grâce à une vente de jetons, a été exploitée via une vulnérabilité de réentrance dans son système. splitDAO Une fonction a été déployée par un attaquant. Ce dernier a utilisé un contrat malveillant doté d'une fonction de repli spécialement conçue, qui appelait une autre fonction de The DAO. splitDAO Cette fonction a fonctionné de manière récursive, entraînant le retrait d'environ 3.6 millions d'ETH (soit environ 60 millions de dollars à l'époque). Il s'agit à ce jour de l'attaque par réentrance la plus lourde de conséquences de l'histoire de la blockchain.
Juillet 2016 : La communauté Ethereum a traversé une crise de gouvernance concernant l’opportunité d’un hard fork de la blockchain pour annuler le piratage de la DAO. Cet événement a mis à rude épreuve le principe « le code fait loi », fondement même de la DAO. La majorité de la communauté, soutenue par Vitalik Buterin, a opté pour une interprétation conditionnelle de ce principe, procédant à un hard fork au bloc 1 920 000 afin de récupérer les fonds. Les opposants, affirmant que le principe « le code fait loi » doit être absolu et immuable, ont maintenu la chaîne originale sous le nom d’Ethereum Classic (ETC).
2017-2018: Le piratage de la DAO a catalysé une approche axée sur la sécurité dans le développement des contrats intelligents. OpenZeppelin a publié son ReentrancyGuard Ce contrat offre une protection standardisée contre la réentrance, basée sur un mutex. Des outils de vérification formelle et des sociétés d'audit de sécurité comme Trail of Bits et ConsenSys Diligence ont émergé pour répondre au besoin croissant de sécurité des contrats intelligents.
2020 : L’explosion estivale de la DeFi a injecté des milliards de dollars dans les contrats intelligents , augmentant considérablement les risques de réentrance. La composabilité des protocoles DeFi (« briques financières ») a introduit des risques de réentrance inter-contrats plus difficiles à détecter et à auditer que les vulnérabilités propres à un seul contrat.
Avril 2020 : L’incident Uniswap/Lendf.me a entraîné la fuite d’environ 25 millions de dollars sur les deux plateformes suite à une attaque par réentrance exploitant les mécanismes de rappel des jetons ERC-777. Lendf.me (protocole de prêt de dForce) a été responsable de la grande majorité des pertes, soit environ 24.5 millions de dollars. Cet incident a démontré que la réentrance ne se limitait pas aux transferts d’ETH bruts, mais pouvait également être déclenchée par les mécanismes de rappel des standards de jetons.
Juillet 2023 : Curve Finance a subi une attaque de réentrance dévastatrice en raison d’un bug du compilateur Vyper (versions 0.2.15, 0.2.16 et 0.3.0) provoquant un dysfonctionnement du verrou de réentrance. Plusieurs pools Curve ont été vidées pour un montant d’environ 70 millions de dollars, démontrant ainsi que les défenses contre la réentrance pouvaient être compromises au niveau du compilateur, et pas seulement au niveau de la logique contractuelle.
2024-2026 : La réentrance en lecture seule est apparue comme une nouvelle source de préoccupation, notamment pour les protocoles qui s’appuient sur les fonctions de consultation d’autres contrats pour la tarification. Les risques de réentrance inter-chaînes se sont également matérialisés avec l’apparition de nouvelles surfaces d’attaque créées par les protocoles de pont et les architectures DeFi multi-chaînes, où les incohérences d’état entre les chaînes pouvaient être exploitées.
« Le piratage de la DAO a été le moment où la communauté Ethereum a compris que le code est loi, mais que la loi peut comporter des erreurs. Cela a fondamentalement changé notre façon de concevoir la sécurité des contrats intelligents, et ce, pour toujours. »
En termes simples
Imaginez un guichetier qui vérifie le solde de votre compte, vous remet de l'argent, puis met à jour le registre pour enregistrer le retrait. Une attaque par réentrance consiste à retourner voir ce même guichetier avant la mise à jour du registre et à demander un autre retrait. Le guichetier voit toujours votre solde initial et vous remet de l'argent. Vous continuez ainsi jusqu'à ce que le coffre soit vide.
Imaginez un distributeur automatique qui vous sert une boisson, puis débite votre carte prépayée. Si vous pouviez appuyer à nouveau sur le bouton dès que la boisson commence à sortir, mais avant que votre carte ne soit débitée, vous obtiendriez plusieurs boissons pour le prix d'une. L'attaque par réentrance exploite cet écart entre « donner la boisson » et « enregistrer que j'ai donné la boisson ».
Imaginez une porte tambour dans un hôtel. Normalement, vous la franchissez, le portier enregistre votre entrée et vous entrez. Lors d'une attaque par réentrée, vous entrez dans la porte tambour et, avant même que le portier ait pu enregistrer votre entrée, vous faites demi-tour et entrez à nouveau, encore et encore, apparaissant à chaque fois comme un « nouveau » visiteur, car le portier n'a jamais eu le temps de mettre à jour sa liste.
C'est comme à la caisse d'un magasin : le caissier vous tend vos courses avant de les scanner. Si vous pouviez retourner instantanément en tête de file avec le même chariot, le caissier continuerait à vous donner d'autres articles, car la caisse enregistreuse affiche toujours le montant total. Finalement, le magasin se retrouve en rupture de stock.
Important : Les attaques par réentrance ciblent le code du contrat lui-même, et non le mécanisme de consensus de la blockchain. La blockchain enregistre fidèlement chaque transaction, y compris les malveillantes. C’est pourquoi la prévention doit être mise en œuvre dès le développement du contrat intelligent, grâce à des modèles de codage sécurisés, des audits et une vérification formelle. La blockchain ne peut pas distinguer un retrait légitime d’une exploitation de réentrance.
Caractéristiques techniques clés
Le mécanisme de réentrance en détail
L'attaquant déploie un contrat malveillant doté d'une fonction de repli (ou de réception) spécialement conçue.
L'attaquant appelle la fonction de retrait du contrat vulnérable depuis le contrat malveillant.
Le contrat vulnérable vérifie le solde de l'attaquant. Il est validé car l'attaquant a déposé des fonds.
Le contrat vulnérable envoie des ETH à l'adresse du contrat de l'attaquant en utilisant une technique de bas niveau. call avec valeur
Avant que l'exécution ne reprenne à la ligne suivante du contrat vulnérable (la mise à jour du solde), l'EVM transfère le contrôle au contrat de l'attaquant.
La fonction de repli de l'attaquant s'exécute automatiquement dès réception d'ETH et appelle immédiatement à nouveau la fonction de retrait.
Le contrat vulnérable réexécute la fonction de retrait. Comme le solde n'a pas été mis à jour, le contrôle est à nouveau validé.
Les étapes 4 à 7 se répètent de manière récursive jusqu'à ce que le solde ETH du contrat soit épuisé ou que la limite de gaz soit atteinte.
Ce n'est qu'après l'exécution du dernier appel récursif que la pile d'appels se déroule et que la mise à jour du solde du premier appel est enfin exécutée. Mais les fonds ont déjà disparu.
Le modèle de vérifications-effets-interactions
Vérifications: Valider toutes les conditions et exigences (par exemple, require(balances[msg.sender] >= amount))
Effets: Mettre à jour toutes les variables d'état internes (par exemple, balances[msg.sender] -= amount)
Interactions Effectuer des appels externes (par exemple, msg.sender.call{value: amount}("")) seulement après tous les changements d'état
Cet ordre garantit que même si un appel réentrant survient pendant l'étape d'interaction, l'état a déjà été mis à jour et les vérifications de solde suivantes échoueront. Ce modèle constitue la protection la plus efficace contre la réentrance et est préconisé par tous les principaux guides de style Solidity et cabinets d'audit.
OpenZeppelin ReentrancyGuard
Fournit un nonReentrant modificateur qui utilise une variable mutex (exclusion mutuelle) pour empêcher la réentrée
Le modificateur verrouille l'état avant l'exécution de la fonction et le réinitialise après son exécution.
Si un appel réentrant tente d'exécuter la fonction protégée alors que le verrou est actif, la transaction est annulée.
L'implémentation utilise une variable d'état de type uint256 (1 = non saisi, 2 = saisi) plutôt qu'un booléen pour l'optimisation du gaz.
Largement adopté dans la finance décentralisée (DeFi) : Aave, Compound, Uniswap V3 et des centaines d’autres protocoles utilisent ReentrancyGuard ou des modèles équivalents.
Variantes de réentrance
Réentrance monofonctionnelle : L'attaque classique où la fonction de repli appelle la même fonction vulnérable. C'était le modèle de piratage DAO.
Réentrance interfonctionnelle : La fonction de repli appelle une autre fonction du même contrat qui lit la variable d'état obsolète, permettant ainsi une exploitation via un chemin secondaire.
Réentrée par contrat croisé : La fonction de rappel cible un autre contrat partageant des relations d'état ou de confiance avec le contrat vulnérable, exploitant ainsi la composabilité dans la finance décentralisée (DeFi).
Réentance en lecture seule : La fonction de rappel appelle une fonction de vue qui renvoie un état obsolète, lequel est ensuite utilisé par un protocole tiers pour la tarification, l'évaluation des garanties ou les flux d'oracle. Aucun détournement de fonds direct n'a lieu, mais l'exploitation indirecte est possible.
Réentrance ERC-777 : La norme de jeton ERC-777 inclut des points d'entrée de rappel (tokensReceived) qui exécutent du code sur le destinataire, créant des vecteurs de réentrance dans les protocoles qui gèrent les jetons ERC-777 sans protection
Outils de détection et de prévention
Analyse statique : Des outils comme Slither (de Trail of Bits) détectent automatiquement les schémas de réentrance dans le code Solidity grâce à l'analyse du flux de contrôle.
Vérification formelle : Des outils comme Certora Prover vérifient mathématiquement qu'une réentrance est impossible compte tenu des spécifications d'un contrat.
Flou : Echidna et Foundry utilisent Forge pour tester des contrats avec des entrées aléatoires afin de découvrir la réentrance et d'autres vulnérabilités.
Audit de sécurité : Les cabinets d'audit professionnels (Trail of Bits, OpenZeppelin, Consensys Diligence, Halborn) examinent manuellement le code des contrats afin de détecter les réentrances et autres vulnérabilités.
Primes aux bogues : Des plateformes comme Immunefi incitent les hackers éthiques à découvrir les vulnérabilités de réentrance avant que des acteurs malveillants ne les exploitent.
Avantages désavantages
Avantages (de la compréhension de la réentrance)
Inconvénients (Risques de récidive)
Sensibilisation à la sécurité: Comprendre la réentance est fondamental pour écrire des contrats intelligents sécurisés. C'est la première vulnérabilité abordée dans tous les cours de sécurité Solidity.
Perte financière catastrophique : Une seule faille de réentrance peut vider les fonds de l'ensemble d'un protocole en une seule transaction, comme l'ont démontré le piratage de DAO (60 millions de dollars) et l'exploitation de Curve (70 millions de dollars).
Défenses établies : Des modèles d'atténuation bien documentés (vérifications, effets, interactions, ReentrancyGuard) permettent d'éviter la réentrance lorsque les développeurs suivent les bonnes pratiques.
Évolution des vecteurs d'attaque : De nouvelles variantes, comme la réentrance en lecture seule et la réentrance inter-contrats, continuent d'émerger, devançant la sensibilisation des développeurs et les outils de détection existants.
Écosystème d'outils : Un écosystème robuste d'analyseurs statiques, de fuzzers et d'outils de vérification formelle permet de détecter automatiquement la plupart des schémas de réentrance avant le déploiement.
Risques au niveau du compilateur : L'exploit de Curve Finance en 2023 a démontré que les défenses contre la réentrance peuvent échouer en raison de bogues dans le compilateur lui-même, créant ainsi une couche de risque hors du contrôle du développeur.
Croissance du secteur de l'audit : La prévalence de la réentrance a stimulé la croissance d'un secteur professionnel d'audit des contrats intelligents, améliorant ainsi la sécurité globale de l'écosystème.
Amplification de la composabilité : L'architecture modulaire « Lego monétaire » de la DeFi signifie qu'une vulnérabilité de réentrance dans un protocole peut se propager en cascade à travers plusieurs protocoles interconnectés.
Partage des connaissances communautaires : Les exploits de réentrance très médiatisés ont généré de nombreuses analyses post-mortem, des ressources pédagogiques open source et des améliorations de sécurité à l'échelle de l'industrie.
Faux sentiment de sécurité : Les développeurs qui appliquent ReentrancyGuard à certaines fonctions peuvent manquer des chemins de réentrance inter-fonctions ou inter-contrats, créant ainsi une protection incomplète.
Incitations liées aux primes aux bogues : La gravité du phénomène de réentrance a incité les protocoles à offrir des primes substantielles pour la découverte de bogues (souvent plus d'un million de dollars), encourageant ainsi la découverte par des hackers éthiques plutôt que l'exploitation par des hackers malveillants.
Gaz en hauteur : Les mécanismes de protection contre la réentrance ajoutent des frais de gaz à chaque appel de fonction protégée, ce qui s'accumule lors des opérations DeFi à haute fréquence et peut impacter la compétitivité du protocole.
Leçons de gouvernance : Le piratage de la DAO a enseigné à la communauté blockchain des leçons cruciales concernant la gouvernance, l'immuabilité et le rôle de la couche sociale dans la réponse aux défaillances au niveau du code.
Irréversibilité des exploits : Contrairement à la finance traditionnelle où les transactions frauduleuses peuvent être annulées, les failles de réentrance sur les blockchains immuables sont permanentes, sauf si la communauté accepte une bifurcation dure controversée.
Gestion du risque
Pratiques de développement des contrats intelligents
Suivez toujours le modèle vérifications-effets-interactions : mettez à jour toutes les variables d’état avant d’effectuer des appels externes.
Appliquer OpenZeppelin nonReentrant modificateur à ajouter à chaque fonction qui effectue des appels externes ou transfère des valeurs
Évitez d'utiliser transfer() et send() Pour les transferts d'ETH dans les nouveaux contrats. Bien que ces contrats limitent les frais de gaz à 2 300 (empêchant ainsi certaines réentrances), ils peuvent dysfonctionner en cas de modifications de l'EIP et de réévaluation du prix du gaz.
Utilisez le modèle de paiement « pull-over-push » : au lieu d’envoyer des fonds directement, permettez aux utilisateurs de retirer eux-mêmes leurs fonds, réduisant ainsi la surface d’attaque.
Protocoles d'audit et de test
Exiger au moins deux audits de sécurité indépendants réalisés par des entreprises réputées avant de déployer des contrats portant sur des sommes importantes.
Exécutez une analyse statique avec Slither et Mythril sur chaque contrat avant déploiement. Ces outils détectent automatiquement les schémas de réentrance les plus courants.
Mettez en œuvre des suites de tests de fuzzing détaillées à l'aide d'Echidna ou de Foundry, ciblant spécifiquement les scénarios de réentrance.
Effectuez une analyse de réentrance inter-contrats lors de l'intégration avec des protocoles externes, en particulier ceux utilisant des normes de jetons à forte composante de rappel comme ERC-777.
Sécurité opérationnelle
Déployez les contrats derrière des modèles de proxy évolutifs ou avec des mécanismes de pause d'urgence capables d'interrompre les retraits en cas de détection de réentrance.
Surveillez l'activité sur la blockchain pour détecter les schémas de retrait inhabituels (par exemple, des appels récursifs rapides à la même fonction au sein d'une même transaction) à l'aide d'outils comme Forta ou OpenZeppelin Defender.
Mettre en place des procédures de réponse aux incidents, notamment la suspension des contrats, des canaux de communication et des stratégies de recouvrement des fonds.
Maintenir des programmes de primes aux bogues avec des paiements proportionnels à la valeur totale bloquée (TVL) dans le protocole
Risque d'intégration de la DeFi
Lors de la composition avec des protocoles externes, vérifiez les protections contre la réentrance du contrat externe avant l'intégration.
Ne présumez pas que les fonctions de vue externes renvoient un état cohérent lors de l'exécution du rappel. Il s'agit du vecteur de réentrance en lecture seule.
Mettez en œuvre des mécanismes de protection contre la réentrance au niveau des limites du protocole, et non seulement au niveau de chaque fonction, afin d'empêcher les chaînes de réentrance inter-contrats.
Pertinence culturelle
L'attaque par réentrance occupe une place unique dans la culture blockchain : elle a brisé la philosophie naïve du « code est loi » et contraint la communauté Ethereum à affronter la tension entre immuabilité et pragmatisme. Le piratage de la DAO en 2016 n'était pas qu'une simple exploitation technique. Il a constitué un moment existentiel pour Ethereum, divisant la communauté en deux camps philosophiques, dont l'un a donné naissance à Ethereum Classic.
« La DAO était censée prouver que la gouvernance décentralisée pouvait fonctionner. Au lieu de cela, elle a prouvé qu'écrire du code sécurisé est plus difficile que quiconque ne l'imaginait. »
Dans le monde du développement, la réentrance est devenue un passage obligé. Tout développeur Solidity commence par l'étude du hack DAO, et « avez-vous vérifié la réentrance ? » est la question la plus fréquemment posée lors des revues de code de contrats intelligents. Les défis Damn Vulnerable DeFi et Ethernaut (capture de drapeau) intègrent tous deux la gestion de la réentrance comme exercices fondamentaux.
L'attaque de Curve Finance en juillet 2023 a relancé le débat culturel autour de la réentrance, cette fois-ci centré sur la possibilité que des failles au niveau du compilateur puissent compromettre des mécanismes de défense pourtant correctement implémentés par les développeurs. La faille du compilateur Vyper qui désactivait les verrous de réentrance a démontré que la sécurité dans le développement de contrats intelligents exige une confiance non seulement dans son propre code, mais aussi dans l'ensemble de la chaîne d'outils. Cette leçon a trouvé un écho profond au sein de la communauté blockchain, qui prône une confiance minimale.
Sur Twitter et les forums DeFi dédiés aux cryptomonnaies, les failles de réentrance sont analysées en temps réel avec la même intensité que les événements d'actualité les plus marquants. Les hackers éthiques qui découvrent et divulguent de manière responsable ces vulnérabilités sont salués comme des héros de la communauté, tandis que les analyses post-mortem de ces exploits deviennent parmi les contenus techniques les plus partagés de l'écosystème. Le terme « réentrance » a dépassé sa définition technique pour devenir un raccourci culturel désignant la tension permanente entre la rapidité d'innovation et la rigueur de la sécurité dans la finance décentralisée.
Exemples du monde réel
Le piratage de la DAO (juin 2016)
Scénario: La DAO, un fonds de capital-risque décentralisé, détenait environ 150 millions de dollars en ETH, apportés par des milliers d'investisseurs. splitDAO Cette fonction permettait aux investisseurs de retirer leur part proportionnelle des fonds dans une « DAO enfant ».
Mise en œuvre: Un attaquant a déployé un contrat externe malveillant avec une fonction de repli conçue pour appeler de manière récursive le système de la DAO. splitDAO Cette fonction a envoyé des ETH au contrat de l'attaquant avant de mettre à jour le solde interne. Comme ce solde n'a jamais été remis à zéro entre les appels récursifs, l'attaquant a pu continuer à détourner des fonds pendant plusieurs heures, obtenant ainsi environ 3.6 millions d'ETH (environ 60 millions de dollars).
Résultat : La communauté Ethereum a procédé à un hard fork au bloc 1 920 000 afin de restituer les fonds volés, créant ainsi la séparation entre Ethereum (ETH) et Ethereum Classic (ETC). Cet événement a fait de la réentrance la vulnérabilité la plus tristement célèbre de l’histoire des contrats intelligents et a donné un nouvel élan à l’ensemble du secteur de la sécurité des contrats intelligents.
Exploitation de la faille Vyper chez Curve Finance (30 juillet 2023)
Scénario: Plusieurs pools de liquidités Curve Finance (alETH/ETH, msETH/ETH, pETH/ETH et CRV/ETH) ont été créées à l'aide de contrats intelligents Vyper qui incluaient @nonreentrant décorateurs, l'équivalent Vyper de ReentrancyGuard de Solidity.
Mise en œuvre: Un bug dans les versions 0.2.15, 0.2.16 et 0.3.0 du compilateur Vyper a provoqué le @nonreentrant Un verrou a été compilé incorrectement, désactivant ainsi la protection contre la réentrance à l'exécution, bien qu'il apparaisse correctement dans le code source. Des attaquants ont exploité cette faille pour réintégrer les fonctions du pool lors du retrait de liquidités, manipulant les prix et vidant les fonds. L'exploit ciblait le remove_liquidity fonction qui envoyait des jetons à l'appelant avant de mettre à jour complètement l'état du pool.
Résultat : Environ 70 millions de dollars ont été détournés sur plusieurs plateformes. Plusieurs hackers éthiques et bots MEV ont mené certaines attaques, récupérant une partie des fonds. Cet incident a mis en lumière le risque critique que représentent les failles de sécurité au niveau du compilateur, susceptibles de compromettre les mesures de sécurité applicatives, et a conduit à un audit approfondi du compilateur Vyper.
Attaque ERC-777 Uniswap/Lendf.me (avril 2020)
Scénario: Le protocole Lendf.me de dForce, une plateforme de prêt, prenait en charge imBTC, un jeton ERC-777 doté de fonctions de rappel intégrées. Lorsqu'un utilisateur recevait des jetons imBTC, le jeton ERC-777 tokensReceived Un hook a exécuté du code sur le contrat du destinataire. Uniswap a également été ciblé par une attaque similaire, les pertes combinées sur les deux plateformes atteignant environ 25 millions de dollars, la grande majorité provenant de Lendf.me.
Mise en œuvre: L'attaquant a exploité la tokensReceived Lors de l'exécution de la fonction d'approvisionnement, une erreur s'est produite : lorsque Lendf.me a envoyé des imBTC au contrat de l'attaquant dans le cadre d'une opération d'approvisionnement/emprunt, la fonction de rappel a réactivé la fonction d'approvisionnement de Lendf.me, gonflant artificiellement le solde de garantie de l'attaquant. Grâce à cette garantie artificiellement gonflée, l'attaquant a emprunté la totalité des actifs disponibles sur le protocole.
Résultat : Environ 24.5 millions de dollars ont été dérobés sur Lendf.me, ainsi que des pertes moindres sur Uniswap. L’attaquant a finalement restitué les fonds après avoir été partiellement identifié. Cet incident a mis en lumière les risques de réentrance liés aux rappels de jetons ERC-777 et a incité de nombreux protocoles DeFi à interdire explicitement les standards de jetons compatibles avec les rappels ou à renforcer leurs protections.
Rari Capital / Exploit du protocole Fei (avril 2022)
Scénario : Les pools de prêt Fuse de Rari Capital permettaient aux utilisateurs de fournir et d’emprunter divers jetons. Plusieurs pools Fuse acceptaient des jetons dotés de mécanismes de rappel autorisant la réentrance lors des emprunts.
Mise en œuvre: L'attaquant a exploité une vulnérabilité de réentrance dans le borrow L'attaquant a exploité l'interaction de la fonction avec les jetons compatibles avec les rappels. En se réinsérant pendant le rappel d'emprunt, il a manipulé la comptabilité du pool pour emprunter plus que ne le permettait sa garantie, et a répété l'opération sur plusieurs pools Fuse.
Résultat : Environ 80 millions de dollars ont été dérobés sur plusieurs pools Fuse. Rari Capital et Fei Protocol, qui avaient récemment fusionné, n’ont pas pu récupérer les fonds, ce qui a finalement conduit à la fermeture du protocole. Cette faille a mis en évidence les risques de réentrance dans les protocoles de prêt composables avec une liste blanche de jetons permissive.
Tableau de comparaison
Fonctionnalité
Attaque de réentrée
Attaque de prêt éclair
Attaque par manipulation d'oracle
Vecteur d'attaque
Appels externes récursifs avant les mises à jour d'état
Prêts non garantis exploitant la logique du protocole au sein d'une seule transaction
Fournir de fausses données de prix aux contrats intelligents via des oracles manipulés ou obsolètes
Cause première
Violation du modèle de contrôles-effets-interactions
Logique de protocole qui suppose que les emprunteurs disposent de capitaux réels à risque
Dépendance à l'égard de flux de prix provenant d'une source unique ou facilement manipulables
Capital requis
Minimale (juste suffisante pour déclencher le premier retrait)
Zéro (les prêts flash sont, par définition, sans garantie)
Variable (de zéro pour les prêts éclair à significative pour la manipulation directe du marché)
Défense primaire
ReentrancyGuard, vérifie les effets et les interactions, analyse les modèles de paiement
TWAP multibloc, périodes de blocage minimales, séparation entre emprunt et offre
Oracles décentralisés (Chainlink), TWAP, flux de prix multi-sources, disjoncteurs
Dommages historiques
60 millions de dollars (DAO, 2016), 70 millions de dollars (Curve, 2023), 80 millions de dollars (Rari, 2022)
Plus de 130 millions de dollars (Cream Finance, 2021), 182 millions de dollars (Beanstalk, 2022)
Plus de 100 millions de dollars (Mango Markets, 2022), 130 millions de dollars (Cream Finance, 2021)
Difficulté de détection
Niveau modéré : les outils d’analyse statique détectent la plupart des modèles, mais les variantes inter-contrats et en lecture seule sont plus difficiles.
Niveau élevé : nécessite la compréhension d’une logique transactionnelle complexe à plusieurs étapes.
Niveau élevé : distinguer la manipulation d'une activité de marché légitime est intrinsèquement difficile.
Impact de la blockchain
A provoqué le hard fork d'Ethereum (séparation ETH/ETC)
A stimulé l'innovation dans la protection des véhicules électriques et la gestion des transactions
A conduit à une adoption généralisée de Chainlink et des normes d'oracle TWAP
Termes connexes
Contrat intelligent: Des programmes auto-exécutables déployés sur une blockchain appliquent automatiquement les termes d'un accord. La réentrance exploite les vulnérabilités ciblées dans la logique des contrats intelligents.
Le DAO: Une organisation autonome décentralisée sur Ethereum qui a subi la plus célèbre attaque de réentrance en 2016, conduisant au hard fork ETH/ETC.
Fonction de secours: Une fonction Solidity spéciale qui s'exécute lorsqu'un contrat reçoit de l'ETH ou un appel de fonction non reconnu. Ce mécanisme déclenche les rappels de réentrance.
Modèle Contrôles-Effets-Interactions : Un modèle de codage sécurisé qui impose d'effectuer toutes les mises à jour d'état avant les appels externes, empêchant ainsi la réentrance par conception.
OpenZeppelin : La principale bibliothèque de contrats intelligents open source fournissant des primitives de sécurité éprouvées, notamment ReentrancyGuard, utilisée par la plupart des principaux protocoles DeFi.
Prêt Flash: Un prêt non garanti qui doit être contracté et remboursé en une seule transaction. Souvent combiné à la réentrance ou à d'autres techniques d'exploitation pour un impact maximal.
Ethereum Classique (ETC): Il s'agit de la continuation de la chaîne Ethereum originale qui a refusé de se diviser après le piratage de la DAO, préservant ainsi la chaîne où l'exploit de réentrance est resté non corrigé.
Vérification formelle : Preuve mathématique qu'un contrat intelligent se comporte conformément à ses spécifications. Permet de prouver définitivement l'absence de vulnérabilités de réentrance.
ERC-777 : Une norme de jeton avancée avec des mécanismes de rappel intégrés qui a introduit de nouvelles surfaces d'attaque de réentrance dans les protocoles DeFi.
Mutex (Exclusion mutuelle) : Un mécanisme de contrôle de concurrence adapté aux contrats intelligents sous la forme de gardes de réentrance qui empêchent l'exécution simultanée de fonctions protégées.
Vyper : Un langage de contrats intelligents similaire à Python pour l'EVM. Un bug du compilateur Vyper a provoqué l'exploit de réentrance de Curve Finance en 2023, malgré des protections applicatives correctes.
MEV (valeur maximale extractible): La valeur que les producteurs de blocs peuvent extraire en réorganisant les transactions. Les bots MEV exploitent parfois les failles de réentrance pour capturer ou restituer les fonds volés.
QFP
Q : Qu'est-ce qu'une attaque par réentrance, en termes simples ?
Une attaque par réentrance se produit lorsqu'un contrat intelligent envoie de l'argent à une adresse externe avant d'enregistrer l'envoi. Le destinataire peut être un contrat malveillant qui demande immédiatement un montant supplémentaire. Comme l'enregistrement n'a pas encore été mis à jour, le contrat vulnérable croit que l'attaquant détient toujours son solde initial. Ce processus se répète indéfiniment, vidant ainsi les fonds du contrat.
Q : Comment s'est déroulé le piratage de la DAO, et pourquoi était-il si important ?
La DAO était un fonds d'investissement de 150 millions de dollars sur Ethereum. splitDAO La fonction de retrait envoyait des ETH aux utilisateurs avant de remettre leur solde à zéro. Un attaquant a déployé un contrat malveillant dont la fonction de repli appelait une autre fonction. splitDAO À chaque réception d'ETH, le système drainait environ 60 millions de dollars. Ce piratage était si important que la communauté Ethereum a procédé à un hard fork de la blockchain pour l'annuler, scindant ainsi Ethereum en ETH et Ethereum Classic – un moment décisif dans l'histoire de la gouvernance des blockchains.
Q : Les attaques par réentrance peuvent-elles se produire sur des blockchains autres qu'Ethereum ?
Oui. La réentrance est possible sur toute blockchain prenant en charge les contrats intelligents avec appels externes transférant le contrôle d'exécution. Cela inclut les chaînes compatibles EVM comme BNB Chain, Polygon, Avalanche et Arbitrum. Les chaînes non-EVM comme Solana possèdent des modèles d'exécution différents qui rendent la réentrance traditionnelle plus difficile, mais pas impossible. Le runtime de Solana empêche les appels CPI (invocations inter-programmes) récursifs au même programme au sein d'une même instruction, mais des schémas similaires à la réentrance inter-programmes peuvent néanmoins se produire.
Q : Qu’est-ce que le modèle de vérifications-effets-interactions, et comment empêche-t-il la réentrance ?
Le modèle de programmation « vérifications-effets-interactions » (Vérifications-Effets-Interactions) exige trois étapes dans un ordre strict : premièrement, vérifier toutes les conditions (par exemple, le solde de l’utilisateur est-il suffisant ?) ; deuxièmement, mettre à jour toutes les variables d’état (par exemple, ramener le solde de l’utilisateur à zéro) ; troisièmement, interagir avec les contrats externes (par exemple, envoyer de l’ETH). En mettant à jour l’état avant l’appel externe, tout rappel réentrant rencontrera l’état déjà mis à jour et échouera à sa vérification, empêchant ainsi l’exploitation de la faille.
Q : Qu’est-ce que la réentrance en lecture seule, et pourquoi est-elle dangereuse ?
La réentrance en lecture seule se produit lorsqu'un rappel lors d'un appel externe permet à un attaquant de lire des données obsolètes provenant des fonctions de vue. Même si aucun fonds n'est directement débité du contrat vulnérable, les autres protocoles qui dépendent de ces fonctions de vue pour la tarification, le calcul des garanties ou les données d'oracle recevront des valeurs incorrectes. Cette vulnérabilité peut être exploitée pour obtenir des prêts insuffisamment garantis ou manipuler les prix dans les protocoles DeFi connectés, ce qui en fait un vecteur d'attaque subtil mais potentiellement dévastateur.
Q : Comment l'exploit de Curve Finance en 2023 a-t-il pu se produire malgré la présence de mécanismes de protection contre la réentrance ?
Les pools de Curve Finance étaient écrites en Vyper et utilisaient correctement le @nonreentrant Un décorateur permet d'empêcher la réentrance. Cependant, un bug dans les versions 0.2.15, 0.2.16 et 0.3.0 du compilateur Vyper entraînait une compilation incorrecte du verrou de réentrance : celui-ci n'était jamais activé lors de l'exécution, bien qu'il apparaisse correctement dans le code source. Autrement dit, la protection contre la réentrance existait théoriquement, mais était silencieusement supprimée à la compilation. Cette faille a démontré que la sécurité des contrats intelligents dépend non seulement de la correction du code applicatif, mais aussi de la fiabilité de l'ensemble de la chaîne d'outils, y compris le compilateur.
Q : Quels outils les développeurs peuvent-ils utiliser pour détecter les vulnérabilités de réentrance avant le déploiement ?
Les développeurs devraient adopter une approche multicouche : (1) des outils d’analyse statique comme Slither et Mythril qui analysent automatiquement le code à la recherche de réentrances, (2) des tests de robustesse avec Echidna ou Foundry Forge qui testent les contrats avec des entrées aléatoires, (3) une vérification formelle avec des outils comme Certora Prover qui prouvent mathématiquement l’absence de réentrance, et (4) des audits de sécurité professionnels réalisés par des entreprises comme Trail of Bits, OpenZeppelin ou Halborn. Aucun outil ne détecte à lui seul toutes les variantes ; une stratégie de défense en profondeur est donc essentielle.
