Cet article est une contribution de la communauté. L'auteur est Minzhi He, auditeur de 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 fondamentaux pour parvenir à l’interopérabilité dans l’espace blockchain. Par conséquent, la sécurité de la technologie de pontage entre chaînes est cruciale. Certaines vulnérabilités courantes en matière de sécurité des ponts blockchain incluent une vérification insuffisante en chaîne et hors chaîne, une mauvaise gestion des jetons natifs et une mauvaise configuration. Pour garantir que la logique de vérification est solide, il est recommandé de tester le pont inter-chaînes contre tous les vecteurs d'attaque possibles.

Introduction

Un pont blockchain est un protocole qui relie deux blockchains et leur permet d'interagir. Grâce au pont blockchain, si les utilisateurs souhaitent participer aux activités DeFi sur le réseau Ethereum, il leur suffit de détenir du Bitcoin et n'ont pas besoin de le vendre pour atteindre leurs objectifs.​

Le pont Blockchain est la base de l’interopérabilité dans le domaine de la blockchain. Ils utilisent diverses vérifications en chaîne et hors chaîne pour fonctionner, il peut donc également exister différentes vulnérabilités de sécurité.

Pourquoi la sécurité des ponts blockchain est-elle critique ?

Les ponts blockchain contiennent généralement des jetons que les utilisateurs souhaitent transférer d'une chaîne à une autre. Les ponts blockchain sont généralement déployés sous la forme de contrats intelligents. À mesure que les transferts entre chaînes continuent de s'accumuler, un grand nombre de jetons seront détenus sur le pont. Cette énorme richesse en fera une cible convoitée pour les pirates.

De plus, la surface d’attaque des ponts blockchain a tendance à être importante en raison des nombreux composants impliqués. Par conséquent, les criminels sont fortement incités à cibler les applications inter-chaînes afin d’obtenir de grandes sommes d’argent.

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

Vulnérabilités de sécurité courantes du pontage inter-chaînes

Pour améliorer la sécurité d'un pont blockchain, il est important de comprendre les vulnérabilités courantes de sécurité des ponts inter-chaînes et de tester le pont blockchain avant de le lancer. Ces vulnérabilités proviennent principalement des quatre aspects suivants :

Vérification en chaîne insuffisante

Pour les ponts blockchain simples, en particulier ceux conçus pour une dApp spécifique, il n'y a généralement qu'un niveau minimal de vérification en chaîne. Ces ponts s'appuient sur un backend centralisé pour effectuer des opérations de base telles que la frappe, la gravure et les transferts de jetons, toutes les vérifications étant effectuées hors chaîne.

Tandis que d'autres types de ponts utilisent des contrats intelligents pour valider les messages et les vérifier en chaîne. Dans ce cas, lorsqu'un utilisateur dépose des fonds dans la chaîne, le contrat intelligent génère un message signé et renvoie la signature dans la transaction. Cette signature servira de preuve de dépôt et servira à vérifier la demande de retrait de l'utilisateur sur une autre chaîne. Ce processus devrait empêcher diverses attaques de sécurité, notamment les attaques par rejeu et les enregistrements de recharge falsifiés.

Cependant, s’il existe une vulnérabilité dans le processus de vérification en chaîne, une attaque pourrait causer de graves dommages. Par exemple, si la blockchain utilise des arbres Merkle pour vérifier les enregistrements de transactions, un attaquant peut générer de fausses preuves. Cela signifie que si le processus de vérification est vulnérable, un attaquant peut contourner la vérification de preuve et créer de nouveaux jetons sur son compte.

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

Cependant, si cette transaction n'est pas correctement validée, un attaquant peut déployer un contrat malveillant qui manipule cette fonctionnalité pour acheminer les jetons encapsulés du pont vers la mauvaise adresse.​

L'attaquant a également besoin que la victime approuve le contrat de pont inter-chaînes avant d'utiliser la fonction « TransferFrom » pour transférer des jetons, supprimant ainsi les actifs du contrat de pont inter-chaînes.

