Qu’est-ce qu’un exploit de bridge cross-chain et comment ces attaques surviennent-elles ?

Qu’est-ce qu’un exploit de bridge cross-chain ?

Un exploit de cross-chain bridge consiste à exploiter une vulnérabilité dans un bridge, une infrastructure qui permet à différentes blockchains de communiquer entre elles. À cause d’une telle vulnérabilité, un attaquant peut par exemple libérer des tokens sans dépôt valide, mint des tokens sans garantie suffisante ou retirer des réserves du bridge.

Un bridge cross-chain permet de déplacer des tokens, des messages ou d’autres données entre des blockchains distinctes. C’est nécessaire, car une blockchain ne peut pas vérifier automatiquement ce qui s’est passé sur une autre blockchain.

Un exploit peut apparaître à différents endroits. Il peut s’agir d’une erreur dans la vérification des messages, de droits d’accès trop larges, d’une vulnérabilité dans des smart contracts ou de clés privées volées à des validateurs ou à des administrateurs. Dans certains bridges, des validateurs confirment par exemple qu’un message provenant d’une blockchain est bien réel et valide avant qu’une action ne soit exécutée sur l’autre blockchain.

Point important à retenir : un bridge ajoute une couche de sécurité supplémentaire au-dessus des blockchains qu’il relie. Dans certains cas, vous faites par exemple confiance à un groupe externe de validateurs ou à un multisig. D’autres bridges utilisent des light clients et des preuves cryptographiques, comme des preuves de Merkle, pour vérifier qu’une transaction ou un événement a bien eu lieu sur l’autre blockchain. Le modèle de sécurité, et donc les risques, peuvent ainsi varier fortement d’un bridge à l’autre.

Une page de phishing pendant l’utilisation d’un bridge n’est d’ailleurs pas automatiquement un exploit de bridge. Une telle page peut vous rediriger vers un contrat malveillant ou vous faire signer une autorisation indésirable, sans que le bridge sous-jacent soit nécessairement compromis.

À retenir

• Un bridge cross-chain permet la communication et le transfert de valeur entre des blockchains distinctes.
• Un exploit de bridge exploite une vulnérabilité technique ou opérationnelle dans un tel bridge.
• Les attaquants peuvent notamment provoquer des paiements non autorisés ou mint des tokens sans garantie suffisante.
• La vérification des messages cross-chain est un point de sécurité essentiel d’un bridge.
• Le modèle de sécurité varie selon le bridge et détermine les risques supplémentaires auxquels les utilisateurs sont exposés.

Comment fonctionne un bridge cross-chain ?

Un bridge cross-chain observe un événement sur la blockchain source et, une fois cet événement vérifié, exécute une action correspondante sur la blockchain cible.

Supposons que vous souhaitiez envoyer un token de la blockchain A vers la blockchain B. La blockchain B ne peut pas vérifier automatiquement que vous avez réellement envoyé ce token depuis la blockchain A. Le bridge doit donc observer et vérifier l’événement sur la blockchain A avant qu’une action ne se produise sur la blockchain B.

Un modèle très utilisé s’appelle lock-and-mint. Vos tokens d’origine sont alors verrouillés sur la blockchain source. Sur la blockchain cible, un wrapped token est ensuite minté : il s’agit d’une représentation du token d’origine. Si vous revenez en arrière, le wrapped token est brûlé et les tokens initiaux peuvent être libérés à nouveau.

Exemple : vous verrouillez 1 token sur la blockchain A. Après vérification, vous recevez 1 wrapped token sur la blockchain B. Votre token d’origine ne voyage donc pas littéralement vers la blockchain B, mais reste verrouillé comme garantie pour le token que vous y recevez.

Une autre approche repose sur des pools de liquidité. Après une transaction vérifiée sur la blockchain source, un pool sur la blockchain cible peut verser une quantité équivalente de tokens.

L’étape cruciale reste toujours la vérification. Le bridge doit par exemple contrôler si un message est authentique, s’il provient de la bonne blockchain, s’il respecte les bonnes conditions et s’il n’a pas déjà été traité. La manière dont cela se fait dépend du bridge.

