Quels sont les vulnérabilités courantes de sécurité des ponts inter-chaînes ?

Résumé

Les ponts blockchain sont à la base de l’interopérabilité dans le domaine de la blockchain. Par conséquent, la sécurité des ponts inter-chaînes est cruciale. Parmi les vulnérabilités courantes des ponts blockchain, on trouve une validation insuffisante en chaîne et hors chaîne, une mauvaise gestion des tokens natifs et des erreurs de configuration. Afin d’assurer une logique de validation raisonnable, il est recommandé de tester le pont inter-chaînes contre toutes les éventualités d’attaque possibles.

Introduction

Les ponts blockchain sont des protocoles qui relient deux blockchains pour permettre leur interaction. Grâce aux ponts blockchain, les utilisateurs souhaitant participer aux activités DeFi sur le réseau Ethereum, par exemple, peuvent simplement détenir des bitcoins sans avoir à les vendre.

Les ponts blockchain constituent la fondation de l’interopérabilité dans le domaine de la blockchain. Ils utilisent diverses validations en chaîne et hors chaîne, ce qui peut également leur faire courir certains risques de sécurité.

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

Les ponts blockchain détiennent généralement des tokens que les utilisateurs souhaitent transférer d’une chaîne à une autre. Ces ponts sont souvent déployés sous forme de contrats intelligents. Avec l’accumulation continue de transferts inter-chaînes, ils détiennent une grande quantité de tokens, ce qui en fait des cibles de choix pour les hackers.

De plus, en raison de la complexité de leurs composants, la surface d’attaque des ponts blockchain est souvent très grande. Par conséquent, les acteurs malveillants ont un fort intérêt à cibler ces applications pour s’emparer de fonds importants.

Selon l’estimation de CertiK, en 2022, les attaques contre les ponts blockchain ont causé des pertes de plus de 1,3 milliard de dollars, représentant 36 % des pertes totales de l’année.

Vulnérabilités courantes dans la sécurité des ponts inter-chaînes

Pour renforcer la sécurité des ponts blockchain, il est essentiel de connaître les vulnérabilités courantes et de tester ces ponts avant leur déploiement. Ces vulnérabilités proviennent principalement de quatre aspects :

Validation en chaîne insuffisante

Pour les ponts simples, notamment ceux conçus pour des dApps spécifiques, la validation en chaîne est généralement minimale. Ces ponts s’appuient sur un backend centralisé pour effectuer des opérations de base telles que la frappe, la destruction et le transfert de tokens, toutes ces validations étant effectuées hors chaîne.

D’autres types de ponts utilisent des contrats intelligents pour valider les messages et effectuer des vérifications en chaîne. Dans ce cas, lorsque l’utilisateur dépose des fonds, le contrat intelligent génère un message signé et le renvoie dans la transaction. Cette signature sert de preuve de dépôt, permettant de valider la demande de retrait sur une autre chaîne. Ce processus doit pouvoir prévenir diverses attaques, telles que la relecture ou la falsification de l’historique des dépôts.

Cependant, si la validation en chaîne comporte des vulnérabilités, cela peut entraîner des pertes graves. Par exemple, si la validation utilise un arbre de Merkle pour vérifier les transactions, un attaquant pourrait générer une preuve falsifiée. Cela signifie que si la validation est vulnérable, un attaquant pourrait contourner la vérification et frapper de nouveaux tokens dans son compte.

Certains ponts utilisent le concept de « tokens emballés (wrapped tokens) ». Par exemple, lorsque l’utilisateur transfère des DAI d’Ethereum vers BNB Chain, ses DAI sont retirés du contrat Ethereum et une quantité équivalente de DAI emballés est émise sur BNB Chain.

Mais si cette opération n’est pas correctement vérifiée, un attaquant pourrait déployer un contrat malveillant, manipuler cette fonction et faire en sorte que les tokens emballés soient routés vers une adresse erronée.

De plus, l’attaquant doit obtenir l’autorisation préalable du contrat du pont pour utiliser la fonction « TransferFrom » et transférer des tokens, ce qui lui permettrait de siphonner des actifs du contrat.

Le problème, c’est que de nombreux ponts demandent aux utilisateurs d’approuver indéfiniment le contrat du dApp pour les tokens, une pratique courante qui réduit les coûts de transaction mais permet au contrat d’accéder à une quantité illimitée de tokens dans le portefeuille de l’utilisateur. Cela augmente le risque. Les attaquants peuvent exploiter ces validations insuffisantes et cette approbation excessive pour transférer des tokens d’autres utilisateurs à leur propre profit.

Validation hors chaîne insuffisante

Dans certains systèmes de ponts inter-chaînes, un serveur backend hors chaîne joue un rôle crucial dans la validation de la légitimité des messages envoyés depuis la blockchain. Dans ce cas, la validation des transactions de dépôt est particulièrement critique.

Le fonctionnement d’un pont avec validation hors chaîne est le suivant :

L’utilisateur interagit avec la dApp, déposant des tokens dans un contrat intelligent sur la chaîne source.

Ensuite, la dApp envoie via API le hash de la transaction de dépôt au serveur backend.

Ce hash doit être validé plusieurs fois par le serveur. Si la transaction est jugée légitime, le signataire signe un message, qui est renvoyé à l’interface utilisateur via API.

Une fois le message reçu, la dApp le vérifie et autorise l’utilisateur à retirer des tokens sur la chaîne cible.

