Quelles sont les vulnérabilités les plus courantes en matiÚre de sécurité des passerelles ?
Accueil
Articles
Quelles sont les vulnérabilités les plus courantes en matiÚre de sécurité des passerelles ?

Quelles sont les vulnérabilités les plus courantes en matiÚre de sécurité des passerelles ?

Avancé
Publié le Mar 22, 2023Mis à jour le Jun 15, 2023
9m

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 : 

  1. Les utilisateurs et utilisatrices interagissent avec la DApp pour déposer des tokens dans le smart contract sur la blockchain source.

  2. La 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. 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.