Certains bridges prennent aussi en charge le generalised message passing. Ils peuvent alors non seulement déplacer des tokens, mais aussi transmettre et exécuter d’autres données ou instructions entre blockchains. Cela offre davantage de possibilités, mais peut aussi élargir la surface d’attaque.

Quels modèles de sécurité différents les bridges utilisent-ils ?

Tous les bridges ne déterminent pas de la même manière si un message est valide. Le modèle de sécurité peut donc varier fortement.

Un bridge peut par exemple s’appuyer sur :

• Des validateurs externes ou des multisigs : un groupe de parties signe les messages avant qu’ils ne soient exécutés sur une autre blockchain.
• Des light clients : une blockchain vérifie des informations cryptographiques sur l’état de l’autre blockchain.
• Des preuves cryptographiques : un bridge utilise par exemple des preuves de Merkle ou d’autres constructions cryptographiques pour démontrer des événements.
• Une vérification optimiste : les messages sont d’abord acceptés, mais une période est prévue pendant laquelle d’autres parties peuvent contester un message invalide.

Ces modèles impliquent des arbitrages différents. Un groupe externe de validateurs peut par exemple être plus simple, mais ajoute une couche de confiance supplémentaire. Un bridge qui vérifie les événements de manière cryptographique présente, lui, d’autres risques techniques. C’est pourquoi le simple mot « bridge » ne dit encore pas grand-chose sur le niveau exact de sécurité du système.

Comment un bridge cross-chain peut-il être attaqué ?

Un attaquant cherche généralement à contourner la vérification du bridge ou à obtenir le pouvoir d’approuver malgré tout un message cross-chain invalide.

L’idée est simple : si la blockchain cible croit à tort que des tokens ont été déposés ou verrouillés sur la blockchain source, le bridge peut par exemple mint de nouveaux tokens ou libérer des réserves sans garantie suffisante en face.

Cela peut se produire de plusieurs façons :

• Une erreur fait qu’un message non prouvé ou falsifié est tout de même accepté.
• Un attaquant met la main sur suffisamment de clés privées de validateurs, de signataires multisig ou d’administrateurs.
• Un bug dans un smart contract saute une vérification importante ou accorde trop de droits à un compte.
• La vérification d’une preuve cryptographique, comme une preuve de Merkle ou une preuve de light client, contient une erreur.
• Une mauvaise configuration ou une mise à jour fait que des messages invalides sont malgré tout traités comme valides.

Une preuve de Merkle est une méthode cryptographique compacte permettant de démontrer que certaines données font partie d’un ensemble plus vaste, par exemple des données contenues dans un bloc. Si un bridge vérifie mal une telle preuve, un attaquant peut éventuellement faire accepter un événement qui n’a jamais été valide.

Toutes les attaques ne passent donc pas par des clés volées, et tous les bridges ne fonctionnent pas de la même manière. Pour comprendre le risque, il faut examiner le modèle de vérification et de sécurité propre au bridge.

Quelles vulnérabilités sont fréquentes ?

De nombreuses attaques de bridge se répartissent grossièrement en plusieurs catégories : erreurs de droits d’accès, erreurs de logique, problèmes de vérification des messages et problèmes de sécurité opérationnelle.

Les permission issues concernent les personnes autorisées à effectuer certaines actions. Il se peut qu’un compte administrateur ait trop de droits, que les comptes des validateurs soient insuffisamment protégés ou que les autorisations puissent être modifiées de manière incorrecte. Surtout avec un petit ensemble de validateurs ou un multisig réduit, cela peut représenter un risque important. Si suffisamment de signataires coopèrent ou sont compromis, ils peuvent autoriser des paiements invalides.

Les logic issues sont des erreurs dans les règles des smart contracts. Un contrat traite par exemple un message sans vérifier toutes les conditions, ou le mint et la libération sont mal configurés. Les erreurs lors d’une mise à jour ou de l’initialisation d’un contrat peuvent aussi entrer dans cette catégorie.

Les message verification issues apparaissent lorsqu’un bridge ne vérifie pas suffisamment qu’un message cross-chain est réellement valide. Un bridge peut par exemple accepter la mauvaise source, vérifier incorrectement une preuve cryptographique ou exécuter un message qui n’a jamais été créé de manière valide sur la blockchain source.

