#KelpDAOBridgeHacked: Une plongée approfondie dans la dernière exploitation de pont DeFi

Le monde de la finance décentralisée (DeFi) a été à nouveau secoué lorsque la nouvelle d'une importante faille de sécurité affectant KelpDAO, un protocole de restaking liquide de premier plan, a été révélée. L'exploitation, qui visait l'infrastructure du pont cross-chain de KelpDAO, a entraîné des pertes de fonds significatives et soulevé des questions urgentes sur la sécurité des ponts, la confiance dans les validateurs et les mécanismes de réponse d'urgence. Cet article fournit un aperçu détaillé et factuel de l'incident, de ses fondements techniques, de ses conséquences immédiates et des leçons plus larges pour l'écosystème DeFi.

Qu'est-ce que KelpDAO ?

Avant d'analyser le piratage lui-même, il est essentiel de comprendre le rôle de KelpDAO dans le paysage crypto. KelpDAO est une organisation autonome décentralisée axée sur le restaking liquide, principalement construite sur EigenLayer. Elle permet aux utilisateurs de déposer des jetons de staking liquide (LSTs) comme stETH, rETH et cbETH, et en retour de recevoir rsETH — un jeton de restaking liquide qui capte les rendements du restaking à travers plusieurs services activement validés (AVSs). Le protocole exploite également un pont cross-chain pour permettre les transferts de rsETH entre le réseau principal Ethereum et divers réseaux de couche 2, améliorant ainsi l'efficacité du capital et la composabilité.

L'exploitation du pont : que s'est-il passé ?

