arrière-plan
Blast est un réseau Ethereum Layer 2 lancé par Pacman (Tieshun Roquerre, alias Tieshun), le fondateur de Blur. Il a lancé le réseau principal le 29 février. Actuellement, environ 19 500 ETH et 640 000 stETH sont promis sur le réseau principal Blast.
Le projet attaqué Munchables est un projet de grande qualité qui a remporté le concours Bigbang organisé par Blast.
Les responsables de Blast attribueront des points ordinaires aux utilisateurs qui promettent de l’ETH sur le réseau principal de Blast :
Afin d’encourager les utilisateurs à participer aux projets DeFi sur l’écosystème Blast, les responsables de Blast sélectionneront des projets de haute qualité à recommander et encourageront les utilisateurs à engager l’ETH une deuxième fois dans DeFi pour obtenir une augmentation plus rapide des points et des points d’or. Quelques utilisateurs ont promis l’ETH promis sur le réseau principal Blast au projet DeFi nouvellement créé.
La maturité et la sécurité de ces projets DeFi doivent encore être examinées, et si ces contrats comportent des considérations de sécurité suffisantes pour protéger les dizaines de millions, voire les centaines de millions de dollars des utilisateurs.
Aperçu de l’événement
Moins d’un mois après la mise en ligne du réseau principal Blast, une attaque contre le jeton SSS (Super Sushi Samurai) s’est produite le 21 mars 2024. Il y avait une erreur de logique de transfert dans le contrat du jeton, qui a permis à l’attaquant d’augmenter le jeton SSS du Compte spécifié à partir de rien. En fin de compte, le projet a finalement perdu plus de 1 310 ETH (environ 4,6 millions de dollars).
Moins d’une semaine après l’attaque du token SSS, une autre attaque plus importante a eu lieu contre Blast : le projet Munchables a été balayé par des attaquants avec 17 413,96 ETH, soit un total d’environ 62,5 millions de dollars américains.
Une demi-heure après la transaction d’attaque, 73,49 WETH du contrat de projet ont également été volés par un pirate informatique à une autre adresse.
À l’heure actuelle, il reste encore 7276 WETH, 7758267 USDB et 4 ETH stockés dans l’adresse contractuelle de la partie au projet, qui tomberont à tout moment entre les mains des pirates. Le pirate a le pouvoir de retirer tous les fonds de l’ensemble du projet, pour un montant total d’environ 97 millions de dollars américains.
Immédiatement après l’incident, le célèbre détective en chaîne de X (Twitter), zachXBT, a souligné que la cause première de cette attaque était l’embauche de pirates informatiques d’un certain pays.
Examinons de plus près comment un « pirate informatique d’un certain pays » a mené une attaque d’une valeur de près de 100 millions de dollars.
Restauration sur place
Les victimes s’expriment
[UTC+ 0 ] À 21h37 le 26 mars 2024 (5 minutes après l’attaque), Munchables a officiellement posté sur X (Twitter) déclarant qu’il était attaqué.
Selon l’enquête du détective en chaîne Zach, l’attaquant est venu faire du travail de développement de jeux. Il était très dur et ressemblait vraiment à un hacker chinois. Nous l’avons licencié dans un délai d’un mois. Il a également essayé de nous faire embaucher un de ses amis, qui était probablement aussi un hacker. hacker."
Étant donné que cette attaque a causé d’énormes pertes aux utilisateurs de la communauté, nous avons immédiatement lancé une enquête en chaîne. Examinons en profondeur les détails de l’attaque de ce « hacker d’un certain pays ».
Première scène
[UTC+ 0 ] À 21h32 le 26 mars 2024, une attaque impliquant 17413,96 ETH s’est produite.
Grâce à Blastscan, nous pouvons voir cette transaction d’attaque :
Le contrat endommagé (0x 29…1 F) est un contrat proxy qui stocke les fonds promis par l’utilisateur. Nous pouvons voir que l’attaquant a appelé la fonction de déverrouillage du contrat de gage, a réussi tous les contrôles d’autorisation et l’a transféré. le contrat va à l’adresse de l’attaquant 1 (0x 6 E…c 5).
Il semble que l’attaquant ait appelé une fonction de déverrouillage avec un comportement de type retrait et ait emporté la majeure partie de l’ETH sur le contrat compromis (0x 29…1 F).
L’équipe du projet a-t-elle oublié de verrouiller le coffre-fort ?
Il existe deux contrôles de déverrouillage associés dans le contrat endommagé (0x 29…1 F). Examinons-les un par un.
Premièrement, nous avons constaté que lors du processus de vérification des autorisations, la méthode isRegistered du contrat (0x 16…A 0) était appelée pour vérifier si le msg.sender actuel, c’est-à-dire l’adresse du pirate informatique 1 (0x 6 E…c 5) Déjà inscrit :
La réponse est : réussi la vérification.
Il s’agit du contrat (0x 16…A 0) et de son dernier contrat logique correspondant (0x e 7…f 1)
[UTC+ 0 ] A 08h39 le 24 mars 2024 (2 jours avant l’attaque), le contrat logique correspondant au contrat (0x 16…A 0) a été mis à jour.
Transaction logique de mise à niveau du contrat :
Le contrat logique est mis à jour en 0x e 7…f 1 .
L’adresse logique originale du contrat peut être vue ici, qui est 0x 9 e…CD.
À l’heure actuelle, nous soupçonnons que le pirate informatique met à jour le contrat de mise en œuvre logique du contrat d’agent, ce qui be 0x 9 e… CD devient malveillant 0x e 7…f 1 , complétant le contournement des autorisations de vérification.
Est ce que c’est vraiment?
Dans le Web 3.0, vous n’avez jamais besoin de deviner ou d’écouter les autres, il vous suffit de maîtriser la technologie pour obtenir la réponse vous-même.
En comparant les deux contrats (pas les contrats open source), il existe des différences évidentes entre le contrat 0x 9 e…CD original et le 0x e 7…f 1 mis à jour :
La partie fonction d’initialisation de 0x e 7…f 1 est implémentée comme suit :
La partie fonction d’initialisation de 0x 9 e…CD est implémentée comme suit :
On peut voir que l’attaquant a défini l’adresse de l’attaquant (0x 6 e…c 5) comme registre dans le contrat logique d’origine (0x 9 e…CD), et il existe également deux autres adresses de l’attaquant 0x c 5 …0. d, 0x bf…87 sont également enregistrés, et leur champ 0 est réglé sur le temps de blocage lors de l’initialisation. L’utilisation du champ 0 sera expliquée plus tard.
En fait, contrairement à ce que l’on pensait, le véritable contrat logique avec une porte dérobée existait depuis le début, et les mises à jour ultérieures étaient normales !
Attendez, cette mise à jour est apparue à 08h39 le 24 mars 2024 [UTC+ 0] (2 jours avant l’attaque). Autrement dit, avant cet incident, le contrat logique était devenu un contrat sans porte dérobée. Pourquoi ? L’attaquant peut-il encore terminer l’attaque?
Cela est dû à l’appel de délégué, donc la mise à jour réelle du stockage de l’état se trouve dans le contrat (0x 16…A 0), ce qui entraîne le fait que même si le contrat logique est ultérieurement mis à jour vers le contrat logique sans porte dérobée 0x e 7… f 1 , l’emplacement modifié dans le contrat (0x 16…A 0) ne sera toujours pas restauré.
Vérifions-le :
Comme vous pouvez le constater, l’emplacement correspondant dans le contrat (0x 16…A 0) a une valeur numérique.
Cela permet à un attaquant de réussir la vérification de la méthode isRegistered :
L’attaquant modifie ensuite le contrat de porte dérobée en un contrat normal pour masquer le fait que la porte dérobée a déjà été implantée.
De plus, le processus de déverrouillage implique également une deuxième vérification :
Concernant le contrôle du temps de verrouillage, cette partie vise à garantir que les actifs verrouillés ne seront pas transférés avant l’expiration.
L’attaquant doit s’assurer que le temps de blocage lors de l’appel du déverrouillage est supérieur au délai d’expiration du verrou requis (champ 3).
Cette partie de la vérification porte sur le contrat endommagé (0x 29…1 F) et le contrat logique correspondant 0x f 5…cd.
Dans une transaction à 11h54 le 21 mars 2024 [UTC+ 0] (5 jours avant l’attaque),
Nous pouvons voir que le contrat logique initial du contrat endommagé (0x 29…1 F) était 0x 91…11, et seulement quatre minutes plus tard, à
Mis à niveau vers 0x f 5…cd.
Nous comparons également les deux contrats et nous pouvons constater que l’attaquant a également fait des astuces dans la fonction d’initialisation comme auparavant.
Implémentation partielle de la fonction d’initialisation de 0x f 5…cd :
Implémentation partielle de la fonction d’initialisation de 0x 91…11 :
On peut voir qu’il est évident que la même méthode a été utilisée à nouveau pour modifier la quantité d’ETH et le temps de déverrouillage, puis l’a remplacée par le contrat normal pour tromper les autres. Lorsque l’équipe du projet et les chercheurs en sécurité déboguaient, tous les contrats logiques observés sont normaux, et comme les contrats sont tous des contrats non open source, il est encore plus difficile de voir clairement le cœur du problème.
Jusqu’à présent, nous comprenons cette transaction impliquant 17413 ETH et comment l’attaquant l’a fait, mais n’y a-t-il que autant d’informations derrière cet incident ?
Dans notre analyse ci-dessus, nous avons en fait vu que le pirate informatique avait intégré 3 adresses dans le contrat :
0x 6 e…c 5 (adresse de l’attaquant 1)
0x c 5…0 d (adresse de l’attaquant 2)
0x bf…87 (adresse de l’attaquant 3)
Cependant, nous n’avons vu que 0x 6 e…c 5 dans la transaction d’attaque que nous avons trouvée ci-dessus. Qu’ont fait les deux autres adresses ? Et quels secrets sont cachés dans address(0), _dodoApproveAddress, _uniswapV3Factorty ?
Deuxième scène
Jetons d’abord un coup d’œil à l’adresse 3 de l’attaquant (0x bf…87), qui a volé 73,49 WETH par la même méthode :
Et attaquez l’adresse source du gaz (0x 97…de), et fournissez des frais de traitement à la fois à 0x c 5…0 d (adresse de l’attaquant 2) et à 0x bf…87 (adresse de l’attaquant 3).
La source du 0,1 ETH qui attaque l’adresse de la source de gaz (0x 97…de) provient de hibouto.finance (pont inter-chaînes).
0x c 5…0 d (adresse de l’attaquant 2) n’a mené aucune attaque après avoir reçu les frais de traitement, mais il a en fait assumé un plan caché. Continuons à l’examiner.
En fait, selon l’opération de sauvetage officielle, l’adresse originale du contrat endommagé (0x 29…1 F) n’était pas seulement 73,49 WETH : jusqu’à la fin de l’attaque, il y avait encore 7276,5 WETH et 7758267 USDB.
Offre de sauvetage :
L’attaquant avait initialement prévu de voler ces actifs. Vous pouvez voir que l’adresse 0x c 5…0 d (adresse de l’attaquant 2) a été initialement utilisée pour voler l’USDB.
L’adresse _dodoApproveAddress ici est 0x00000000000000000000000043000000000000000000000000000000000000003
est l’adresse USB
0x bf…87 (adresse de l’attaquant 3) Cette adresse est utilisée pour voler :
L’usine _uniswap V3 ici est 0x0000000000000000000000004300000000000000000000000000000000000004
est l’adresse de Weth
Et 0x 6 e…c 5 (adresse de l’attaquant 1) est responsable du vol de l’adresse (0), qui est l’actif natif ETH.
En définissant le champ 0, l’attaquant peut voler les actifs correspondants via la logique suivante :
question
Pourquoi l’attaquant n’a-t-il pas volé tous les actifs ?
Théoriquement, il peut voler tous les actifs, à savoir les WETH et USDB restants.
0x bf…87 (adresse de l’attaquant 3) n’a volé que 73,49 WETH. 0x bf…87 (adresse de l’attaquant 3) peut en fait emporter tous les 7350 WETH, ou vous pouvez utiliser 0x c 5…0 d (adresse de l’attaquant 2) a pris tous les 7758267 USDB. Pourquoi s’est-il arrêté après avoir pris seulement un peu de WETH ? Nous ne le savons pas. Il faudra peut-être qu’un détective de chaîne bien connu mène une enquête interne approfondie.
Pourquoi l’attaquant n’a-t-il pas transféré 17413 ETH vers le réseau principal Ethereum ?
Comme nous le savons tous, il est possible que le réseau principal Blast intercepte ces ETH via une méthode centralisée et les laisse ici en permanence sans causer de pertes substantielles aux utilisateurs. Cependant, une fois que ces ETH entrent dans le réseau principal Ethereum, il n’y a aucun moyen de les intercepter. il.
Nous avons évalué les ponts inter-chaînes actuels de Blast. Il n’y a pas de limite sur le nombre de ponts inter-chaînes officiels, mais il faut 14 jours pour sortir, ce qui est suffisant pour que les responsables de Blast préparent un plan d’interception.
Le pont cross-chain tiers peut être crédité en temps quasi réel, tout comme la source de frais de l’attaquant, et peut rapidement terminer le cross-chain.Pourquoi l’attaquant n’a-t-il pas immédiatement cross-chain ?
En effet, l’attaquant a effectué un cross-chain dès le premier instant (dans les 2 minutes suivant l’attaque) :
De plus, il a fallu 20 secondes pour que les fonds arrivent sur le réseau principal Ethereum. En théorie, un attaquant peut continuer à cross-chain et transférer une grande quantité d’ETH entre les chaînes avant que le pont cross-chain ne puisse intervenir manuellement.
Quant à savoir pourquoi il ne peut y avoir que 3 ETH à la fois, la raison est la limite de liquidité du pont inter-chaînes, de Blast à ETH :
Un autre pont multi-chaînes qui prend en charge Blast en prend encore moins en charge :
Après cette transaction cross-chain, l’attaquant n’a pas poursuivi d’autres opérations cross-chain. La raison nous est inconnue. Il semble que le “hacker d’un certain pays” n’ait pas fait de préparations adéquates pour le retrait des fonds de Blast.
Développement des événements après l’attaque
Sur la base des commentaires de l’utilisateur de la communauté Nearisbuilding, il a trouvé davantage d’informations sur l’identité de l’attaquant et a trouvé des moyens de l’inciter à restituer les fonds.
En fin de compte, avec l’attention et les efforts de la communauté du chiffrement, le « pirate informatique d’un certain pays », peut-être parce qu’il avait peur de révéler son identité, a fourni les clés privées des trois adresses d’attaquants ci-dessus à l’équipe du projet et les a toutes rendues. Les parties au projet ont également mené une opération de sauvetage : transférer tous les fonds du contrat endommagé vers le contrat multi-signatures pour les conserver.
