Vulnérabilités dans la sécurité des bridges

Obtenir l'interopérabilité dans l'écosystème blockchain nécessite la présence de bridges blockchain, qui jouent un rôle crucial. Par conséquent, il est essentiel de prioriser la sécurité de ces bridges. Discutons-en dans notre blog.

Notions de base

Les faiblesses dans la sécurité des bridges impliquent souvent une validation on-chain et off-chain insuffisante, une gestion inappropriée des tokens natifs et des erreurs de configuration. Pour garantir une logique de vérification robuste, il est conseillé de tester soigneusement le bridge contre divers vecteurs d'attaque.

Qu'est-ce qu'un bridge blockchain ?

Un bridge blockchain permet les interactions entre deux blockchains ; il s'agit d'un protocole facilitant une connectivité transparente. Supposons que vous possédiez du Bitcoin mais souhaitiez participer à des opérations DeFi sur le réseau Ethereum. Dans ce cas, un bridge blockchain vous permet de prendre part à ces activités sans liquider vos avoirs en Bitcoin.

Les bridges blockchain fonctionnent en mettant en œuvre diverses mécanismes de validation on-chain et off-chain, essentiels pour atteindre l'interopérabilité dans le domaine blockchain. Par conséquent, ils présentent des vulnérabilités spécifiques en matière de sécurité.

Pourquoi la sécurité des bridges est-elle importante ?

Selon les estimations du secteur, les attaques contre les bridges ont causé environ 1,3 milliard USD de pertes en 2022, représentant 36 % des pertes totales de cette année-là. Ces attaques ciblent principalement les applications cross-chain, car les bridges, souvent implémentés sous forme de smart contracts, accumulent des tokens importants lors des transferts entre chaînes. Ainsi, les bridges deviennent des cibles attrayantes pour les pirates en raison de leur valeur élevée.

De plus, les bridges blockchain comprennent de nombreux composants, offrant une surface d'attaque considérable. Les acteurs malveillants sont fortement incités à exploiter les vulnérabilités de ces bridges pour détourner des fonds significatifs.

Vulnérabilités associées aux bridges

Pour renforcer la sécurité des bridges, il est crucial de comprendre les vulnérabilités courantes pouvant apparaître dans leur conception. Avant leur lancement, il est conseillé de soumettre les bridges à des tests approfondis afin d'identifier et corriger ces failles. Ces risques de sécurité peuvent être classés en plusieurs catégories.

La validation on-chain est réduite pour certains bridges, notamment ceux conçus pour des applications décentralisées (DApps) spécifiques. Ces bridges s'appuient sur un backend centralisé pour exécuter des opérations fondamentales comme le mint, le burn et les transferts de tokens. Pendant ce temps, les processus de validation sont effectués off-chain.

À l'inverse, d'autres bridges utilisent des smart contracts pour valider des messages et effectuer des vérifications on-chain. Lorsqu'un utilisateur initie un dépôt de fonds sur une chaîne, le smart contract génère un message signé et inclut la signature dans la transaction. 

Cette signature sert de preuve du dépôt et est ensuite utilisée pour authentifier la demande de retrait de l'utilisateur sur la chaîne cible. Ce processus robuste atténue les attaques potentielles, y compris les attaques par rejeu et les enregistrements de dépôt falsifiés.

Toutefois, si une vulnérabilité existe lors de la phase de validation on-chain, un attaquant peut l'exploiter pour causer des dégâts importants. Par exemple, dans le cas d'un bridge utilisant un arbre de Merkle pour valider les enregistrements de transactions, un attaquant pourrait fabriquer de faux proofs. Cette action malveillante lui permettrait de contourner la validation des preuves et de créer illicitement de nouveaux tokens sur son compte, exploitant la faiblesse du processus de validation.

« Wrapped tokens » et sécurité des bridges

L'intégration des soi-disant « wrapped tokens » est une stratégie courante employée par certains bridges. Par exemple, lorsqu'un utilisateur transfère des DAI de la blockchain Ethereum vers la BNB Chain, ses DAI sont retirés du contrat Ethereum et une quantité équivalente de DAI emballés (wrapped DAI) est ensuite générée sur la BNB Chain.

Cependant, si la validation de cette transaction est insuffisante, cela ouvre la porte aux attaquants potentiels. En déployant un contrat malveillant et en manipulant ses fonctions, ces attaquants peuvent détourner les wrapped tokens du bridge vers une adresse non prévue.

Pour réaliser une telle attaque, les auteurs comptent sur le fait que les victimes approuvent le contrat du bridge, autorisant le transfert de tokens via la fonction "transferFrom". Cela leur permet de vider les actifs du contrat du bridge.

Malheureusement, cette situation est aggravée par la pratique utilisée par de nombreux bridges qui demandent une approbation infinie des tokens par les utilisateurs des applications décentralisées. Bien que cette approche puisse réduire les frais de gas, elle introduit des risques supplémentaires en permettant à un smart contract d'accéder à un nombre illimité de tokens depuis le portefeuille d'un utilisateur. En exploitant l'absence d'une validation adéquate et l'approbation excessive accordée, les attaquants peuvent siphonner des tokens d'utilisateurs imprudents vers leurs propres comptes.

Validation off-chain faible et sécurité des bridges

Dans certains systèmes de bridge, le serveur backend off-chain joue un rôle critique dans la vérification de la légitimité des messages envoyés depuis la blockchain. Dans cet exemple, nous nous concentrons sur la vérification des transactions de dépôt. 

Un bridge avec validation off-chain fonctionne comme suit : 

