Cet article est une soumission de la communauté. L'auteur est Minzhi He, auditeur chez CertiK.

Les opinions exprimées dans cet article sont celles du contributeur/auteur et ne reflètent pas nécessairement celles de Binance Academy.

TL;DR

Les ponts blockchain sont essentiels pour parvenir à l’interopérabilité dans l’espace blockchain. La sécurité du pont est donc d’une importance primordiale. Certaines vulnérabilités courantes en matière de sécurité des ponts incluent une faible validation en chaîne et hors chaîne, une mauvaise gestion des jetons natifs et des erreurs de configuration. Il est recommandé de tester le pont contre tous les vecteurs d'attaque possibles pour garantir une logique de vérification solide.

Introduction

Un pont blockchain est un protocole reliant deux blockchains pour permettre les interactions entre elles. Si vous possédez du bitcoin mais souhaitez participer à l'activité DeFi sur le réseau Ethereum, un pont blockchain vous permet de le faire sans vendre votre bitcoin.

Les ponts blockchain sont fondamentaux pour parvenir à l’interopérabilité au sein de l’espace blockchain. Ils fonctionnent en utilisant diverses validations en chaîne et hors chaîne et présentent donc différentes vulnérabilités de sécurité.

Pourquoi la sécurité des ponts est-elle essentielle ?

Un pont contient généralement le jeton qu'un utilisateur souhaite transférer d'une chaîne à une autre. Souvent déployés sous forme de contrats intelligents, les ponts contiennent une quantité importante de jetons à mesure que les transferts inter-chaînes s'accumulent, ce qui en fait des cibles lucratives pour les pirates.

De plus, les ponts blockchain ont une grande surface d’attaque car ils impliquent de nombreux composants. Dans cette optique, les acteurs malveillants sont très motivés à cibler les applications inter-chaînes afin de drainer d’importantes sommes de fonds.

Les attaques de ponts ont entraîné des pertes de plus de 1,3 milliard de dollars en 2022, soit 36 ​​% des pertes totales de l’année, selon les estimations de CertiK.

Vulnérabilités courantes de sécurité du pont

Pour améliorer la sécurité des ponts, il est utile de comprendre les vulnérabilités courantes en matière de sécurité des ponts et de tester les ponts avant le lancement. Ces vulnérabilités peuvent être classées dans les quatre domaines suivants.

Faible validation en chaîne

Pour les ponts simples, en particulier ceux conçus pour des DApp spécifiques, la validation en chaîne est réduite au minimum. Ces ponts s'appuient sur un backend centralisé pour exécuter des opérations de base telles que la frappe, la gravure et les transferts de jetons tandis que toutes les vérifications sont effectuées hors chaîne.

En revanche, d'autres types de ponts utilisent des contrats intelligents pour valider les messages et effectuer des vérifications en chaîne. Dans ce scénario, lorsqu'un utilisateur dépose des fonds dans une chaîne, le contrat intelligent génère un message signé et renvoie la signature dans la transaction. Cette signature sert de preuve du dépôt et permet de vérifier la demande de retrait de l'utilisateur sur l'autre chaîne. Ce processus devrait être capable de prévenir diverses attaques de sécurité, notamment les attaques par relecture et les faux enregistrements de dépôt.

Cependant, s'il existe une vulnérabilité lors du processus de validation en chaîne, l'attaquant peut causer de graves dommages. Par exemple, si un pont utilise l'arborescence Merkle pour valider l'enregistrement de la transaction, un attaquant peut générer de fausses preuves. Cela signifie qu'ils peuvent contourner la validation des preuves et créer de nouveaux jetons sur leur compte si le processus de validation est vulnérable.

Certains ponts implémentent le concept de « jetons enveloppés ». Par exemple, lorsqu'un utilisateur transfère le DAI d'Ethereum vers la chaîne BNB, son DAI est extrait du contrat Ethereum et une quantité équivalente de DAI enveloppé est émise sur la chaîne BNB.

Cependant, si cette transaction n'est pas correctement validée, un attaquant pourrait déployer un contrat malveillant pour acheminer les jetons encapsulés du pont vers une adresse incorrecte en manipulant la fonction.

Les attaquants ont également besoin que les victimes approuvent le contrat relais pour transférer des jetons en utilisant la fonction « transferFrom » pour drainer les actifs du contrat relais.

