Cet article est un message 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 les opinions de Binance Academy.

Résumé

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

Introduction 

Bridge blockchain est un protocole qui connecte deux blockchains pour permettre l'interaction entre elles. Si vous possédez des bitcoins mais souhaitez participer aux activités DeFi sur le réseau Ethereum, les ponts blockchain vous permettent de le faire sans vendre de bitcoins. 

Les ponts blockchain sont essentiels pour parvenir à l’interopérabilité dans le domaine de la blockchain. Ce pont fonctionne en utilisant diverses validations en chaîne et hors chaîne, il présente donc diverses vulnérabilités de sécurité.

Pourquoi la sécurité du pont est-elle importante ? 

Les ponts stockent généralement les jetons que les utilisateurs souhaitent transférer d'une chaîne à une autre. Les ponts sont souvent mis en œuvre sous forme de contrats intelligents et stockent de grandes quantités de jetons à mesure que les transferts entre chaînes s'accumulent, ce qui en fait des cibles tentantes pour les pirates. 

De plus, les ponts blockchain présentent un écart d’attaque important car ils impliquent de nombreux composants. Par conséquent, les criminels sont très motivés à cibler les applications inter-chaînes afin de drainer de grandes quantités de fonds. 

Les attaques de ponts ont causé des pertes de plus de 1,3 milliard USD en 2022, soit 36 ​​% des pertes totales de cette année-là selon les estimations du CertiK. 

Vulnérabilités de sécurité courantes des ponts

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

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 minime. Le pont s'appuie sur un backend centralisé pour exécuter des opérations de base telles que la frappe, la gravure et le transfert 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 une vérification en chaîne. Dans cette situation, lorsqu'un utilisateur dépose des fonds dans une chaîne, le contrat intelligent générera un message signé et renverra la signature dans la transaction. Cette signature sert de preuve de dépôt et est utilisée pour vérifier les demandes des utilisateurs sur d'autres chaînes. Ce processus devrait empêcher diverses attaques de sécurité, notamment les attaques par relecture et les faux enregistrements de dépôt. 

Cependant, si une vulnérabilité existe lors du processus de validation en chaîne, un attaquant pourrait causer de graves dommages. Par exemple, si un pont utilise un arbre Merkle pour valider les enregistrements de transactions, un attaquant pourrait 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 « jeton enveloppé ». Par exemple, lorsqu'un utilisateur transfère le DAI d'Ethereum vers BNB Chain, son DAI est extrait du contrat Ethereum et une quantité équivalente de DAI enveloppé est émise vers BNB Chain. 

Cependant, si ces transactions ne sont pas correctement validées, un attaquant peut mettre en œuvre un contrat malveillant pour acheminer les jetons enveloppés du pont vers la mauvaise adresse en manipulant sa fonctionnalité. 

L'attaquant demande également à la victime d'accepter le contrat-relais afin de transférer des jetons à l'aide de la fonction « transferFrom » pour drainer les actifs du contrat-relais. 

Malheureusement, la situation empire car la plupart des ponts nécessitent une approbation illimitée des jetons de la part des utilisateurs de DApp. Il s'agit d'une pratique courante qui réduit les frais de gaz, mais introduit un risque supplémentaire en permettant aux contrats intelligents d'accéder aux jetons d'un nombre illimité de portefeuilles d'utilisateurs. 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, les serveurs backend hors chaîne jouent un rôle important dans la vérification de la validité des messages envoyés depuis la blockchain. Dans ce cas, nous nous concentrons sur la vérification des transactions de dépôt. 

La façon dont un pont blockchain fonctionne avec la validation hors chaîne est la suivante : 

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

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

3. Les hachages de transaction nécessitent une certaine validation par le serveur. S'il est jugé valide, le signataire signe le message, puis renvoie la signature à l'interface utilisateur via l'API.

4. Après avoir reçu la signature, le DApp la vérifie, puis permet à l'utilisateur de retirer les jetons de la chaîne cible.

Le serveur principal doit garantir que la transaction de dépôt traitée a réellement eu lieu et n'a pas été falsifiée. Ce serveur backend détermine si les utilisateurs peuvent retirer des jetons sur la chaîne cible, ce qui en fait une cible de grande valeur pour les attaquants.

Le serveur backend doit valider la structure de l'événement résultant de la transaction ainsi que l'adresse du contrat qui a généré l'événement. Si l'adresse du contrat est ignorée, un attaquant peut alors mettre en œuvre un contrat malveillant pour simuler un événement de dépôt en utilisant la même structure qu'un événement de dépôt légitime. 