Les key management issues surviennent lorsque les clés privées de validateurs, d’administrateurs ou de signataires multisig sont volées ou insuffisamment protégées. Les smart contracts peuvent fonctionner correctement sur le plan technique, tandis qu’un attaquant peut malgré tout produire des signatures valides avec des clés volées.

Les replay attacks constituent aussi un risque connu. Dans ce cas, un message déjà valide est réutilisé. Un bridge doit donc vérifier que chaque message ne peut être traité qu’une seule fois. Un identifiant de message unique, un nonce ou un hash peut aider à cela.

Un audit peut aider à détecter des vulnérabilités, mais il ne garantit pas qu’un bridge soit exempt d’erreurs. Après des mises à jour, des changements de paramètres ou des modifications de l’infrastructure off-chain, de nouveaux risques peuvent apparaître.

Quel rôle jouent les interfaces et le phishing ?

Toute perte lors de l’utilisation d’un bridge ne signifie pas forcément que le bridge lui-même a été exploité. Les attaquants peuvent aussi essayer de tromper les utilisateurs via un faux site ou une fausse interface.

Une fausse interface peut par exemple vous faire envoyer une transaction vers un mauvais smart contract ou vous faire accorder une autorisation pour utiliser des tokens depuis votre wallet. L’infrastructure technique du bridge peut alors rester entièrement intacte.

La distinction est importante : dans le cas d’un bridge exploit, une faiblesse du bridge ou de l’infrastructure qui l’entoure est exploitée. Dans le cas du phishing, l’utilisateur est généralement trompé pour approuver lui-même une action nuisible.

Quel rôle jouent les clés privées et les smart contracts ?

Les clés privées et les smart contracts sont des éléments essentiels de nombreux bridges. Un problème dans l’un ou l’autre peut déjà avoir de graves conséquences.

Une clé privée est une clé secrète qui permet de créer des transactions ou des signatures cryptographiques. Si un bridge n’exécute par exemple un paiement qu’après la signature de plusieurs validateurs, le risque devient important lorsqu’un attaquant parvient à obtenir suffisamment de ces clés. L’attaquant peut alors faire approuver de fausses instructions de bridge comme si elles étaient légitimes.

Un multisig exige que plusieurs parties signent avant qu’une action ne soit exécutée. Cela peut être plus sûr qu’un seul compte administrateur, mais ce n’est pas automatiquement sécurisé. Le seuil doit être bien choisi, les signataires doivent être suffisamment indépendants et les clés privées doivent être correctement protégées.

Lors de l’attaque du Ronin Bridge, en mars 2022, suffisamment de clés de validateurs ont été compromises pour approuver des retraits non autorisés. Au total, 173 600 ETH et 25,5 millions USDC ont été retirés du bridge. La conception du bridge a ensuite été modifiée et des mesures de sécurité supplémentaires ont été mises en place.

Lors de l’incident du Harmony Horizon Bridge, en juin 2022, au moins deux des quatre clés privées des validateurs du bridge ont été compromises. Harmony a indiqué qu’il n’existait aucune preuve que les smart contracts du bridge ou le protocole blockchain lui-même aient été touchés. Cet incident montre qu’un bridge peut être compromis sans qu’il y ait nécessairement une erreur dans le contrat on-chain.

Les smart contracts constituent par ailleurs les règles on-chain de nombreux bridges. Ils vérifient par exemple les signatures ou les preuves cryptographiques, puis exécutent des actions comme mint, brûler, verrouiller ou libérer des tokens. Si ces contrôles sont mal conçus ou mal implémentés, un attaquant peut parfois créer des tokens ou retirer des réserves sans transaction sous-jacente valide.

Une bonne protection exige donc à la fois des smart contracts sûrs et une gestion solide des clés.

Quelles sont les conséquences d’un exploit de bridge cross-chain ?

Un exploit de bridge cross-chain peut faire disparaître des réserves, vider des pools de liquidité ou rendre des wrapped tokens insuffisamment couverts.