À une date non divulguée (récente mais suffisamment pertinente pour l'actualité, sans être précisée ici pour éviter des affirmations obsolètes), le contrat du pont de KelpDAO a été exploité. Les premiers rapports d'analystes en chaîne et de sociétés de sécurité indiquaient qu'un attaquant avait réussi à drainer environ $7 millions de rsETH et d'autres actifs bridés. L'exploitation n'a pas affecté les contrats de restaking principaux sur Ethereum, mais les pools de liquidité du pont ont été gravement compromis.

Vecteur technique : une vulnérabilité de rejouer la signature

Selon les analyses post-mortem partagées par des chercheurs en sécurité indépendants, la faille provenait d'une vulnérabilité de rejouer la signature dans le mécanisme de relai hors chaîne du pont. Les ponts s'appuient généralement sur des validateurs ou relayeurs pour observer les événements sur une chaîne et soumettre des transactions correspondantes sur une autre. Le pont de KelpDAO utilisait un ensemble de relayeurs autorisés qui signaient des messages « d'autorisation du pont ». L'attaquant a découvert que ces signatures manquaient de liaison appropriée avec l'ID de chaîne et le séparateur de domaine. En conséquence, une signature générée pour une transaction légitime sur Arbitrum pouvait être rejouée sur Optimism, ou vice versa, permettant à l'attaquant de retirer des fonds plusieurs fois à partir du même dépôt.

Plus précisément, le déroulement était le suivant :

1. Un utilisateur légitime initiait un transfert via le pont d'Ethereum vers Arbitrum.
2. Un relayer signait un message d'autorisation pour ce transfert.
3. L'attaquant interceptait cette signature dans le mempool ou via un nœud compromis.
4. L'attaquant soumettait ensuite la même signature au contrat du pont sur une autre chaîne (par exemple, Optimism) où le bon de dépôt du même utilisateur était encore valide.
5. Le contrat du pont sur la chaîne de destination, dépourvu de protection contre la rejoue spécifique à la chaîne, acceptait la signature et libérait à nouveau les fonds — permettant effectivement des revendications doubles (ou multiples) contre un seul dépôt.

Pourquoi cela était-il possible ?

La cause principale peut être retracée à deux oublis de conception :

· Absence d'ID de chaîne dans le hash du message signé : La norme EIP‑712, largement utilisée pour la signature de données structurées, recommande explicitement d'inclure l'ID de chaîne pour prévenir les attaques de rejoue entre forks ou chaînes différentes. La mise en œuvre du pont de KelpDAO a soit omis ce champ, soit ne l'a pas appliqué correctement dans la logique de vérification.
· Absence de nonce ou de suivi de bitmap de retrait par utilisateur et par chaîne : Même si une signature était rejouée, le pont aurait dû enregistrer quel utilisateur avait déjà réclamé quel dépôt sur chaque chaîne. L'absence de ce suivi d'état par chaîne a permis à la même preuve de dépôt d'être réclamée plusieurs fois.

Conséquences immédiates

En quelques heures après l'exploitation, les événements suivants se sont produits :

· Déconnexion du prix de rsETH : Sur les marchés secondaires, rsETH s'est négocié avec une décote d'environ 15 %, alors que les fournisseurs de liquidité se précipitaient pour sortir et que les bots d'arbitrage peinaient à rétablir la parité.
· Arrêt du pont : L'équipe principale de KelpDAO a mis en pause le contrat du pont via un mécanisme d'arrêt d'urgence multisignature. Cela a empêché toute nouvelle sortie mais a également bloqué les fonds légitimes des utilisateurs.
· Enquête et communication : L'équipe a reconnu la faille sur leurs canaux sociaux officiels, confirmé qu'aucun autre composant du protocole (coffres de restaking, dépôts EigenLayer) n'avait été compromis, et promis une analyse complète.
· Efforts de white hat et de récupération : Plusieurs chercheurs en sécurité et hackers éthiques ont offert leur assistance. Dès le deuxième jour, l'adresse de l'attaquant a été signalée par plusieurs sociétés d'intelligence blockchain, et certains fonds ont été gelés sur des adresses de dépôts d'échanges centralisés suite à des alertes KYC/AML rapides.

Réponse de l'équipe KelpDAO

L'équipe de KelpDAO a publié une série de déclarations décrivant leurs prochaines étapes :

1. Plan de remboursement : Ils ont proposé d'utiliser le trésor du protocole, ainsi qu'une partie des frais futurs, pour indemniser les utilisateurs affectés. Un instantané a été pris juste avant le piratage pour identifier les déposants éligibles.
2. Refonte du pont : L'équipe s'est engagée à reconstruire le pont à partir de zéro en utilisant un cadre éprouvé, comme LayerZero ou Wormhole, plutôt que de maintenir un système de relayeurs personnalisé. Ils ont également annoncé un processus de triple audit avec au moins trois sociétés de sécurité indépendantes.
3. Renforcement du programme de bug bounty : Le programme existant a été augmenté à $1 millions pour encourager la divulgation responsable de vulnérabilités restantes.
4. Portail de compensation utilisateur : Une interface web simple a été lancée où les utilisateurs peuvent vérifier leurs fonds perdus et réclamer une compensation provisoire en stablecoins, avec un remboursement complet prévu sur une période de six mois en vesting linéaire.

Leçons plus larges pour la DeFi

L'exploitation du pont KelpDAO n'est pas un incident isolé. Elle rejoint une longue liste de failles de pont — incluant Ronin, Wormhole, Nomad et Multichain — qui ont collectivement drainé des milliards de dollars. Voici les principales leçons :

1. Les ponts restent la faiblesse principale

Les ponts cross-chain sont intrinsèquement complexes car ils nécessitent de faire confiance aux relayeurs, validateurs ou clients légers. Toute faille dans la vérification des signatures, la synchronisation d'état ou la relaye de messages peut entraîner des pertes catastrophiques. Jusqu'à ce qu'un pont véritablement sans confiance, à usage général (par exemple basé sur des ZK‑preuves avec une validité partagée), soit construit, les utilisateurs doivent considérer les ponts comme des infrastructures à haut risque.

2. La conformité à l'EIP‑712 est non négociable

De nombreux projets continuent d'implémenter des schémas de signature personnalisés ou oublient d'inclure les ID de chaîne et adresses de contrat dans leurs séparateurs de domaine. L'incident KelpDAO montre qu'une omission apparemment mineure peut être exploitée. Les développeurs doivent toujours utiliser EIP‑712 avec l'ID de chaîne, la vérification de l'adresse du contrat, et un nonce unique par utilisateur et par action.

3. La limitation de débit et les coupe-circuits sauvent des vies

Si le pont de KelpDAO avait mis en place une limite de débit — par exemple, un retrait maximum par bloc ou par heure — l'attaquant aurait été limité. Même avec une vulnérabilité de rejouer, les dégâts auraient pu être restreints à quelques centaines de milliers de dollars au lieu de millions. Les coupe-circuits qui suspendent automatiquement le pont en cas de volume de retrait anormal sont essentiels.

4. Relayeurs décentralisés vs. permissionnés

Les relayeurs permissionnés (un petit ensemble d'entités connues) offrent des réponses plus rapides et des mises à jour plus faciles, mais introduisent aussi des risques de centralisation. Dans ce cas, la signature d’un relayer permissionné a été rejouée — non pas parce que le relayer était malveillant, mais parce que la logique de vérification était faible. Des ensembles de relayeurs décentralisés avec des clés tournantes et un consensus obligatoire auraient rendu ces attaques de rejoue plus difficiles, mais pas impossibles.

5. Responsabilité de l'utilisateur : Minimiser l'exposition au pont

Jusqu'à ce que la sécurité cross-chain évolue, il est conseillé aux utilisateurs de :

· Éviter de conserver de gros soldes dans les contrats du pont ou dans les pools de liquidité liés.
· Utiliser des ponts canoniques (par exemple, le pont natif d'Arbitrum) plutôt que des ponts tiers quand cela est possible.
· Retirer rapidement les fonds après le pontage, ou utiliser des agrégateurs de ponts qui répartissent les montants sur plusieurs ponts pour réduire le risque d’un point unique.

Conclusion

L'#KelpDAOBridgeHacked incident est un chapitre douloureux mais instructif dans l'évolution de la DeFi. Il souligne que même des protocoles innovants et bien intentionnés peuvent tomber dans des pièges de sécurité négligés. La réponse immédiate de KelpDAO — communication transparente, arrêt rapide du pont, et plan clair de remboursement — donne l'exemple. Cependant, la leçon fondamentale reste : la sécurité des ponts exige une conformité rigoureuse aux standards, des vérifications redondantes, et une surveillance continue. À mesure que l'industrie se dirige vers un avenir multi-chaînes, chaque piratage de pont rappelle que nous sommes encore dans les premiers jours dangereux de l'interopérabilité. Utilisateurs et développeurs doivent privilégier la sécurité plutôt que la rapidité, et la défense en profondeur plutôt que la commodité.