Malheureusement, la situation est aggravée car de nombreux ponts demandent l’approbation infinie des jetons aux utilisateurs de DApp. Il s’agit d’une pratique courante qui réduit les frais de gaz mais crée des risques supplémentaires en permettant à un contrat intelligent d’accéder à un nombre illimité de jetons depuis le portefeuille de l’utilisateur. Les attaquants peuvent exploiter le manque de validation et l’approbation excessive pour transférer des jetons d’autres utilisateurs vers eux-mêmes.

Faible validation hors chaîne

Dans certains systèmes de pont, le serveur backend hors chaîne joue un rôle essentiel dans la vérification de la légitimité des messages envoyés depuis la blockchain. Dans ce cas, nous nous concentrons sur la vérification des transactions de dépôt.

Un pont blockchain avec validation hors chaîne fonctionne comme suit :

1. Les utilisateurs interagissent avec le DApp pour déposer des jetons dans le contrat intelligent sur la chaîne source.

2. Le DApp envoie ensuite le hachage de la transaction de dépôt au serveur backend via une API.

3. Le hachage de la transaction est soumis à plusieurs validations par le serveur. S'il est jugé légitime, un signataire signe un message et renvoie la signature à l'interface utilisateur via l'API.

4. Dès réception de la signature, le DApp la vérifie et permet à l'utilisateur de retirer ses jetons de la chaîne source.

Le serveur backend doit s’assurer que la transaction de dépôt qu’il traite a bien eu lieu et n’a pas été falsifiée. Ce serveur backend détermine si un utilisateur peut retirer des jetons sur la chaîne cible et constitue donc une cible de grande valeur pour les attaquants.

Le serveur backend doit valider la structure de l’événement émis par la transaction, ainsi que l’adresse du contrat qui a émis l’événement. Si ce dernier est négligé, un attaquant pourrait déployer un contrat malveillant pour forger un événement de dépôt ayant la même structure qu'un événement de dépôt légitime.

Si le serveur backend ne vérifie pas quelle adresse a émis l'événement, il considérera cela comme une transaction valide et signera le message. L'attaquant pourrait alors envoyer le hachage de transaction au backend, contournant la vérification et lui permettant de retirer les jetons de la chaîne cible.

Mauvaise gestion des jetons natifs

Les ponts adoptent différentes approches pour gérer les jetons natifs et les jetons utilitaires. Par exemple, sur le réseau Ethereum, le token natif est ETH et la plupart des tokens utilitaires adhèrent à la norme ERC-20.

Lorsqu'un utilisateur a l'intention de transférer son ETH vers une autre chaîne, il doit d'abord le déposer dans le contrat relais. Pour y parvenir, l'utilisateur attache simplement l'ETH à la transaction, et le montant de l'ETH peut être récupéré en lisant le champ « msg.value » de la transaction.

Le dépôt de jetons ERC-20 diffère considérablement du dépôt d’ETH. Pour déposer un jeton ERC-20, l'utilisateur doit d'abord autoriser le contrat relais à dépenser ses jetons. Après avoir approuvé cela et déposé les jetons dans le contrat relais, le contrat brûlera les jetons de l'utilisateur à l'aide de la fonction "burnFrom()" ou transférera le jeton de l'utilisateur au contrat à l'aide de la fonction "transferFrom()".

Une approche pour différencier cela consiste à utiliser une instruction if-else dans la même fonction. Une autre approche consiste à créer deux fonctions distinctes pour gérer chaque scénario. Tenter de déposer de l'ETH à l'aide de la fonction de dépôt ERC-20 peut entraîner la perte de ces fonds.

Lors du traitement des demandes de dépôt ERC-20, les utilisateurs fournissent généralement l'adresse du jeton comme entrée dans la fonction de dépôt. Cela présente un risque important car des appels externes non fiables peuvent survenir pendant la transaction. La mise en œuvre d'une liste blanche qui inclut uniquement les jetons pris en charge par le pont est une pratique courante pour minimiser les risques. Seules les adresses sur liste blanche peuvent être transmises comme arguments. Cela évite les appels externes car l'équipe du projet a déjà filtré l'adresse du token.

Cependant, des problèmes peuvent également survenir lorsque les ponts gèrent le transfert inter-chaînes de jetons natifs, car le jeton natif n'a pas d'adresse. Une adresse zéro (0x000...0) est représentative du jeton natif. Cela peut être problématique car transmettre l'adresse zéro à la fonction peut contourner la vérification de la liste blanche même si elle est mal implémentée.