Ce dernier point peut avoir de lourdes conséquences. Dans un bridge lock-and-mint, un wrapped token doit normalement être couvert par des réserves sur une autre blockchain. Si cette garantie disparaît, la possibilité d’échanger le wrapped token contre l’actif d’origine peut être mise sous pression. Cela peut aussi toucher des protocoles dans lesquels le token est utilisé comme garantie, comme objet de trading ou comme liquidité.

Les équipes de projet peuvent parfois mettre un bridge en pause temporairement afin de limiter les dégâts. Après l’exploit de Nomad en août 2022, par exemple, le traitement a été interrompu après qu’une erreur dans l’initialisation a permis de traiter des messages invalides comme valides. Lors de cet incident, environ 190 millions de dollars d’actifs ont été retirés du bridge.

Lors de l’exploit de BSC Token Hub en octobre 2022, une preuve cryptographique falsifiée a été utilisée, ce qui a permis de créer environ 2 millions de BNB supplémentaires. BNB Chain a coordonné avec les validateurs pour mettre temporairement la blockchain à l’arrêt et limiter les dégâts. Une grande partie des BNB concernés est ainsi restée sous contrôle.

Les transactions blockchain ne peuvent généralement pas être simplement annulées par une autorité centrale, comme peut l’être par exemple un virement bancaire traditionnel. Cela ne signifie toutefois pas qu’aucune intervention n’est possible. Selon le réseau, les validateurs, les équipes de projet, les émetteurs de tokens ou la gouvernance peuvent parfois prendre des mesures pour arrêter d’autres transactions, bloquer des actifs ou mettre en œuvre d’autres mesures de récupération.

Une pause temporaire peut limiter les dégâts, mais elle a aussi des inconvénients. Les utilisateurs peuvent temporairement ne plus pouvoir utiliser le bridge ni récupérer leurs tokens. En outre, un arrêt d’urgence signifie que certains administrateurs, validateurs ou guardians ont le pouvoir de ralentir ou d’arrêter certaines parties du système.

Le remboursement des utilisateurs après un exploit n’est pas garanti. Cela dépend notamment des réserves disponibles, des assurances, des décisions du projet, de la gouvernance et de la possibilité de récupérer les fonds volés.

Un exploit de bridge important peut aussi nuire à la confiance dans un projet ou dans un actif bridgé. Cela peut avoir un impact sur la liquidité et éventuellement sur le prix de marché, mais l’effet varie selon l’incident et les conditions de marché.

Au-delà de la perte financière directe, un bridge peut donc devenir moins utile pendant longtemps. La liquidité peut diminuer, les wrapped tokens peuvent devenir plus difficiles à échanger et les utilisateurs peuvent hésiter davantage à réutiliser le bridge.

Quels sont les exploits de bridge cross-chain les plus connus ?

Plusieurs grands exploits de bridge ont eu lieu. La cause technique variait selon l’incident.

• Poly Network : en août 2021, plus de 600 millions de dollars de crypto ont été déplacés chez Poly Network après l’exploitation de l’infrastructure cross-chain. Une grande partie des fonds a ensuite été restituée.
• Wormhole : en février 2022, une vulnérabilité dans Wormhole sur Solana a été exploitée pour créer du wrapped ETH sans la couverture sous-jacente requise. L’attaquant a ensuite déplacé une partie des actifs vers Ethereum.
• Ronin Bridge : en mars 2022, des clés de validateurs ont été compromises, ce qui a permis à l’attaquant d’approuver des retraits non autorisés. Au total, 173 600 ETH et 25,5 millions USDC ont été retirés du bridge.
• Harmony Horizon Bridge : en juin 2022, au moins deux clés privées de validateurs du bridge ont été compromises. Lors de l’incident, environ 100 millions de dollars de crypto ont été dérobés.
• Nomad : en août 2022, une erreur liée à l’initialisation du contrat Replica a permis de traiter des messages non prouvés comme valides. Différentes adresses ont ainsi pu copier des transactions et retirer des actifs du bridge. La perte totale s’est élevée à environ 190 millions de dollars.
• BNB Chain Token Hub : en octobre 2022, le bridge natif entre BNB Beacon Chain et BNB Smart Chain a été touché. En falsifiant une preuve de bas niveau, environ 2 millions de BNB supplémentaires ont pu être créés.

