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.
Résumé
Les passerelles blockchain sont fondamentales pour atteindre lâinteropĂ©rabilitĂ© dans lâespace blockchain. La sĂ©curitĂ© des passerelles est donc dâune importance capitale. Parmi les vulnĂ©rabilitĂ©s les plus courantes en matiĂšre de sĂ©curitĂ© des passerelles, on peut citer la faiblesse de la validation sur et hors de la blockchain, la mauvaise gestion des tokens natifs et les mauvaises configurations. Il est recommandĂ© de tester la passerelle contre tous les vecteurs dâattaque possibles afin de garantir une logique de vĂ©rification solide.
IntroductionÂ
Une passerelle blockchain est un protocole reliant deux blockchains pour permettre les interactions entre elles. Si vous possĂ©dez des bitcoins mais que vous souhaitez participer Ă une activitĂ© DeFi sur le rĂ©seau Ethereum, une passerelle blockchain vous permet de le faire sans vendre vos bitcoins.Â
Les passerelles blockchain sont fondamentales pour atteindre lâinteropĂ©rabilitĂ© dans lâespace blockchain. Elles fonctionnent Ă lâaide de diverses validations sur et hors de la blockchain et prĂ©sentent donc des vulnĂ©rabilitĂ©s diffĂ©rentes en matiĂšre de sĂ©curitĂ©.
Pourquoi la sĂ©curitĂ© des passerelles est-elle essentielle ?Â
Une passerelle contient gĂ©nĂ©ralement le token quâun(e) utilisateur/utilisatrice souhaite transfĂ©rer dâune blockchain Ă une autre. Souvent dĂ©ployĂ©es sous la forme de smart contracts, les passerelles dĂ©tiennent une quantitĂ© importante de tokens Ă mesure que les transferts entre blockchains sâaccumulent, ce qui en fait des cibles de choix pour les pirates informatiques.Â
En outre, les passerelles blockchain ont une grande surface dâattaque car elles impliquent de nombreux composants. Câest pourquoi les acteurs malveillants sont trĂšs motivĂ©s pour cibler les applications inter-blockchains afin de voler de grosses sommes dâargent.Â
Les attaques de passerelles ont entraĂźnĂ© des pertes de plus de 1,3 milliard de dollars amĂ©ricains en 2022, ce qui reprĂ©sente 36 % des pertes totales de lâannĂ©e, selon les estimations de CertiK.Â
Vulnérabilités de sécurité communes pour les passerelles
Pour renforcer la sĂ©curitĂ© des passerelles, il est utile de comprendre les vulnĂ©rabilitĂ©s les plus courantes et de les tester avant leur mise en service. Ces vulnĂ©rabilitĂ©s peuvent ĂȘtre classĂ©es dans les quatre catĂ©gories suivantes.Â
Faiblesse de la validation sur la blockchain
Pour les passerelles simples, en particulier celles qui sont conçues pour des DApps spĂ©cifiques, la validation sur la blockchain est rĂ©duite au minimum. Ces passerelles sâappuient sur un backend (application dorsale) centralisĂ© pour exĂ©cuter les opĂ©rations de base telles que lâĂ©mission, le burn et les transferts de tokens, tandis que toutes les vĂ©rifications sont effectuĂ©es hors de la blockchain.
En revanche, dâautres types de passerelles utilisent des smart contracts pour valider les messages et effectuer des vĂ©rifications sur la blockchain. Dans ce scĂ©nario, lorsquâun(e) utilisateur/utilisatrice dĂ©pose des fonds sur une blockchain, le smart contract gĂ©nĂšre un message signĂ© et renvoie la signature dans la transaction. Cette signature sert de preuve de dĂ©pĂŽt et est utilisĂ©e pour vĂ©rifier la demande de retrait de lâutilisateur/lâutilisatrice sur lâautre blockchain. Ce processus doit permettre de prĂ©venir diverses attaques de sĂ©curitĂ©, notamment les attaques par rejeu et les faux enregistrements de dĂ©pĂŽts.Â
Cependant, sâil existe une vulnĂ©rabilitĂ© au cours du processus de validation sur la blockchain, lâattaquant peut causer de graves dommages. Par exemple, si une passerelle utilise un arbre de Merkle pour valider la transaction, un pirate peut gĂ©nĂ©rer de fausses preuves. Cela signifie quâils peuvent contourner la validation de la preuve et Ă©mettre de nouveaux tokens sur leur compte si le processus de validation est vulnĂ©rable.
Certaines passerelles mettent en Ćuvre le concept de « tokens wrappĂ©s ». Par exemple, lorsquâun(e) utilisateur/utilisatrice transfĂšre un DAI dâEthereum Ă la BNB Chain, son DAI est prĂ©levĂ© du contrat Ethereum et un montant Ă©quivalent de DAI wrappĂ© est Ă©mis sur la BNB Chain.Â
Cependant, si cette transaction nâest pas correctement validĂ©e, un pirate pourrait dĂ©ployer un contrat malveillant pour acheminer les tokens wrappĂ©s de la passerelle vers une adresse incorrecte en manipulant cette fonctionnalitĂ©.Â
Les pirates ont Ă©galement besoin que les victimes approuvent le contrat de la passerelle pour transfĂ©rer des tokens Ă lâaide de la fonction « transferFrom » afin de drainer les actifs du contrat de la passerelle.Â
Malheureusement, cette situation est aggravĂ©e par le fait que de nombreuses passerelles demandent aux utilisateurs et utilisatrices de DApp dâapprouver des tokens Ă lâinfini. Il sâagit dâune pratique courante qui rĂ©duit les frais de gas, mais qui crĂ©e des risques supplĂ©mentaires en permettant Ă un smart contract dâaccĂ©der Ă un nombre illimitĂ© de tokens du portefeuille de lâutilisateur ou lâutilisatrice. Les pirates sont en mesure dâexploiter lâabsence de validation et lâapprobation excessive pour transfĂ©rer des tokens dâautres utilisateurs et utilisatrices sur leurs propres comptes.
Faiblesse de la validation hors de la blockchain
Dans certains systĂšmes de passerelles, le serveur backend hors blockchain joue un rĂŽle essentiel dans la vĂ©rification de la lĂ©gitimitĂ© des messages envoyĂ©s par la blockchain. Dans le cas prĂ©sent, nous nous concentrons sur la vĂ©rification des opĂ©rations de dĂ©pĂŽt.Â
Une passerelle blockchain avec validation hors blockchain fonctionne comme suit :Â
Les utilisateurs et utilisatrices interagissent avec la DApp pour déposer des tokens dans le smart contract sur la blockchain source.
La DApp envoie ensuite le hachage de la transaction de dépÎt au serveur backend via une API.
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.
Lorsquâelle reçoit la signature, la DApp la vĂ©rifie et autorise lâutilisateur ou lâutilisatrice Ă retirer ses tokens de la blockchain source.
Le serveur backend doit sâassurer que la transaction de dĂ©pĂŽt quâil traite a bien eu lieu et quâelle nâa pas Ă©tĂ© falsifiĂ©e. Ce serveur backend dĂ©termine si un(e) utilisateur/utilisatrice peut retirer des tokens sur la blockchain cible et constitue donc une cible de grande valeur pour les pirates.
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 point est nĂ©gligĂ©, un pirate pourrait dĂ©ployer un contrat malveillant pour falsifier 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 quâil sâagit dâune transaction valide et signera le message. Le pirate peut alors envoyer le hachage de la transaction au backend, contournant ainsi la vĂ©rification et lui permettant de retirer les tokens de la blockchain cible.
Mauvaise gestion des tokens natifs
Les passerelles adoptent des approches diffĂ©rentes pour gĂ©rer les tokens natifs et les tokens utilitaires. Par exemple, sur le rĂ©seau Ethereum, le token natif est lâETH et la plupart des tokens utilitaires suivent la norme ERC-20.Â
Lorsquâun(e) utilisateur/utilisatrice souhaite transfĂ©rer ses ETH vers une autre blockchain, il ou elle doit dâabord le dĂ©poser dans le contrat de la passerelle. Pour ce faire, lâutilisateur ou lâutilisatrice 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 tokens ERC-20 diffĂšre considĂ©rablement du dĂ©pĂŽt dâETH. Pour dĂ©poser un token ERC-20, lâutilisateur ou lâutilisatrice doit dâabord autoriser le contrat de passerelle Ă dĂ©penser ses tokens. AprĂšs approbation et dĂ©pĂŽt des tokens dans le contrat de la passerelle, ce dernier va burn les tokens de lâutilisateur/de lâutilisatrice Ă lâaide de la fonction « burnFrom() » ou transfĂ©rera les tokens de lâutilisateur/de lâutilisatrice vers le contrat Ă lâaide de la fonction « transferFrom() ».Â
Une approche pour diffĂ©rencier cela est dâutiliser une instruction si alors (if-else) au sein de 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 en utilisant la fonction de dĂ©pĂŽt de lâERC-20 peut entraĂźner la perte des fonds.
Lors du traitement des demandes de dĂ©pĂŽt ERC-20, les utilisateurs et utilisatrices fournissent gĂ©nĂ©ralement lâadresse du token en entrĂ©e de la fonctionnalitĂ© de dĂ©pĂŽt. Cela prĂ©sente un risque important, car des appels externes non fiables peuvent avoir lieu pendant la transaction. La mise en Ćuvre dâune liste blanche qui nâinclut que les tokens pris en charge par la passerelle est une pratique courante pour minimiser les risques. Seules les adresses figurant sur la liste blanche peuvent ĂȘtre transmises en tant quâarguments. Cela permet dâĂ©viter les appels externes car lâĂ©quipe projet a dĂ©jĂ appliquĂ© un filtre sur lâadresse du token.
Toutefois, des problĂšmes peuvent Ă©galement survenir lorsque les passerelles gĂšrent le transfert de tokens natifs dâune blockchain Ă une autre, car le token natif nâa pas dâadresse. Une adresse zĂ©ro (0x000...0) est reprĂ©sentative du token natif. Cela peut poser problĂšme, car le fait de transmettre lâadresse zĂ©ro Ă la fonctionn peut permettre de contourner la vĂ©rification de la liste blanche, mĂȘme si elle est mise en Ćuvre de maniĂšre correcte.Â
Lorsque le contrat de la passerelle appelle la fonction « transferFrom » pour transfĂ©rer les actifs de lâutilisateur/lâutilisatrice vers le contrat, lâappel externe Ă lâadresse zĂ©ro renvoie un message faux car il nây a pas de fonction « transferFrom » implĂ©mentĂ©e dans lâadresse zĂ©ro. Toutefois, la transaction peut toujours avoir lieu si le contrat ne gĂšre pas la valeur de retour de maniĂšre appropriĂ©e. Les pirates ont ainsi la possibilitĂ© dâexĂ©cuter la transaction sans transfĂ©rer de tokens au contrat.
Mauvaise configuration
Dans la plupart des passerelles blockchain, un rĂŽle privilĂ©giĂ© est responsable de la mise sur liste blanche ou noire des tokens et des adresses, de lâattribution ou de la modification des signataires et dâautres paramĂ©trages critiques. Il est essentiel de sâassurer que tous les paramĂ©trages sont corrects, car mĂȘme des oublis apparemment insignifiants peuvent entraĂźner des pertes importantes.
Par exemple, il y a eu un incident oĂč le pirate a rĂ©ussi Ă contourner la vĂ©rification de lâenregistrement du transfert en raison dâune mauvaise configuration. LâĂ©quipe du projet a mis en Ćuvre une mise Ă jour 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 de confiance. Cette modification a eu pour effet que tous les messages Ă©taient automatiquement considĂ©rĂ©s comme prouvĂ©s, ce qui permet Ă un pirate de soumettre un message arbitraire et de passer le processus de vĂ©rification.
Comment améliorer la sécurité des passerelles ?
Les quatre vulnĂ©rabilitĂ©s communes expliquĂ©es ci-dessus dĂ©montrent les dĂ©fis Ă relever pour assurer la sĂ©curitĂ© dans un Ă©cosystĂšme blockchain interconnectĂ©. La gestion de chacune de ces vulnĂ©rabilitĂ©s fait lâobjet de considĂ©rations importantes, et il nâexiste pas de mode dâemploi unique applicable Ă toutes ces vulnĂ©rabilitĂ©s.Â
Par exemple, il est difficile de fournir des lignes directrices gĂ©nĂ©rales pour garantir un processus de vĂ©rification sans erreur, car chaque passerelle a des exigences de vĂ©rification qui lui sont propres. Lâapproche la plus efficace pour empĂȘcher le contournement de la vĂ©rification consiste Ă tester minutieusement la passerelle contre tous les vecteurs dâattaque possibles et Ă sâassurer 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 failles de sĂ©curitĂ© les plus courantes des passerelles. Â
Conclusion
En raison de leur valeur Ă©levĂ©e, les passerelles inter-blockchains sont depuis longtemps une cible pour les pirates. Les dĂ©veloppeurs et dĂ©veloppeuses peuvent renforcer la sĂ©curitĂ© de leurs passerelles en effectuant des tests approfondis avant le dĂ©ploiement et en sâengageant dans des audits par des tiers, rĂ©duisant ainsi le risque de piratages dĂ©vastateurs qui ont touchĂ© les passerelles au cours des derniĂšres annĂ©es. Les passerelles sont essentielles dans un monde Ă blockchain multiples, mais la sĂ©curitĂ© doit ĂȘtre une prĂ©occupation majeure lors de la conception et de la mise en place dâune infrastructure Web3 efficace.
Plus dâinformations
Quâest-ce quâune passerelle blockchain ?
Quâest-ce que lâinteropĂ©rabilitĂ© inter-blockchains ?
Trois passerelles crypto populaires et leur fonctionnement
Que sont les tokens wrappés ?
Avis de non-responsabilitĂ© et avertissement concernant les risques : ce contenu vous est prĂ©sentĂ© « tel quel » Ă des fins dâinformation gĂ©nĂ©rale et Ă©ducative uniquement, sans reprĂ©sentation ni garantie dâaucune sorte. Il ne doit pas ĂȘtre interprĂ©tĂ© comme un conseil financier, lĂ©gal ou venant dâun professionnel, ni comme un moyen de recommander lâachat dâun produit ou dâun service spĂ©cifique. Vous devriez vous renseigner auprĂšs des professionnels appropriĂ©s avant toute dĂ©cision. Lorsque lâarticle Ă Ă©tĂ© rĂ©digĂ© par un contributeur tiers, veuillez remarquer que les opinions de lâarticle ne reflĂštent pas nĂ©cessairement celles de Binance Academy. Veuillez lire lâintĂ©gralitĂ© de notre avis de non-responsabilitĂ© ici pour en savoir plus. Les prix des actifs numĂ©riques peuvent ĂȘtre volatils. La valeur de votre investissement peut varier Ă la baisse ou Ă la hausse, et vous ne rĂ©cupĂ©rerez peut-ĂȘtre pas le montant que vous avez investi. Vous ĂȘtes seul(e) responsable de vos dĂ©cisions dâinvestissement et Binance Academy nâest pas responsable des pertes que vous pourriez subir. Ce contenu ne doit pas ĂȘtre interprĂ©tĂ© comme un conseil financier, lĂ©gal, ou venant dâun professionnel. Pour en savoir plus, veuillez vous reporter Ă nos Conditions dâutilisation et Ă lâavertissement concernant les risques.