Qu'est-ce qu'une «attaque de réentrance»?

Comprendre les attaques de renforcement dans la blockchain

1. Une attaque de renforcement est une vulnérabilité de sécurité essentielle qui se produit dans les contrats intelligents, en particulier sur la blockchain Ethereum. Il exploite la façon dont les appels externes sont traités lors de l'exécution du contrat, permettant un contrat malveillant pour réintégrer à plusieurs reprises la fonction vulnérable avant la fin de l'exécution initiale. Ce comportement récursif peut égoutter les fonds ou manipuler les variables d'état de manière inattendue.

2. Le mécanisme de base implique un contrat d'appel invoquant une fonction dans un contrat cible qui fait un appel externe - souvent pour transférer des fonds - avant de mettre à jour son état interne. Si le contrat de réception contient une fonction de secours avec une logique malveillante, il peut déclencher un autre rappel dans la fonction d'origine, créant une boucle. Étant donné que le solde ou l'état n'a pas encore été mis à jour, chaque rentrée contourne les chèques et continue de retirer des fonds.

3. L'un des exemples les plus tristement célèbres est le hack DAO 2016, où plus de 3,6 millions d'ETH ont été siphonés en raison d'un défaut de réentrance. La fonction de retrait de l'organisation autonome décentralisée a envoyé des fonds avant de définir le solde de l'utilisateur à zéro, permettant à l'attaquant de retirer à plusieurs reprises le même solde. Cet événement a conduit à une fourche dure dans le réseau Ethereum et à une sensibilisation accrue autour de la conception de contrat sécurisée.

4. Les pratiques de développement modernes mettent désormais l'accent sur le modèle «Check-Effets-Interactions» pour empêcher de telles attaques. Cette approche exige que l'État change - comme la mise à jour des équilibres ou la propriété - sur les appels de fonction externe. En garantissant la cohérence interne avant l'interaction, la fenêtre de renforcement est effectivement fermée.

5. Les garanties de niveau linguistique dans la solidité, comme l'utilisation des gardes de réentrance de la bibliothèque d'Openzeppelin, sont devenues standard. Ces gardes utilisent un mécanisme de type mutex pour marquer une fonction en exécution actuellement, bloquant toutes les tentatives d'entrée récursives. Les développeurs sont également encouragés à utiliser des modèles de paiement pull-sur-push, où les utilisateurs lancent des retraits plutôt que d'avoir des fonds qui leur sont automatiquement poussés.

Vecteurs communs de l'exploitation de la réentrance

1. Les appels externes à des contrats inconnus ou non fiables servent de point d'entrée principal pour la réentrance. Lorsqu'un contrat invoque une fonction sur un autre contrat, en particulier celui qui peut exécuter du code arbitraire - il risque de tomber dans un piège de rappel. Ceci est particulièrement dangereux lorsque le contrat appelé est contrôlé par l'attaquant.

2. Les fonctions de secours et de réception dans les contrats intelligents Ethereum sont des déclencheurs automatiques lorsqu'un contrat reçoit l'éther. Si ces fonctions contiennent une logique qui rappelle l'expéditeur, elles peuvent exploiter les lacunes de synchronisation dans les mises à jour d'état. Les attaquants fabriquent des contrats avec ces fonctions conçues spécifiquement pour réintégrer les routines de retrait ou de transfert vulnérables.

3. Si plusieurs fonctions partagent l'état et manquent de mécanismes de verrouillage appropriés, un attaquant peut sauter entre eux pour maintenir un état incohérent et extraire la valeur.

4. Les prêts flash provenant des protocoles de financement décentralisés (DEFI) ont amplifié le risque. Les attaquants peuvent emprunter de grosses sommes sans garantie, les utiliser pour manipuler les conditions de contrat et exécuter des attaques de renforcement dans une seule transaction. Les fonds empruntés sont remboursés avant la finalisation du bloc, ce qui rend l'attaque rentable et difficile à empêcher par une dissuasion économique.

5. Les bibliothèques tierces mal auditées ou le code hérité peuvent introduire des risques de renforcement cachés. Même si la logique principale semble sécurisée, les dépendances peuvent contenir des fonctions vulnérables qui sont indirectement exposées. Cela souligne la nécessité d'audits complets et de suivi des dépendances dans les projets Defi.

Stratégies d'atténuation et meilleures pratiques

1. L'application du modèle de chèques-effets-interactions est fondamentale. Les développeurs doivent s'assurer que toutes les modifications d'état se produisent avant tout appel externe. Par exemple, la réduction du solde d'un utilisateur avant d'envoyer des fonds élimine la possibilité de retirer plusieurs fois le même solde.

2. La mise en œuvre de modificateurs non réentrants des bibliothèques de confiance ajoute une couche de protection. Ces modificateurs utilisent un drapeau booléen pour verrouiller la fonction pendant l'exécution, empêchant les appels récursifs. Bien qu'ils ne soient pas infaillibles, ils sont efficaces contre les modèles de réentrance les plus connus.

3. Limiter la quantité d'éther ou de jetons qu'un contrat peut tenir réduit les dommages potentiels. Les contrats qui agissent en tant qu'intermédiaires devraient minimiser l'accumulation de fonds et encourager les retraits fréquents. Cela limite la marge bénéficiaire de l'attaquant même si une vulnérabilité existe.

4. Les audits de code par des sociétés de sécurité spécialisés sont essentiels. Des outils automatisés comme Slither ou Mythril peuvent détecter les modèles de réentrée, mais une revue humaine est nécessaire pour capter des défauts logiques complexes. Les examens par les pairs et les programmes de primes de bogues renforcent encore la sécurité.

5. L'utilisation de modèles de contrat à niveau avec des mécanismes de pause permet aux développeurs de répondre aux attaques en temps réel. Bien que cela introduit des risques de centralisation, il offre une option d'intervention d'urgence critique lorsque les vulnérabilités sont découvertes après le déploiement.

Questions fréquemment posées

Qu'est-ce qui déclenche une attaque de renforcement dans un contrat intelligent? Une attaque de renforcement est déclenchée lorsqu'un contrat passe un appel externe à un autre contrat avant de mettre à jour son état interne. Si le contrat de réception a une fonction de secours malveillante, il peut rappeler la fonction du contrat d'origine, exploitant la mise à jour de l'état inachevée.

La réentrance peut-elle se produire dans des contrats qui ne gèrent pas l'éther? Oui. Bien que les transferts d'éther soient des vecteurs communs, la rentrée peut également se produire avec des transferts de jetons ou tout appel externe à un contrat qui peut faire un appel récursif. Le facteur clé est la séquence des mises à jour d'état et des interactions externes, pas le type d'actif.

Tous les protocoles Defi sont-ils vulnérables à la rentrée? Pas tout, mais beaucoup de protocoles de défi précoces l'étaient. Les protocoles modernes intègrent des gardes de réentrance et suivent des pratiques de codage sécurisées. Cependant, les projets nouveaux ou non audités peuvent toujours comporter des risques, surtout s'ils interagissent avec les systèmes hérités ou les contrats non fiables.

Comment les prêts Flash permettent-ils des attaques de renforcement? Les prêts flash permettent aux attaquants d'emprunter de grandes quantités d'actifs dans une seule transaction. Ils utilisent ces fonds pour manipuler les états contractuels - tels que les pools de liquidité et déclenchent une rentabilité avant de rembourser le prêt. Cela permet des attaques rentables sans capital initial.