S'il ne vérifie pas l'adresse qui a généré l'événement, le serveur backend peut supposer que ce contrat est valide et signer le message. Ensuite, l'attaquant peut envoyer le hachage de transaction au backend, contournant ainsi la vérification et lui permettant de retirer les jetons de la chaîne cible.

Mauvaise gestion des jetons natifs

Bridge adopte diverses 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 suivent 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, les utilisateurs attachent simplement de l'ETH à une transaction, puis le montant d'ETH peut être récupéré en lisant le champ « msg.value » de la transaction.

Le dépôt de jetons ERC-20 est très différent du dépôt d’ETH. Pour déposer des jetons ERC-20, les utilisateurs doivent d'abord autoriser le contrat relais à utiliser leurs jetons. Une fois qu'il a accepté 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 les jetons de l'utilisateur au contrat à l'aide de la fonction "transferFrom()". 

Une approche pour les différencier consiste à utiliser des instructions 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 une perte de fonds.

Lors du traitement d'une demande de dépôt ERC-20, les utilisateurs fournissent généralement une adresse de jeton comme entrée dans la fonction de dépôt. Cette action présente des risques importants, car des appels externes non fiables peuvent survenir lors des transactions. La mise en œuvre d'une liste blanche qui inclut uniquement les jetons adossés à un 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 filtre déjà les adresses des jetons.

Cependant, des problèmes surviennent également lorsque le pont gère les transferts inter-chaînes de jetons natifs, car les jetons natifs n'ont pas d'adresse. L'adresse zéro (0x000...0) représente le jeton d'origine. Cela peut être problématique, car transmettre une adresse nulle à une fonction peut contourner la vérification de la liste blanche même si elle est mal implémentée. 

Lorsque le contrat relais 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 à l'adresse zéro. Cependant, des transactions peuvent toujours avoir lieu si le contrat ne peut pas gérer correctement la valeur résultante. Cela crée une opportunité pour les attaquants d'exécuter des transactions sans transférer de jetons au contrat.

Erreur de configuration

Dans la plupart des ponts blockchain, une position privilégiée 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 importantes. Il est essentiel de garantir que toutes les configurations sont exactes, car même des erreurs apparemment insignifiantes peuvent entraîner des pertes importantes.

En fait, lors d’un incident, un attaquant a réussi à contourner la vérification des enregistrements de transfert en raison d’une erreur de configuration. L'équipe du projet a mis en œuvre une mise à niveau du protocole plusieurs jours avant le piratage, qui comprenait la modification d'une variable. La variable est utilisée pour représenter la valeur par défaut des messages approuvés. Ce changement fait que tous les messages sont considérés comme automatiquement prouvés, permettant aux attaquants d'envoyer des messages à volonté et de contourner le processus de vérification.

Comment améliorer la sécurité du pont

Les quatre vulnérabilités courantes des ponts décrites 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 concernant la résolution de chacune de ces vulnérabilités. Il n’existe pas de ligne directrice unique qui s’applique à tout. 

Par exemple, il est difficile de fournir des lignes directrices générales pour garantir un processus de vérification sans erreur, car 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 a du sens. 

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

Fermeture 

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é des ponts en effectuant des tests approfondis avant la mise en œuvre et en effectuant des audits par des tiers afin de réduire le risque de piratages coûteux 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 que la Blockchain Bridge ?

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 à des fins éducatives uniquement, sans représentation ni garantie d'aucune sorte. Ce contenu ne doit pas être interprété comme un conseil financier, juridique ou autre conseil professionnel et n’est pas non plus destiné à recommander l’achat d’un produit ou d’un service particulier. Vous devriez demander conseil à des conseillers professionnels appropriés. Si l'article est une contribution d'un contributeur tiers, veuillez noter que les opinions exprimées sont celles du contributeur tiers et ne reflètent pas nécessairement les opinions 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 baisser ou augmenter. Il se peut que vous ne récupériez pas le montant investi. Vous êtes pleinement responsable de vos décisions d'investissement. Binance Academy n'est pas responsable des pertes que vous pourriez subir. Ce document ne doit pas être considéré comme un conseil financier, juridique ou autre conseil professionnel. Pour plus d’informations, lisez nos conditions d’utilisation et nos avertissements de risque.