• Les utilisateurs interagissent avec la DApp pour déposer des tokens dans le smart contract sur la chaîne source.
• La DApp envoie alors le hash de la transaction de dépôt au serveur backend via une API.
• Le hash de la transaction fait l'objet de plusieurs validations par le serveur. Si elle est jugée légitime, un signataire signe un message et envoie la signature à l'interface utilisateur via l'API.
• Après réception de la signature, la DApp la vérifie et autorise l'utilisateur à retirer ses tokens depuis la chaîne source.

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 détermine si un utilisateur peut retirer des tokens 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 point est négligé, un attaquant pourrait déployer un contrat malveillant pour falsifier un événement de dépôt ayant la même structure qu'un événement légitime. 

Si le serveur backend ne vérifie pas quelle adresse a émis l'événement, il considérerait la transaction comme valide et signerait le message. L'attaquant pourrait alors envoyer le hash de la transaction au backend, en contournant la vérification et lui permettant de retirer les tokens sur la chaîne cible.

Mauvaise gestion des tokens natifs

Les bridges emploient différentes approches pour traiter les tokens natifs et les tokens utilitaires. Sur le réseau Ethereum, le token natif est l'ETH, tandis que la plupart des tokens utilitaires respectent la norme ERC-20. Les utilisateurs doivent d'abord déposer de l'ETH dans le contrat du bridge pour le transférer vers une autre chaîne. Cela se fait en attachant l'ETH à la transaction et en récupérant le montant depuis le champ "msg.value".

Le dépôt de tokens ERC-20 diffère sensiblement du dépôt d'ETH. Pour les dépôts de tokens ERC-20, les utilisateurs doivent autoriser le contrat du bridge à dépenser leurs tokens. Une fois les tokens déposés, le contrat brûlera les tokens de l'utilisateur via la fonction "burnFrom()" ou transférera les tokens vers le contrat en utilisant la fonction "transferFrom()".

Il existe différentes approches pour distinguer ces deux scénarios. Une méthode utilise une instruction if-else dans la même fonction, tandis qu'une autre utilise des fonctions séparées pour chaque cas. Il est crucial de ne pas tenter de déposer de l'ETH en utilisant la fonction de dépôt ERC-20, car cela peut entraîner la perte de fonds.

Lors du traitement des demandes de dépôt ERC-20, les utilisateurs fournissent généralement l'adresse du token en tant qu'argument de la fonction de dépôt. Cependant, cela présente un risque car des appels externes non fiables peuvent survenir pendant la transaction. Pour atténuer ce risque, une pratique courante consiste à implémenter une whitelist contenant uniquement les tokens pris en charge par le bridge. En n'autorisant que des adresses figurant sur la whitelist comme arguments, les appels externes sont évités puisque l'équipe du projet a déjà filtré les adresses de tokens.

Toutefois, des problèmes peuvent survenir lorsque les bridges gèrent les transferts cross-chain de tokens natifs, car les tokens natifs n'ont pas d'adresse. À la place, une adresse nulle (0x000...0) représente le token natif. Cela peut être problématique car le passage de l'adresse nulle à la fonction peut contourner la vérification de la whitelist, même si celle-ci est mal implémentée.

Dans les cas où le contrat du bridge appelle "transferFrom" pour transférer les actifs de l'utilisateur vers le contrat, un appel externe vers l'adresse nulle renverra false puisque l'adresse nulle n'implémente pas de fonction "transferFrom". Cependant, si le contrat ne gère pas correctement la valeur de retour, la transaction peut toujours se produire sans transférer de tokens vers le contrat. Cela permet aux attaquants d'exécuter des transactions sans transférer de tokens au contrat.

Risques de mauvaise configuration en sécurité blockchain

La responsabilité de la gestion des whitelists ou blacklists de tokens et d'adresses, de l'attribution ou du changement des signataires et d'autres configurations critiques dans la plupart des bridges blockchain revient à un rôle privilégié. Une configuration correcte est essentielle, car même de petites négligences peuvent avoir des conséquences importantes.

Un attaquant a exploité une mauvaise configuration pour contourner la vérification des enregistrements de transfert. L'équipe du projet a mis en œuvre une mise à niveau du protocole impliquant la modification d'une variable. Cette variable représentait la valeur par défaut du message de confiance. Ce changement a entraîné la validation automatique des messages, permettant à l'attaquant de soumettre n'importe quel message et de réussir la vérification.

Renforcer la sécurité des bridges

Traiter les défis de sécurité dans un écosystème blockchain interconnecté nécessite de comprendre les quatre vulnérabilités communes des bridges évoquées précédemment. Chaque vulnérabilité présente ses propres considérations, et il n'existe pas de solution universelle.

Lorsqu'il s'agit d'établir des processus de vérification sans erreur, il est difficile de fournir des directives génériques en raison des exigences de vérification variables de chaque bridge. La stratégie la plus efficace consiste à effectuer des tests complets pour identifier et atténuer les vecteurs d'attaque potentiels tout en garantissant l'intégrité de la logique de vérification. En conclusion, des tests rigoureux contre les attaques potentielles et une approche ciblée pour traiter les vulnérabilités de sécurité répandues dans les bridges sont essentiels pour maintenir un environnement sécurisé.

Conclusion 

Les bridges cross-chain ont longtemps été des cibles pour les attaquants en raison de leur valeur considérable. Les développeurs peuvent réduire le risque des cyberattaques graves qui ont frappé les bridges ces dernières années en réalisant des tests préalables au déploiement et en participant à des audits tiers. Les bridges sont essentiels dans un monde multi-chaînes, mais lors du développement et de la construction d'une infrastructure Web3, la sécurité doit primer.