Cours de sécurité DeFi Cobo (1re partie) : Revue des grands événements de sécurité DeFi en 2022
TechFlow SélectionTechFlow Sélection
Cours de sécurité DeFi Cobo (1re partie) : Revue des grands événements de sécurité DeFi en 2022
Selon les statistiques de SlowMist, plus de 300 incidents de sécurité liés à la blockchain se sont produits en 2022, impliquant un montant total de 4,3 milliards de dollars américains.
Dédié à des analyses Web3 approfondiesAuteur : Max, Directeur de la sécurité chez Cobo
Invité par Moledao, Max, directeur de la sécurité chez Cobo, a récemment dispensé en ligne un cours sur la sécurité DeFi à destination de la communauté. Max y a passé en revue les principaux incidents de sécurité survenus dans l'industrie Web3 au cours des derniers mois, analysant particulièrement leurs causes et la manière de les éviter. Il a également résumé les vulnérabilités courantes des contrats intelligents ainsi que les mesures préventives associées, tout en prodiguant quelques conseils de sécurité aux projets comme aux utilisateurs ordinaires. Nous publions ici le contenu de cet exposé en deux parties, à conserver précieusement pour tous les passionnés de DeFi.
Selon les statistiques de SlowMist, plus de 300 incidents de sécurité blockchain ont eu lieu en 2022, impliquant au total environ 4,3 milliards de dollars américains.
Cet article détaille huit cas emblématiques, dont chacun a entraîné des pertes dépassant largement 100 millions de dollars. Bien que le montant concerné par Ankr soit moindre, il s'agit néanmoins d'un cas typique.
Ronin Bridge
Résumé de l’incident :
-
Le 23 mars 2022, le réseau secondaire Ronin Network du jeu NFT Axie Infinity a annoncé avoir subi une intrusion. Les nœuds validateurs de Sky Mavis et ceux du DAO Axie avaient été compromis, permettant à un attaquant de transférer via le pont 173 600 ETH (valeur actuelle supérieure à 590 millions de dollars) et 25,5 millions d’USD.
-
Le Trésor américain a indiqué que le groupe nord-coréen de hackers Lazarus était lié au piratage de Ronin Network ayant causé une perte de 625 millions de dollars.
-
D’après des sources médiatiques, les pirates ont contacté via LinkedIn un employé de Sky Mavis, développeur d’Axie Infinity, lui proposant un emploi bien rémunéré après plusieurs entretiens fictifs. L’employé a ensuite téléchargé une fausse lettre d’embauche au format PDF, permettant à un logiciel malveillant de s’installer dans le système de Ronin. Grâce à cela, les attaquants ont pris le contrôle de quatre des neuf validateurs du réseau Ronin, manquant de peu la prise de contrôle totale. Ils ont finalement achevé leur intrusion en exploitant un compte du DAO Axie dont les droits n’avaient pas été révoqués.
Ce groupe de hackers nord-coréen existe depuis longtemps. Même avant l’essor des technologies Web3, de nombreux rapports faisaient état d’intrusions dans des banques ou grandes entreprises. Aujourd’hui, de plus en plus de groupes de hackers traditionnels, voire des entités étatiques, passent d’attaques visant à voler des données ou informations de carte bancaire à des attaques contre des projets blockchain afin d’obtenir directement des gains financiers.
La méthode d’attaque utilisée ici est très classique, désignée dans le domaine de la cybersécurité traditionnelle sous le nom d’APT (Advanced Persistent Threat). Une fois une cible identifiée, le groupe de hackers utilise notamment l’ingénierie sociale pour prendre le contrôle d’un poste informatique au sein de l’organisation, servant de point d’appui pour infiltrer progressivement le système jusqu’à atteindre son objectif.
Cet incident révèle aussi une faiblesse notable en matière de sensibilisation à la sécurité chez les employés d’Axie Infinity, ainsi qu’un défaut dans les dispositifs internes de sécurité de l’entreprise.
Wormhole
Résumé de l’incident :
-
Selon le rapport publié par Wormhole sur cet incident, la faille provenait d’une erreur dans le code de vérification des signatures du contrat principal côté Solana. Cette erreur permettait à un attaquant de falsifier des messages provenant des « gardiens » afin de frapper artificiellement des ETH encapsulés via Wormhole, entraînant une perte totale d’environ 120 000 ETH.
-
Jump Crypto a injecté 120 000 ETH pour couvrir les pertes dues au piratage du pont Wormhole, soutenant ainsi la poursuite du développement du projet.
Le problème rencontré par Wormhole était essentiellement lié au code, notamment à l’utilisation de fonctions obsolètes. Par exemple, dans les premières versions de Solidity sur Ethereum, certaines fonctions étaient mal conçues et ont progressivement été abandonnées lors des mises à jour ultérieures. D’autres écosystèmes connaissent des situations similaires. Il est donc fortement conseillé aux développeurs d’utiliser toujours les dernières versions disponibles pour éviter ce type de problème.
Nomad Bridge
Résumé de l’incident :
-
Le protocole d’interopérabilité inter-chaînes Nomad Bridge a été piraté car lors de l’initialisation du contrat Replica, la racine de confiance avait été définie à 0x0. Pire encore, lors de la modification de cette racine, l’ancienne n’a pas été invalidée, permettant aux attaquants de fabriquer arbitrairement des messages pour vider les fonds verrouillés sur le pont, causant des pertes supérieures à 190 millions de dollars.
-
Les pirates ont exploité cette vulnérabilité en reprenant une transaction valide existante, puis en envoyant à répétition des données de transaction manipulées, drainant ainsi presque intégralement les fonds bloqués sur Nomad.
-
Selon PeckShield, environ 41 adresses ont profité de cet incident, récupérant environ 152 millions de dollars (soit 80 % des fonds), incluant environ 7 robots MEV (7,1 millions de dollars), le pirate de Rari Capital (3,4 millions de dollars), et 6 hackers blancs (8,2 millions de dollars). Environ 10 % des bénéfices, soit 6,1 millions de dollars, sont allés à des adresses ENS.
L’incident Nomad Bridge est emblématique. Fondamentalement, il résultait d’une mauvaise configuration initiale. Si un pirate retrouve une ancienne transaction valide et la rebroadcaste, les fonds associés peuvent être exécutés à nouveau, reversant les profits à l’attaquant. Dans l’écosystème Ethereum, outre les projets et utilisateurs, de nombreux robots MEV sont présents. Dans ce cas précis, dès qu’un robot automatisé a détecté que diffuser cette transaction donnait un gain à son initiateur, ils se sont tous précipités dessus, transformant l’incident en course au pillage. Un très grand nombre d’adresses ont été impliquées. Bien que l’équipe projet ait pu récupérer une partie des fonds via certains hackers blancs et adresses ENS, la majorité des fonds restent irrécupérables. Si l’attaquant utilise un appareil et une adresse parfaitement propres, il devient extrêmement difficile de remonter à son identité par analyse des données.
Bien que des entreprises comme Google, Microsoft, Facebook, Alibaba ou Tencent aient déjà subi des attaques, leurs logiciels sont généralement fermés. En revanche, dans l’écosystème Ethereum ou celui des contrats intelligents, de nombreux programmes sont open source. Pour les hackers, analyser du code public est relativement simple. Dès lors, si un projet comporte une vulnérabilité, sa chute est souvent inévitable.
Beanstalk
Résumé de l’incident :
-
Le projet de stablecoin algorithmique Beanstalk Farms, basé sur Ethereum, a perdu environ 182 millions de dollars lors d’une attaque par prêt flash. Les actifs volés comprenaient 79 238 241 BEAN3CRV-f, 1 637 956 BEANLUSD-f, 36 084 584 BEAN et 0,54 UNI-V2_WETH_BEAN. L’attaquant a empoché plus de 80 millions de dollars, notamment environ 24 830 ETH et 36 millions de BEAN.
-
La cause principale de cette attaque résidait dans l’absence d’intervalle temporel entre le vote et l’exécution d’une proposition, permettant à l’attaquant d’exécuter immédiatement une proposition malveillante sans validation communautaire.
-
Déroulement de l’attaque :
-
Acheter et staker des jetons la veille pour obtenir le droit de proposer, puis créer un contrat malveillant ;
-
Utiliser un prêt flash pour accumuler massivement des jetons et voter pour le contrat malveillant ;
-
Exécuter le contrat malveillant et réaliser l’arbitrage.
-
Beanstalk constitue un autre cas classique. L’attaquant n’a exploité aucune vulnérabilité technique, mais simplement un défaut de conception du projet. Ce dernier permet à toute personne ayant misé des jetons de soumettre une proposition, qui peut elle-même être un contrat. La veille de l’attaque, l’attaquant a acheté suffisamment de jetons pour soumettre une proposition malveillante. Après 24 heures, celle-ci pouvait être votée, et aussitôt validée, elle était exécutée immédiatement, sans délai ni verrou temporel.
De nombreux projets aujourd’hui prônent l’autonomie communautaire et la décentralisation pure, ce qui pose de nombreux problèmes. Par exemple, chaque proposition doit-elle être examinée ? Comment distinguer une proposition légitime d’une proposition malveillante ? Si un prêt flash permet de voter massivement, ne faudrait-il pas instaurer un système de staking sur une durée fixe, voire distribuer des jetons de vote spécifiques ? Et surtout, un délai (« time lock ») entre l’approbation et l’exécution d’une proposition ne devrait-il pas être obligatoire ? En théorie, oui. Cela permettrait à la communauté de surveiller les actions durant cette période et offrirait une chance de fuir en cas de menace. Sans cela, si une action malveillante est exécutée, personne ne peut s’échapper.
Wintermute
Résumé de l’incident :
-
Le matin du 21 septembre 2022, Evgeny Gaevoy a publié sur Twitter une mise à jour sur l’incident, confirmant que Wintermute avait effectivement utilisé Profanity et un outil interne en juin pour créer des adresses de portefeuille. Cette pratique visait à optimiser les frais de transaction, pas seulement à obtenir des adresses « jolies ». Il a ajouté qu’après avoir découvert la vulnérabilité de Profanity la semaine précédente, Wintermute avait accéléré la désactivation des anciennes clés. Toutefois, en raison d’une erreur humaine interne, une mauvaise fonction a été appelée, empêchant la suppression effective des opérations de signature et d’exécution sur les adresses compromises.
On trouve souvent en ligne des adresses commençant par plusieurs zéros (par exemple huit zéros). Plus une adresse Ethereum contient de zéros, plus les frais de transaction sont faibles. C’est pourquoi de nombreux robots MEV et projets préfèrent utiliser ces adresses, en particulier pour des opérations fréquentes.
Wintermute est un market maker. À l’époque, ils ont envoyé de nombreux jetons vers un contrat, utilisant un programme de génération d’adresses « premium » pour créer l’adresse du contrat. Le propriétaire (Owner) du contrat était aussi une adresse « jolie », dont la clé privée a malheureusement été calculée de force par un attaquant, qui a alors vidé tous les fonds du contrat.
Lorsqu’on utilise un outil open source en ligne, il faut être prêt à en accepter les conséquences potentielles. Avant d’utiliser un programme externe, il est fortement recommandé d’en faire une évaluation de sécurité approfondie.
Harmony Bridge
Résumé de l’incident :
-
Le pont inter-chaînes Horizon a perdu plus de 100 millions de dollars, notamment plus de 13 000 ETH et 5 000 BNB.
-
Le fondateur de Harmony a indiqué que l’attaque d’Horizon était due à une fuite de clé privée.
-
Selon Bloomberg, une analyse récente d’Elliptic, société spécialisée dans l’analyse blockchain, attribue le vol de 100 millions de dollars sur le pont Horizon de Harmony au groupe nord-coréen Lazarus. Elliptic souligne plusieurs indices, notamment un blanchiment automatisé via Tornado.Cash similaire à celui observé lors de l’attaque de Ronin Bridge, ainsi que le moment du vol.
Harmony n’a pas publié de détails précis, mais selon les rapports, il pourrait s’agir à nouveau du groupe nord-coréen. Si tel est le cas, la méthode d’attaque serait similaire à celle de Ronin Bridge. Ces groupes nord-coréens sont très actifs ces dernières années, particulièrement dans le domaine des cryptomonnaies, avec de nombreuses tentatives de phishing contre diverses entreprises.
Ankr
Résumé de l’incident :
-
Ankr : mise à jour du contrat Deployer.
-
Ankr : le Deployer envoie du BNB à l’exploitant Ankr.
-
L’exploitant utilise la méthode de frappe du contrat mis à jour pour générer des jetons.
-
10 000 milliards de aBNBc ont été créés artificiellement. Le pirate A a échangé les aBNBc contre 5 millions de USDC sur PancakeSwap, vidant le pool et faisant chuter la valeur des aBNBc à presque zéro. Il a ensuite transféré les fonds vers Ethereum et les a envoyés vers Tornado Cash.
-
Environ une demi-heure après la création des aBNBc par le pirate A, la chute brutale du prix a créé une opportunité d’arbitrage. L’arbitragiste B a exploité le paramètre du price feed d’Helio (moyenne pondérée sur 6 heures) pour échanger les aBNBc sous-évalués sur le marché contre des hBNB sur Helio, puis a misé les hBNB pour obtenir la stablecoin HAY, qu’il a convertie en BNB et USDC, réalisant plus de 17 millions de dollars d’actifs, vidant presque complètement le pool HAY.
-
Ankr va prélever sur un fonds de récupération de 15 millions de dollars pour racheter les HAY émis afin de compenser les victimes de l’attaque.
La perte globale d’Ankr est modérée, mais cet incident mérite d’être souligné. Car de nombreux projets DeFi actuels sont comme des briques Lego : A dépend de B, B dépend de C, etc. Quand un maillon de la chaîne présente un problème, tous les projets en amont et en aval peuvent être affectés.
Ankr a par la suite expliqué l’origine de l’incident : un ancien employé interne ayant agi malicieusement. Problèmes révélés : premièrement, le propriétaire du contrat de staking était un compte EOA et non un multisig, ce qui signifie que qui détient la clé privée contrôle entièrement le contrat — une situation très risquée ; deuxièmement, la clé privée du Deployer restait accessible à un « employé clé », même après son départ. En somme, le système de sécurité interne était pratiquement inexistant.
Mango
Résumé de l’incident :
-
Le pirate a utilisé deux comptes avec un capital initial de 10 millions de USDT.
-
Première étape : le pirate transfère 5 millions de USDT sur les adresses A et B de Mango.
-
Deuxième étape : via l’adresse A, il ouvre une position courte sur le contrat perpétuel MNGO du token MNGO à 0,0382 dollar, pour 483 millions d’unités. Simultanément, via l’adresse B, il ouvre une position longue identique. (La raison de cette double position est que Mango a une faible liquidité : sans s’affronter lui-même, il aurait été difficile d’ouvrir une position aussi importante.)
-
Troisième étape : le pirate fait grimper le prix au comptant de MNGO sur plusieurs plateformes (FTX, Ascendex), entraînant une hausse de 5 à 10 fois. Ce prix est relayé via l’oracle Pyth à Mango, amplifiant la hausse, jusqu’à atteindre un pic de 0,91 dollar contre 0,0382 dollar initialement.
-
Quatrième étape : le gain sur la position longue s’élève à 483 millions × (0,91 - 0,0382) = 420 millions de dollars. Le pirate utilise alors sa richesse nette pour emprunter sur Mango. Heureusement, la liquidité limitée du protocole limite le montant emprunté à environ 115 millions de dollars.
-
Après l’attaque, le pirate a publié une nouvelle proposition demandant à l’équipe de rembourser les dettes via les fonds du trésor (70 millions de dollars). Selon les estimations, le trésor contenait environ 144 millions de dollars, dont 88,5 millions en MNGO et près de 60 millions en USDC. Il a proposé de restituer une partie des fonds volés à condition qu’aucune poursuite pénale ni gel de fonds n’ait lieu. « Si cette proposition est approuvée, je transférerai les MSOL, SOL et MNGO de ce compte vers l’adresse publiée par l’équipe Mango. Le trésor servira à couvrir les dettes restantes, et tous les utilisateurs endettés seront intégralement indemnisés… Une fois les tokens retournés comme prévu, il n’y aura ni poursuite ni gel. »
-
Selon CoinDesk, Avraham Eisenberg, l’attaquant de Mango qui s’était identifié, a été arrêté le 26 décembre 2022 à Porto Rico. Il fait face à des accusations de fraude et de manipulation sur produits, passibles d’amende et d’emprisonnement.
L’incident Mango peut être qualifié d’attaque ou d’arbitrage, car il ne découle pas d’une vulnérabilité de sécurité technique, mais d’un défaut dans le modèle économique. La plateforme propose des actifs très liquides comme BTC et ETH, mais aussi des petits jetons comme MNGO. En période de marché baissier, la faible liquidité de ces petits jetons permet à un attaquant de manipuler facilement leur prix avec peu de moyens, rendant la gestion des positions sur les contrats perpétuels extrêmement risquée.
Les équipes projet doivent donc anticiper tous les scénarios possibles et intégrer des tests couvrant même les situations hors normes pendant la phase de test.
Quant aux utilisateurs ordinaires, lorsqu’ils participent à un projet, ils ne doivent pas uniquement regarder les rendements, mais aussi évaluer sérieusement la sécurité de leur capital. Au-delà des vulnérabilités techniques, il convient d’examiner attentivement si le modèle économique comporte des failles exploitables.
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
Cobo