Les montants associés à de tels incidents doivent toutefois être replacés dans leur contexte. Un montant cité peut correspondre à la valeur de marché des tokens mintés, aux réserves effectivement retirées, à des actifs temporairement bloqués ou à des montants récupérés par la suite. Comme les prix des cryptos évoluent, la valeur en dollars rapportée peut aussi varier selon le moment de mesure.

Comment prévenir les exploits de bridge cross-chain ?

Les exploits de bridge cross-chain ne peuvent pas être totalement évités, mais plusieurs couches de sécurité indépendantes peuvent réduire la probabilité d’une attaque réussie et limiter les dégâts maximaux.

La base est une vérification stricte. Un bridge doit notamment contrôler d’où vient un message, s’il est valide, pour quelle action il est destiné et s’il n’a pas déjà été utilisé. Ce n’est qu’ensuite qu’un contrat peut par exemple mint des tokens ou libérer des réserves.

Le modèle de confiance compte aussi. Un bridge qui dépend d’un petit ensemble externe de validateurs ou d’un multisig présente un profil de risque différent d’un bridge qui vérifie les informations cross-chain via des light clients, par exemple. Aucun design n’est totalement exempt de risque.

D’autres mesures peuvent aider à limiter les dégâts maximaux :

• Les rate limits limitent la valeur pouvant être déplacée sur une période donnée.
• Les plafonds de retrait fixent une limite aux paiements.
• Les circuit breakers peuvent ralentir ou arrêter automatiquement une activité anormale.
• Les fonctions de pause peuvent suspendre temporairement certaines activités du bridge pendant un incident.
• La surveillance peut signaler plus rapidement des messages de bridge inhabituellement importants ou inhabituels.

Un tel frein d’urgence ne corrige pas la vulnérabilité sous-jacente. Il peut toutefois empêcher un attaquant de retirer en peu de temps toutes les réserves disponibles.

Les audits, les bug bounties, les revues de code et les tests approfondis sont également importants. Ils fonctionnent le mieux en combinaison avec une surveillance continue, une gestion sûre des clés et un plan d’incident préparé à l’avance.

Quelles mesures de sécurité les développeurs peuvent-ils prendre ?

Les développeurs peuvent réduire le risque en organisant strictement dès le départ la vérification, les droits d’accès, la gestion des clés et les mesures d’urgence.

1. Vérifiez chaque message dans son intégralité. Contrôlez notamment la blockchain source, l’expéditeur, le nonce ou l’identifiant unique du message, la destination et la fonction autorisée. Vous évitez ainsi qu’un message provenant de la mauvaise source soit utilisé pour une autre action.

2. Intégrez une protection contre les replay attacks. Marquez un message traité comme utilisé et n’acceptez pas qu’il soit traité à nouveau. Cela aide à contrer les replay attacks, dans lesquelles la même instruction est exécutée plusieurs fois.

3. Accordez le moins de droits possible. Appliquez le principe du moindre privilège. Tous les comptes n’ont pas besoin de pouvoir mettre à jour des contrats, modifier des validateurs, mint des tokens ou activer un arrêt d’urgence. Moins un compte dispose de pouvoirs, plus les dégâts potentiels sont limités s’il est compromis.

4. Protégez les comptes d’administration avec un multisig. Pour les actions de gestion sensibles, utilisez si possible plusieurs signataires indépendants plutôt qu’un seul externally owned account avec une seule clé privée. Un multisig n’est toutefois utile que si les signataires et leurs clés sont réellement suffisamment indépendants.

5. Utilisez un timelock pour les changements risqués. Un timelock introduit un délai d’attente avant l’exécution d’une mise à jour ou d’une décision de gouvernance. Les changements peuvent ainsi être contrôlés à l’avance et une activité suspecte peut être détectée plus tôt.

6. Testez davantage que le seul parcours normal. Faites réaliser des audits indépendants, mais testez aussi les mises à jour, l’initialisation, les entrées erronées, les cas limites et la vérification des preuves. L’exploit de Nomad montre à quel point une erreur lors d’une mise à jour ou d’une initialisation peut avoir de graves conséquences.

