Qu'est-ce qu'une attaque de réentrance dans un contrat intelligent?

Comprendre les bases des contrats intelligents

Un contrat intelligent est un contrat auto-exécutant avec les termes directement écrits en code. Il fonctionne sur des plateformes de blockchain comme Ethereum et applique automatiquement les accords entre les parties sans intermédiaires. Ces contrats sont immuables une fois déployés, ce qui signifie que toutes les vulnérabilités présentes dans le code ne peuvent pas être modifiées après le déploiement. Cette immuabilité rend crucial pour s'assurer que les contrats intelligents sont sécurisés de tous les exploits possibles avant leur mise en ligne.

L'un de ces exploitations est l' attaque de réentrance , qui a été responsable de pertes importantes dans l'écosystème de la crypto-monnaie. Comprendre le fonctionnement de cette vulnérabilité nécessite une compréhension de la façon dont les contrats intelligents interagissent avec les comptes externes et autres contrats via des appels de fonction.

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

Une attaque de réentrance se produit lorsqu'un contrat malveillant appelle à plusieurs reprises une fonction vulnérable dans un autre contrat 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 involontaire.

L'exemple classique implique un contrat de gestion des transferts d'éther. Si une fonction envoie Ether à une adresse externe avant de mettre à jour son solde interne, un contrat malveillant peut réintégrer la fonction pendant le transfert et drainer les fonds du contrat à plusieurs reprises. Le tristement célèbre hack DAO en 2016 , qui a entraîné une perte d'éther de 60 millions de dollars, est le résultat d'une vulnérabilité de réentrance.

Comment fonctionne une attaque de réentrance dans la pratique?

Pour mieux comprendre la mécanique d'une attaque de réentrance, considérez le scénario simplifié suivant:

• Un contrat a une fonction withdraw() qui permet aux utilisateurs de retirer leur éther déposé.
• La fonction envoie d'abord Ether à l'utilisateur à l'aide de call.value() , puis met à jour le solde de l'utilisateur à zéro.
• Un contrat malveillant s'inscrit en tant qu'utilisateur et dépose l'éther dans le contrat cible.
• Lorsqu'il appelle withdraw() , le contrat cible initie le transfert d'éther.
• Pendant le transfert, la fonction de secours du contrat malveillant (qui est déclenché automatiquement) appelle à nouveau withdraw() .
• Étant donné que le solde n'a pas encore été mis à jour, le contrat estime que l'utilisateur a toujours des fonds disponibles et envoie plus d'éther.
• Cette boucle se poursuit jusqu'à ce que le contrat soit drainé ou que le gaz s'épuise.

Ce processus exploite l'ordre des opérations dans le contrat, en particulier, l'envoi de l'éther avant de mettre à jour l'État.

Types de vulnérabilités de réentrance

Les attaques de réentrance se présentent sous plusieurs formes, chacune exploitant différents aspects de la logique contractuelle:

• Réentrance à une seule fonction : Cela se produit lorsqu'une seule fonction contient à la fois des appels externes et des changements d'état. Un attaquant déclenche une rentrée pendant l'appel externe avant que l'État ne soit mis à jour.
• Réentrance croisée : ici, les fonctions multiples partagent des variables d'état. Un attaquant peut réintégrer une deuxième fonction tandis que le premier s'exécute toujours, manipulant les données partagées de manière incohérente.
• RelegateCall Réentrance : cette variante avancée utilise le mécanisme delegatecall pour exécuter le code à partir d'un contrat dans le contexte d'un autre. S'il n'est pas géré attentivement, cela peut conduire à des scénarios de réentrance inattendus.

Chaque type nécessite une audit soigneuse et des stratégies d'atténuation spécifiques pour empêcher l'exploitation.

Comment éviter les attaques de réentrance

La prévention des attaques de réentrance consiste à adopter les meilleures pratiques dans la conception des contrats et à tirer parti des outils de sécurité:

• Utilisez le modèle de chèques-effets-interactions : mettez toujours à jour l'état du contrat avant de passer des appels externes. Cela garantit qu'aucune rentrée ne peut manipuler des soldes ou des états préexistants.
• Implémentation des gardes de réentrance : les bibliothèques comme Openzeppelin fournissent des modificateurs de garde de réentrance qui utilisent une variable Mutex pour bloquer les appels réentrants.
• Évitez les appels externes complexes : minimiser les interactions avec des contrats inconnus ou non fiables. Si nécessaire, assurez-vous que les rappels sont sûrs et ne déclenchent pas de code arbitraire.
• Utilisez des paiements de poussée : au lieu de pousser des fonds aux utilisateurs, laissez-les lancer des retraits. Cela réduit le risque de drainage récursif.
• Effectuer des audits approfondis : Utilisez des outils automatisés et des revues manuelles pour détecter les vecteurs de réentrance potentiels dans votre base de code.

En appliquant ces stratégies, les développeurs peuvent réduire considérablement la probabilité d'une attaque de réentrance réussie.

Exemples du monde réel d'exploits de réentrance

Plusieurs incidents de haut niveau mettent en évidence l'impact dévastateur des attaques de réentrance:

• Le DAO Hack (2016) : Le cas le plus célèbre impliquait une organisation autonome décentralisée dont le contrat intelligent a permis des retraits récursifs. Les attaquants ont exploité cela pour drainer des millions d'éther.
• Fusion Network Attack (2021) : les pirates ont exploité un bogue de réentrance croisé dans le protocole, ce qui entraîne une perte de 14 millions de dollars.
• Warp Finance Hack (2021) : plusieurs points de réentrance ont été exploités sur différentes fonctions, permettant aux attaquants de vider près de 8 millions de dollars d'actifs.

Ces exemples soulignent l'importance des tests rigoureux et de l'adhésion aux pratiques de codage sécurisées.

Questions fréquemment posées

Q: Les attaques de réentrance peuvent-elles se produire dans des blockchains non éthereum? Oui, les attaques de réentrance peuvent affecter toute plate-forme blockchain qui prend en charge les contrats intelligents avec des appels externes et un état mutable. Alors qu'Ethereum a vu les cas les plus importants, des vulnérabilités similaires existent sur Binance Smart Chain, Solana et autres.

Q: Tous les appels externes sont-ils dangereux? Non, mais les appels externes doivent être traités avec prudence. Le danger survient lorsqu'ils sont fabriqués avant de mettre à jour les variables d'état critiques. Des modèles de codage et des garanties appropriés peuvent atténuer ce risque.

Q: Comment tester mon contrat pour les vulnérabilités de réentrance? Vous pouvez utiliser des outils d'analyse statique comme Slither ou Securify, effectuer des audits de code manuel et simuler des scénarios d'attaque à l'aide de frameworks comme Brownie ou HardHat. L'utilisation de gardes de réentrance et suivant des pratiques de développement sécurisées aide également.

Q: Quelle est la différence entre une attaque de prêt flash et une attaque de réentrance? Bien que les deux puissent exploiter les protocoles Defit, une attaque de prêt flash repose sur l'emprunt de grandes quantités de capital sans garantie et le rembourser dans la même transaction. Une attaque de réentrance se concentre sur l'appel récursivement des fonctions pour manipuler l'état du contrat. Cependant, certaines attaques combinent les deux techniques pour plus d'impact.