Analyse de la raison du vol de 190 millions chez Nomad : un carnage déclenché par une mise à jour
TechFlow SélectionTechFlow Sélection
Analyse de la raison du vol de 190 millions chez Nomad : un carnage déclenché par une mise à jour
Lors d'une mise à jour, le contrat a marqué 0x00 comme racine valide, ce qui a permis à Nomad d'être inondé par des informations falsifiées. Les attaquants ont exploité cette faille pour copier/coller des adresses de transactions valides, et dans la confusion qui s'ensuivit, les actifs du pont ont été rapidement vidés.
Dédié à des analyses Web3 approfondiesRédaction : Samczsun
Traduction : TechFlow intern
TL;DR
Lors d'une mise à jour, le contrat a marqué 0x00 comme racine valide, ce qui a entraîné un afflux massif de messages frauduleux sur Nomad. Les attaquants ont exploité cette faille en copiant/collant des transactions valides, remplaçant simplement les adresses par les leurs. Dans ce chaos, le pont a rapidement été vidé de ses actifs.
L'incident récent survenu chez Nomad est l'une des attaques les plus chaotiques que j'aie jamais vues dans l'écosystème Web3, aboutissant au détournement de plus de 150 millions de dollars. Comment cela s'est-il produit ? Quelle en était la cause fondamentale ? Permettez-moi de vous dévoiler ce qui s'est passé en coulisses.
Tout a commencé lorsque CIA Officer a partagé sur le canal Telegram ETHSecurity un tweet de Spreek. À ce moment-là, je ne savais pas encore ce qui se passait, mais voir un volume important d'actifs quitter le pont était clairement un mauvais signe.
Mon premier soupçon fut une erreur de configuration du nombre de décimales du jeton. Après tout, de mon point de vue, le pont semblait proposer une promotion du type « Envoyez 0,01 WBTC, recevez 100 WBTC ».
Au départ, je n'y croyais pas vraiment. Toutefois, après avoir effectué quelques recherches manuelles sur le réseau Moonbeam, j'ai pu confirmer que c'était bien le cas : seulement 0,01 WBTC avaient été transférés depuis Moonbeam, alors que pour une raison inconnue, 100 WBTC étaient reçus sur Ethereum.
En outre, cette transaction de pontage WBTC n'incluait en réalité aucune étape de preuve (Prove), elle appelait directement la fonction `Process`. Il va sans dire qu'autoriser le traitement d'un message sans preuve est extrêmement problématique.
Deux hypothèses s'offraient alors à moi : soit la preuve avait été soumise séparément lors d'un bloc antérieur, soit il y avait un problème majeur avec le contrat Replica. Or, il n'y avait absolument aucun indice indiquant qu'une quelconque preuve eût été soumise récemment.
Il ne restait donc qu'une seule possibilité : une vulnérabilité critique dans le contrat Replica. Mais comment ? En parcourant rapidement le code, j'ai remarqué que les messages envoyés devaient appartenir à une racine acceptée, sinon la vérification à la ligne 185 échouerait.
Heureusement, il existait un moyen simple de tester cette hypothèse. Je savais qu'une racine de message non prouvé valait 0x00, car messages[_messageHash] indiquait une valeur non initialisée. Il me suffisait donc de vérifier si le contrat acceptait cette racine.
Le contrat l’a acceptée…
Il s'avère que pendant la mise à jour, l'équipe de Nomad a initialisé la racine de confiance à 0x00. Pour être clair, utiliser la valeur zéro comme valeur d'initialisation est une pratique courante. Malheureusement, dans ce cas précis, cela a eu un petit effet secondaire désastreux : chaque message était automatiquement validé.
Voilà pourquoi cet événement a été si chaotique : vous n'aviez pas besoin de connaître Solidity ou les arbres de Merkle. Il vous suffisait de trouver une transaction valide, de localiser et remplacer l'adresse de destination par la vôtre, puis de rebroadcast le message.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