Le serveur backend doit s’assurer que la transaction de dépôt est authentique et non falsifiée. C’est lui qui décide si l’utilisateur peut retirer des tokens sur la chaîne cible, ce qui en fait une cible privilégiée pour les attaques.

Le serveur doit valider la structure de l’événement de dépôt ainsi que l’adresse du contrat qui a initié cet événement. Si cette dernière est ignorée, un attaquant pourrait déployer un contrat malveillant pour falsifier un événement de dépôt identique à un dépôt légitime.

Si le serveur ne vérifie pas l’adresse qui a initié l’événement, il pourrait considérer la transaction comme valide et signer le message. L’attaquant pourrait alors envoyer le hash de la transaction au serveur, contourner la validation et retirer des tokens sur la chaîne cible.

Gestion inadéquate des tokens natifs

Les ponts inter-chaînes utilisent différentes méthodes pour gérer les tokens natifs et les tokens utilitaires. Par exemple, sur le réseau Ethereum, le token natif est ETH, et la plupart des tokens utilitaires respectent la norme ERC-20.

Si l’utilisateur souhaite transférer ses ETH vers une autre chaîne, il doit d’abord les déposer dans le contrat du pont. Pour cela, il suffit d’attacher ETH à la transaction, en lisant le champ « msg.value ».

Le dépôt de tokens ERC-20 est très différent. L’utilisateur doit d’abord autoriser le contrat du pont à utiliser ses tokens. Après avoir approuvé et déposé ses tokens, le contrat les brûle via la fonction « burnFrom( » ou transfère ses tokens dans le contrat avec « transferFrom) ».

Pour distinguer ces opérations, on peut utiliser une instruction if-else dans la même fonction ou créer deux fonctions séparées pour chaque scénario. En raison de leur traitement différent, si l’utilisateur tente d’utiliser la fonction de dépôt ERC-20 pour déposer des ETH, ces ETH pourraient être perdus.

Lors du traitement des requêtes de dépôt ERC-20, l’utilisateur fournit généralement l’adresse du token en paramètre. Cela comporte un risque important, car des appels externes non fiables peuvent se produire durant la transaction. L’utilisation d’une liste blanche contenant uniquement les tokens supportés par le pont est une pratique courante pour minimiser ce risque. Seules les adresses en liste blanche sont transmises en paramètre, ce qui empêche les appels externes non contrôlés, car l’équipe du projet a filtré ces adresses.

Cependant, lors du transfert de tokens natifs via un pont inter-chaînes, un problème survient : ces tokens n’ont pas d’adresse. On peut utiliser une adresse spéciale pour représenter le token natif, par exemple « zéro adresse (0x000…) ». Mais cela pose un problème : si la logique de validation de la liste blanche n’est pas correctement implémentée, transmettre la zero adresse à la fonction pourrait contourner cette validation.

Lorsque le contrat du pont appelle « TransferFrom » pour transférer des actifs utilisateur vers le contrat, l’appel externe à la zero adresse retourne false, car cette adresse ne possède pas la fonction « transferFrom ». Mais si le contrat ne gère pas correctement cette valeur de retour, la transaction peut continuer. Cela donne une opportunité à l’attaquant de réaliser une transaction sans transférer de tokens vers le contrat.

Erreur de configuration

Dans la majorité des ponts blockchain, un rôle privilégié est responsable de l’ajout ou du retrait de tokens et d’adresses dans la liste blanche ou noire, de l’attribution ou de la modification des signataires, ainsi que d’autres configurations clés. Assurer la précision de toutes ces configurations est essentiel, car une erreur apparemment mineure peut entraîner des pertes importantes.

En réalité, des attaques ont déjà réussi à contourner la validation des enregistrements de transfert suite à une erreur de configuration. Par exemple, une équipe a effectué une mise à jour du protocole quelques jours avant une attaque, modifiant une variable représentant la valeur par défaut des messages de confiance. Ce changement a conduit à considérer tous les messages comme vérifiés par défaut, permettant à un attaquant de soumettre n’importe quel message et de le faire passer pour légitime.

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

Les quatre vulnérabilités courantes évoquées ci-dessus montrent que la sécurité dans l’écosystème blockchain interconnecté est un défi de taille. Pour y faire face, il faut adopter une approche adaptée à chaque cas, car aucune méthode universelle ne peut couvrir tous les scénarios.

Par exemple, chaque pont inter-chaînes ayant ses propres exigences de validation, il est difficile d’assurer une validation sans erreur en se contentant de règles générales. La méthode la plus efficace pour prévenir la contournement de validation consiste à tester exhaustivement le pont contre toutes les éventualités d’attaque possibles et à s’assurer que la logique de validation est raisonnable.

En résumé, il est indispensable de tester rigoureusement contre toutes les attaques potentielles et de prêter une attention particulière aux vulnérabilités de sécurité les plus courantes dans les ponts inter-chaînes.

Conclusion

En raison de l’ampleur des fonds en jeu, les ponts inter-chaînes sont depuis longtemps des cibles privilégiées pour les attaques. Les développeurs peuvent renforcer leur sécurité en effectuant des tests complets avant déploiement et en intégrant des audits tiers, ce qui réduit le risque de cyberattaques catastrophiques qui ont frappé ces ponts ces dernières années. Les ponts inter-chaînes sont essentiels dans un monde multi-chaînes, mais leur conception et leur construction doivent faire de la sécurité une priorité absolue. ($STO