Mais le problème est que de nombreux ponts inter-chaînes exigent que les utilisateurs de dApp approuvent un nombre illimité de jetons. Cette pratique est très courante, ce qui peut réduire les frais de gaz, mais permet aux contrats intelligents d'accéder à un nombre illimité de jetons depuis le portefeuille de l'utilisateur. ce qui entraînera des risques supplémentaires. Les attaquants exploiteraient ces sous-vérifications et ces approbations excessives pour transférer des jetons d’autres utilisateurs vers eux-mêmes.

Vérification hors chaîne insuffisante

Dans certains systèmes de ponts inter-chaînes, les serveurs backend hors chaîne jouent un rôle crucial dans la vérification de la légitimité des messages envoyés depuis la blockchain. Dans ce cas, nous devons nous concentrer sur la vérification de la transaction de recharge.

Un pont blockchain avec vérification hors chaîne fonctionne comme suit :

1. Les utilisateurs interagissent avec la dApp et déposent des jetons dans des contrats intelligents sur la chaîne source.

2. La dApp envoie ensuite le hachage de la transaction de dépôt au serveur backend via l'API.

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

4. Une fois la signature reçue, la dApp la vérifie et permet à l'utilisateur de retirer les jetons de la chaîne cible.

Le serveur backend doit s'assurer que les transactions de recharge qu'il gère sont réelles et non falsifiées. Ce serveur backend détermine si un utilisateur peut retirer des jetons sur la chaîne cible, ce qui en fait la première cible des attaques.

Le serveur principal doit vérifier la structure de l'événement d'initiation de la transaction et l'adresse du contrat qui a initié l'événement. Si ce dernier est ignoré, les attaquants peuvent déployer des contrats malveillants pour créer des événements de recharge ayant la même structure que les événements de recharge légitimes.

Si le serveur principal ne vérifie pas quelle adresse a initié l'événement, il supposera qu'il s'agit d'une transaction valide et signera le message. Un attaquant peut alors envoyer le hachage de transaction au serveur backend, contournant la vérification et lui permettant de retirer des jetons de la chaîne cible.

Gestion incorrecte des jetons natifs

Les ponts inter-chaînes adoptent une approche différente des jetons natifs et des jetons utilitaires. Par exemple, sur le réseau Ethereum, le token natif est ETH, et la plupart des tokens utilitaires sont conformes à la norme ERC-20.

Si 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 de pont inter-chaînes. Pour ce faire, l'utilisateur attache simplement de l'ETH à la transaction et peut récupérer le montant d'ETH en lisant le champ de transaction « msg.value ».

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 de pont inter-chaînes à utiliser leurs jetons. Après avoir approuvé et déposé les jetons dans le contrat de pont inter-chaînes, le contrat utilisera la fonction « burnFrom() » pour détruire les jetons de l'utilisateur, ou la fonction « transferFrom() » pour transférer les jetons de l'utilisateur vers le contrat.

Pour distinguer de quelle opération il s’agit, vous pouvez utiliser des instructions if-else dans la même fonction. Ou créez deux fonctions distinctes pour gérer chaque scénario. En raison des différentes méthodes de traitement, si un utilisateur tente de déposer de l'ETH à l'aide de la fonction de dépôt ERC-20, l'ETH peut être perdu.

Lors du traitement des demandes de dépôt ERC-20, les utilisateurs fournissent généralement l'adresse du jeton comme paramètre d'entrée à la fonction de dépôt. Cela présente un risque important, car des appels externes non fiables peuvent survenir lors des transactions. L'utilisation d'une liste blanche pour inclure uniquement les jetons pris en charge par un pont inter-chaînes est une pratique courante pour minimiser les risques. Seules les adresses sur liste blanche sont transmises en paramètres. Cela évite les appels externes car l'équipe du projet a filtré les adresses des jetons.

Cependant, il existe également un problème lorsque le pont inter-chaînes gère le transfert inter-chaînes de jetons natifs, car les jetons natifs n'ont pas d'adresse. Les tokens natifs peuvent être représentés par une adresse spéciale, l'"adresse zéro" (0x000... 0). Mais cela pose un problème : si la logique de vérification de la liste blanche n'est pas implémentée correctement, transmettre une adresse nulle à la fonction peut contourner la vérification de la liste blanche.

