Cet article est une contribution 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.
En bref
Les ponts blockchain constituent la base de l’interopérabilité dans le secteur de la blockchain. Il est donc très important de sécuriser les ponts. Certaines vulnérabilités courantes en matière de sécurité des ponts incluent une faible authentification en chaîne et hors chaîne, une mauvaise gestion des jetons natifs et des erreurs de configuration. Le pont doit être testé pour s'assurer qu'il peut résister à tous les vecteurs d'attaque et garantir une logique de vérification appropriée.
Introduire
Un pont blockchain est un protocole qui connecte deux blockchains pour permettre l'interaction entre elles. Si vous possédez du bitcoin mais souhaitez participer à l’activité DeFi sur le réseau Ethereum, le pont blockchain vous permettra de le faire sans vendre votre bitcoin.
Les ponts blockchain sont fondamentaux pour parvenir à l’interopérabilité dans le secteur de la blockchain. Ils fonctionnent en utilisant différentes authentifications 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 importante ?
Les ponts contiennent généralement des jetons que les utilisateurs souhaitent 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. Compte tenu de cette nature, les acteurs malveillants sont très motivés à cibler les applications inter-chaînes afin de retirer d’importantes sommes de fonds.
Les attaques de ponts entraînent 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 de pontage courantes
Pour améliorer la sécurité des ponts, il est utile de comprendre les vulnérabilités courantes des ponts et de tester les ponts avant de les lancer. Ces vulnérabilités peuvent être classées en quatre types comme suit.
Faible authentification en chaîne
Pour les ponts simples, en particulier ceux conçus pour des DApp spécifiques, la validation en chaîne est souvent minime. Ces ponts s'appuient sur un backend centralisé pour effectuer 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 ce cas, 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 de dépôt, utilisée pour vérifier la demande de retrait d'un utilisateur sur une autre chaîne. Ce processus sera en mesure de prévenir diverses attaques de sécurité, notamment les attaques par rejeu et les faux enregistrements de dépôt.
Cependant, s’il existe des vulnérabilités dans le processus d’authentification en chaîne, un attaquant peut causer de graves dommages. Par exemple, si un pont utilise une arborescence Merkle pour authentifier les enregistrements de transactions, un attaquant pourrait créer des preuves falsifiées. Cela signifie qu'ils peuvent contourner l'authentification par preuve et créer de nouveaux jetons sur leurs comptes si le processus d'authentification 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 libérée sur la chaîne BNB.
Cependant, si cette transaction n'est pas correctement authentifiée, un attaquant peut déployer un contrat malveillant pour acheminer les jetons encapsulés du pont vers une adresse incorrecte en manipulant la fonctionnalité.
Les attaquants ont également besoin que la victime approuve le contrat relais pour transférer les jetons en utilisant la fonction « transferFrom » pour retirer les actifs du contrat relais.
Malheureusement, la situation est encore pire car de nombreux ponts nécessitent une approbation illimitée des jetons de la part des utilisateurs de DApp. Il s'agit d'une méthode populaire qui réduit les frais de gaz mais crée un risque supplémentaire en permettant au contrat intelligent d'accéder à un nombre illimité de jetons depuis le portefeuille de l'utilisateur. Les attaquants peuvent exploiter le manque d’authentification et les approbations excessives pour leur transférer des jetons d’autres utilisateurs.
Faible authentification 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 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 authentification hors chaîne fonctionne comme suit :
Les utilisateurs interagissent avec le DApp pour déposer des jetons dans un contrat intelligent sur la chaîne source.
Ce DApp envoie ensuite la chaîne de hachage de la transaction de dépôt au serveur backend via l'API.
La chaîne de hachage de transaction est soumise à une validation du serveur. S'il est jugé légitime, le signataire signe un message et renvoie la signature à l'interface utilisateur via l'API.
Dès réception d'une signature, le DApp la vérifiera et permettra aux utilisateurs de retirer leurs jetons de la chaîne cible.
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 les utilisateurs peuvent 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 ignoré, un attaquant peut déployer un contrat malveillant pour simuler 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ère qu'il s'agit d'une transaction valide et signe le message. L'attaquant peut ensuite 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 ont différentes approches pour gérer les jetons natifs et les jetons utilitaires. Par exemple, sur le réseau Ethereum, les tokens natifs sont des ETH et la plupart des tokens utilitaires sont conformes à la norme ERC-20.
Lorsque les utilisateurs ont l’intention de transférer leur ETH vers une autre chaîne, ils doivent d’abord le déposer dans le contrat relais. Pour y parvenir, les utilisateurs doivent simplement attacher l'ETH à la transaction et le montant de l'ETH peut être obtenu en lisant le champ « msg.value » de la transaction.
L’envoi de jetons ERC-20 est très différent de l’envoi d’ETH. Pour déposer un jeton ERC-20, les utilisateurs doivent d'abord autoriser le contrat de pont à dépenser leurs jetons. Une fois qu'ils ont approuvé cela et déposé les jetons dans le contrat de transition, 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 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 situation. 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 des adresses de jetons 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 un moyen populaire d'atténuer les risques. Seules les adresses sur liste blanche peuvent être transmises comme arguments. Cela évite les appels externes car l’équipe du projet a filtré les adresses des jetons.
Cependant, des problèmes peuvent également survenir lorsque les ponts gèrent les transferts inter-chaînes de jetons natifs, car les jetons natifs n'ont pas d'adresse. Le numéro d'adresse 0 (0x000...0) représente le jeton d'origine. Cela peut être problématique car transmettre l'adresse 0 à 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, 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'effectuer des transactions 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 importantes. Il est crucial de s’assurer que toutes les configurations sont correctes, car même des erreurs apparemment minimes peuvent entraîner des pertes importantes.
En fait, il y a eu un problème où un attaquant a réussi à contourner la vérification des enregistrements de transfert en raison d'une mauvaise configuration. L'équipe du projet a effectué une mise à niveau du protocole quelques jours avant le piratage, ce qui impliquait de modifier une variable. Variable utilisée pour représenter la valeur par défaut d'un message approuvé. Ce changement fait que tous les messages sont automatiquement considérés comme prouvés, permettant ainsi à un attaquant d'envoyer un message arbitraire et de contourner le processus de vérification.
Comment améliorer la sécurité des ponts
Les quatre vulnérabilités de pontage courantes 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 remédier à 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, car chaque pont a ses propres exigences de vérification. 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 une logique de vérification appropriée.
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 des ponts.
résumé
En raison de leur valeur élevée, les ponts inter-chaînes ont longtemps été une cible pour les attaquants. Les développeurs peuvent accroître la sécurité de leurs ponts en effectuant des tests approfondis avant le déploiement et en faisant appel à des tiers pour participer à l'audit, afin de réduire le risque d'attaques dévastatrices, qui ont frappé les ponts au cours des dernières années. Les ponts sont des composants très importants dans un monde multi-chaînes, mais la sécurité doit être une préoccupation majeure pour concevoir et construire une infrastructure Web3 efficace.
En savoir plus:
Qu’est-ce qu’un pont Blockchain ?
Qu’est-ce que l’interopérabilité inter-chaînes ?
Trois ponts de crypto-monnaie populaires et comment ils fonctionnent
Que sont les jetons enveloppé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, ni comme une recommandation d’acheter un produit ou un service spécifique. Vous devriez demander votre propre avis à des conseillers professionnels appropriés. Dans les cas où les articles proviennent de contributeurs tiers, veuillez noter que les opinions exprimées appartiennent au 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 fluctuer. La valeur de votre investissement peut augmenter ou diminuer et vous ne récupérerez peut-être pas le montant que vous avez 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 matériel 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.