Lorsque le contrat pont appelle « transferFrom » pour transférer les actifs de l'utilisateur vers le contrat, l'appel externe à l'adresse zéro renvoie false car aucune fonction « transferFrom » n'est implémentée dans l'adresse zéro. Cependant, la transaction peut toujours avoir lieu si le contrat ne gère pas la valeur de retour de manière appropriée. Cela crée une opportunité pour les attaquants d'exécuter la transaction sans transférer de jetons au contrat.

Mauvaise configuration

Dans la plupart des ponts blockchain, un rôle privilégié est responsable de la mise sur liste blanche ou noire des jetons et des adresses, de l'attribution ou de la modification des signataires et d'autres configurations critiques. Il est crucial de garantir que toutes les configurations sont exactes, car même des oublis apparemment insignifiants peuvent entraîner des pertes importantes.

En fait, il y a eu un incident au cours duquel l'attaquant a réussi à contourner la vérification de l'enregistrement de transfert en raison d'une mauvaise configuration. L’équipe du projet a mis en œuvre une mise à niveau du protocole quelques jours avant le piratage, qui impliquait la modification d’une variable. La variable a été utilisée pour représenter la valeur par défaut du message approuvé. Ce changement a permis à tous les messages d'être automatiquement considérés comme prouvés, permettant ainsi à un attaquant de soumettre un message arbitraire et de réussir le processus de vérification.

Comment améliorer la sécurité du pont

Les quatre vulnérabilités courantes des ponts expliquées ci-dessus démontrent les défis liés à la garantie de la sécurité dans un écosystème blockchain interconnecté. Il existe des considérations importantes pour gérer chacune de ces vulnérabilités, et aucun manuel unique ne s’applique à toutes.

Par exemple, il est difficile de fournir des lignes directrices générales pour garantir un processus de vérification sans erreur puisque chaque pont a des exigences de vérification uniques. L'approche la plus efficace pour empêcher le contournement de la vérification consiste à tester minutieusement le pont contre tous les vecteurs d'attaque possibles et à garantir que la logique de vérification est solide.

En résumé, il est essentiel d’effectuer des tests rigoureux contre les attaques potentielles et d’accorder une attention particulière aux vulnérabilités de sécurité les plus courantes dans les ponts.

Pensées finales

En raison de leur valeur élevée, les ponts inter-chaînes ont longtemps été une cible pour les attaquants. Les constructeurs peuvent renforcer la sécurité de leurs ponts en effectuant des tests préalables au déploiement approfondis et en s’engageant dans des audits tiers, réduisant ainsi le risque de piratages dévastateurs qui ont frappé les ponts au cours des dernières années. Les ponts sont essentiels dans un monde multi-chaînes, mais la sécurité doit être une préoccupation majeure lors de la conception et de la construction d'une infrastructure Web3 efficace.

Lectures complémentaires

Qu’est-ce qu’un pont Blockchain ?

Qu’est-ce que l’interopérabilité inter-chaînes ?

Trois ponts cryptographiques populaires et comment ils fonctionnent

Que sont les jetons emballés ?

Avis de non-responsabilité et avertissement de risque : ce contenu vous est présenté « tel quel » à des fins d'information générale et éducatives uniquement, sans représentation ni garantie d'aucune sorte. Il ne doit pas être interprété comme un conseil financier, juridique ou autre conseil professionnel, et il n’est pas non plus destiné à recommander l’achat d’un produit ou d’un service spécifique. Vous devriez demander votre propre avis auprès de conseillers professionnels appropriés. Lorsque l'article est rédigé par un contributeur tiers, veuillez noter que les opinions exprimées appartiennent au contributeur tiers et ne reflètent pas nécessairement celles de Binance Academy. Veuillez lire notre clause de non-responsabilité complète ici pour plus de détails. Les prix des actifs numériques peuvent être volatils. La valeur de votre investissement peut augmenter ou diminuer et vous ne récupérerez peut-être pas le montant investi. Vous êtes seul responsable de vos décisions d'investissement et Binance Academy n'est pas responsable des pertes que vous pourriez subir. Ce document ne doit pas être interprété comme un conseil financier, juridique ou autre conseil professionnel. Pour plus d’informations, consultez nos conditions d’utilisation et nos avertissements de risque.