7. Préparez à l’avance la réponse aux incidents. Utilisez la surveillance, la détection d’anomalies, les rate limits et, lorsque c’est approprié, un arrêt d’urgence contrôlé. Définissez à l’avance qui peut intervenir, quelles actions sont possibles et comment la communication se déroule pendant un incident.

8. Gérez les clés privées avec soin. Conservez les clés des validateurs et des administrateurs séparées et bien protégées. Prévoyez aussi des procédures permettant d’ajouter, de retirer et de remplacer les signataires de manière contrôlée.

Un audit ou un bug bounty n’est pas pour autant un label de sécurité. Les nouvelles mises à jour, les relayers off-chain, les changements de configuration et la sécurité quotidienne des clés privées restent des risques distincts.

Comment les utilisateurs peuvent-ils limiter les risques ?

En tant qu’utilisateur, vous ne pouvez pas décider vous-même du niveau de sécurité d’un bridge, mais vous pouvez limiter le risque que vous prenez via un bridge.

1. Examinez le modèle de confiance. Vérifiez quel bridge vous utilisez et comment les messages cross-chain sont vérifiés. Regardez par exemple si un groupe externe de validateurs, un multisig, un light client ou un autre modèle de vérification est utilisé.

2. Utilisez la bonne interface. Ouvrez le bridge via un canal de projet fiable et contrôlé. Avant de signer une transaction, vérifiez notamment l’URL, la blockchain, l’adresse de réception et le token que vous envoyez.

3. Ne signez pas à l’aveugle. Vérifiez ce qu’une transaction ou un message fait avant de le signer. La signature aveugle peut vous exposer au phishing, à un contrat malveillant ou à des autorisations indésirables.

4. Limitez les approvals de tokens. Accordez si possible uniquement l’autorisation correspondant au montant nécessaire. Un approval de token peut rester actif on-chain jusqu’à ce qu’il soit modifié ou révoqué.

5. Révoquez les approvals inutilisés. Vérifiez les anciens plafonds de dépense et révoquez-les si vous n’en avez plus besoin. Le simple fait de déconnecter votre wallet crypto d’une dApp ne supprime pas les approvals de tokens existants.

6. Limitez votre exposition. Une petite transaction test peut aider à vérifier par exemple l’adresse, l’interface et le chemin choisi. Un tel test ne prouve toutefois pas que le bridge lui-même est sûr.

7. Tenez compte du risque lié aux tokens bridgés. Après un exploit, les wrapped tokens peuvent temporairement devenir difficiles à échanger ou moins liquides. Plus une valeur importante dépend longtemps d’un seul bridge et de ses réserves sous-jacentes, plus l’exposition à ce risque spécifique de bridge est grande.

Vérifiez également les annonces officielles d’incident et les avertissements de sécurité en cours avant d’utiliser un bridge.

En résumé

Un bridge cross-chain permet d’échanger des tokens, des messages et d’autres données entre blockchains, mais ajoute aussi une couche de sécurité supplémentaire. Des vulnérabilités peuvent notamment apparaître dans la vérification des messages cross-chain, les droits d’accès, les clés privées, la configuration et les smart contracts.

Les conséquences peuvent être importantes, car les bridges gèrent souvent des quantités considérables de crypto ou sont responsables de la couverture des wrapped tokens. Les incidents survenus notamment chez Poly Network, Wormhole, Ronin, Harmony, Nomad et BNB Chain montrent en outre que les exploits de bridge peuvent survenir de façons très différentes.

Pour les développeurs, une bonne sécurité repose donc sur plusieurs couches indépendantes : vérification stricte, protection contre les replay attacks, gestion limitée, gestion sûre des clés, surveillance et plan d’incident préparé. Pour les utilisateurs, il est surtout important de comprendre quel modèle de confiance un bridge utilise, de vérifier la bonne interface et de tenir compte des risques supplémentaires liés aux actifs bridgés.

Les bridges jouent un rôle important dans un écosystème composé de plusieurs blockchains, mais ils ne sont pas sans risque. Plus vous comprenez comment un bridge vérifie les événements sur une autre blockchain et de quelles parties ou de quels systèmes cette vérification dépend, mieux vous pouvez évaluer son modèle de sécurité.