Lorsque le contrat de pont inter-chaînes appelle « TransferFrom » pour transférer les actifs de l'utilisateur vers le contrat, l'appel externe à l'adresse zéro renverra false car la fonction « transferFrom » n'est pas implémentée dans l'adresse zéro. Cependant, si le contrat ne gère pas correctement la valeur de retour, la transaction peut quand même continuer à se produire. Cela crée une opportunité pour un attaquant d'exécuter une transaction sans transférer de jetons au contrat.

Erreur de configuration

Dans la plupart des ponts blockchain, il existe un rôle privilégié 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 clés. Il est essentiel de garantir que toutes les configurations sont exactes, car des oublis apparemment insignifiants peuvent entraîner des dommages importants.

En fait, il y a eu des incidents au cours desquels des attaquants ont réussi à contourner la vérification des enregistrements 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 au cours de laquelle une certaine variable a été modifiée. Cette variable est la valeur par défaut utilisée pour représenter les messages approuvés. Ce changement fait que tous les messages sont automatiquement considérés comme authentifiés, permettant ainsi à un attaquant de soumettre un message aléatoire et de réussir l'authentification.

Comment améliorer la sécurité des ponts inter-chaînes

Les quatre vulnérabilités courantes des ponts inter-chaînes décrites ci-dessus démontrent que les défis auxquels est confrontée la sécurité dans un écosystème de blockchain connecté ne peuvent être sous-estimés. Pour faire face à ces vulnérabilités, nous devons réfléchir « en fonction des conditions locales ». Aucune méthode ne peut être une panacée pour faire face à toutes les vulnérabilités.

Par exemple, étant donné que chaque pont inter-chaînes a des exigences de vérification uniques, il serait difficile de garantir que le processus de vérification est sans erreur en fournissant simplement des directives générales. Le moyen le plus efficace d'empêcher le contournement de la vérification consiste à tester minutieusement le pont inter-chaînes contre tous les vecteurs d'attaque possibles et à garantir que la logique de vérification est raisonnable.

Dans l’ensemble, des tests rigoureux doivent être effectués contre les attaques potentielles, avec une attention particulière accordée aux vulnérabilités de sécurité les plus courantes dans les ponts inter-chaînes.

Conclusion

En raison du volume considérable de fonds, les ponts inter-chaînes sont depuis longtemps la cible des attaquants. Les constructeurs peuvent renforcer la sécurité des ponts inter-chaînes en effectuant des tests complets avant le déploiement et en intégrant des audits tiers, réduisant ainsi le risque de piratage catastrophique qui a menacé les ponts inter-chaînes au cours des dernières années. Les ponts entre chaînes sont cruciaux dans un monde multi-chaînes, mais la sécurité doit être une considération primordiale 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é entre chaînes ?

Trois ponts de crypto-monnaie populaires et comment ils fonctionnent

Qu'est-ce qu'un jeton enveloppé ?

Avis de non-responsabilité et avertissement de risque : le contenu de cet article est constitué de faits et est uniquement destiné à des fins d'information générale et d'éducation et ne constitue aucune représentation ou garantie. Cet article ne doit pas être interprété comme un conseil financier, juridique ou autre conseil professionnel et ne constitue pas une recommandation d’achat d’un produit ou d’un service spécifique. Vous devriez demander votre propre avis à des conseillers professionnels appropriés. Si cet article a été fourni par un contributeur tiers, veuillez noter que les opinions exprimées dans cet article appartiennent au contributeur tiers et ne reflètent pas nécessairement les opinions de Binance Academy. Pour plus d’informations, veuillez cliquer ici pour lire notre clause de non-responsabilité complète. Les prix des actifs numériques peuvent fluctuer. La valeur de votre investissement peut baisser comme augmenter et vous risquez de ne pas récupérer le capital investi. Vous êtes seul responsable de vos propres décisions d'investissement et Binance Academy n'est pas responsable des pertes que vous pourriez subir. Cet article ne constitue pas un conseil financier, juridique ou autre conseil professionnel. Pour plus d’informations, veuillez consulter nos conditions d’utilisation et nos avertissements de risque.