Analyse de l'incident de l'attaque Hedgey : perte de dizaines de millions de dollars en autorisation symbolique

Le 19 avril 2024, le contrat Hedgey Token Claim a été attaqué sur plusieurs chaînes telles que Ethereum et Arbitrum, provoquant des pertes de plusieurs dizaines de millions de dollars. L'équipe du projet Hedgey a immédiatement émis une alerte de sécurité, rappelant aux utilisateurs qui ont créé des activités de réclamation de jetons d'annuler les activités de réclamation de jetons via les canaux officiels. (https://twitter.com/hedgeyfinance/status/1781257581488418862)

Attack Brief

Hedgey aide les DAO et les organisations en chaîne à distribuer des jetons via l'émission de jetons en chaîne et programmatique. sont distribués à leur équipe, leurs contributeurs, leurs investisseurs et leur communauté. L'outil où la vulnérabilité s'est produite cette fois est son produit Token Claims, qui permet aux utilisateurs de créer une page de réclamation de jeton, d'ajouter plus de 100 000 destinataires à la liste blanche via des fichiers CSV et de contrôler la manière de transmettre les flux, les verrous temporels, les jetons réclamés peuvent être rejetés par le recyclage ou d’autres méthodes.

La vulnérabilité du contrat exploitée par cette attaque est que lorsque le contrat ClaimCampaigns dans le produit Token Claims crée un événement de réclamation de jeton, il autorise son jeton à l'adresse spécifiée par le créateur. Lorsque le créateur annule la réclamation de l'événement, le jeton transféré par le créateur pendant la phase de création de l'événement est renvoyé à une autre adresse spécifiée par le créateur, mais l'autorisation du jeton n'est pas révoquée, ce qui permet à l'adresse du créateur de l'événement de toujours utiliser les informations. autorisé par le jeton ClaimCampaigns.

Adresses clés impliquées dans l'attaque

Cette attaque implique plusieurs transactions. Nous utilisons uniquement la transaction suivante pour voler des jetons NOBL à titre d'exemple pour analyser le principe de l'attaque.

Transaction d'attaque : https://etherscan.io/tx/0x017ce9593350cba65d506e1a87e52d2c20079fdfa80a350a89fe6fc875f2d9f9

Attaque EOA :

0 xded2b1a426e1b7d415a40bcad44e98f47181dda2

Attaquant (contrat) :

0xd818ff3d5cfc938014b270d0c8029ba04629b549

Contrat vulnérable ( ClaimCampaigns) :

0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511

Jeton volé (NobleBlocks : jeton NOBL) :

0x88b9f5c663 42ebaf661b3e2836b807c8cb1b3195

Analyse du processus d'attaque

1.Mise en œuvre de l'attaque

Dans la phase de mise en œuvre de l'attaque, L'attaquant a appelé à plusieurs reprises la fonction "createLockedCampaign" du contrat vulnérable pour créer une campagne, puis a appelé la fonction "cancelCampaign" pour supprimer la campagne. Lors de la création d'une campagne, l'attaquant transfère un nombre spécifié de jetons NOBL vers le contrat de vulnérabilité et obtient la limite d'utilisation des jetons NOBL autorisée par le contrat de vulnérabilité. Lorsque la campagne est supprimée, le contrat de vulnérabilité renvoie les tokens NOBL que l'attaquant a transférés lors de la création de la campagne. Cependant, à ce stade, le contrat de vulnérabilité ne révoque pas la limite d'utilisation du token NOBL autorisée à l'attaquant. Par conséquent, en créant une campagne puis en supprimant la campagne, l'attaquant peut obtenir le pouvoir de dépenser à partir de rien les jetons NOBL détenus par le contrat vulnérable.

Les étapes spécifiques de l'attaque sont les suivantes :

L'attaquant appelle la fonction "createLockedCampaign" du contrat vulnérable pour créer une campagne et définit à la fois "campaign.manager" et "claimLockup.tokenLocker" dans les paramètres de l'attaquant. lui-même, et définit "campaign.token" " est défini sur les jetons NOBL, " campagne.amount " est défini sur " 680000000000000000000000 " (la décimale des jetons NOBL est 18, cela représente donc 680 000 jetons NOBL) et " donation.amount " est mis à 0. Comme le montre le code de la fonction "createLockedCampaign", l'attaquant transfère d'abord les jetons NOBL vers le contrat vulnérable, puis utilise la fonction "safeIncreaseAllowance" pour autoriser le contrat vulnérable à "claimLockup.tokenLocker" (l'attaquant) pour dépenser le fonds détenus par le contrat vulnérable. La puissance des jetons NOBL autorise ici autant de « montant de campagne » à l'attaquant.

1. 

   L'attaquant appelle la fonction "cancelCampaign" pour supprimer la campagne créée à l'étape 1. Comme le montre le code de la fonction, le contrat vulnérable supprime les données de la campagne et appelle la fonction "withdrawTokens" du Bibliothèque TransferHelper pour supprimer la campagne à l'étape 1. Dans cette étape, les tokens NOBL transférés par l'attaquant sont renvoyés à "campaign.manager" (attaquant). À ce stade, la campagne a été annulée avec succès. Cependant, le quota d'utilisation du jeton NOBL autorisé par le contrat de vulnérabilité à l'attaquant à l'étape 1 n'a pas été supprimé simultanément. Par conséquent, l’attaquant a également le pouvoir de dépenser les jetons NOBL du contrat vulnérable à ce moment-là.





2. L'attaquant a répété les étapes 1 et 2 25 fois et a finalement obtenu le quota d'utilisation de 680 000 * 25 = 1 700 000 de jetons NOBL du contrat vulnérable.

2. Récolte de l'argent volé

Au stade de la récolte de l'argent volé, l'attaquant appelle directement la fonction "transferFrom" du token NOBL pour transférer le token NOBL du contrat vulnérable vers l'adresse EOA de l'attaquant. En raison de l'attaque pendant la phase de mise en œuvre de l'attaque, l'attaquant a obtenu le droit de dépenser les jetons NOBL détenus par le contrat vulnérable, de sorte que la vérification de la limite dans la fonction « transferFrom » peut se dérouler sans problème et, finalement, l'attaquant a réussi à voler les jetons NOBL dans le contrat vulnérable.

Veuillez vérifier la transaction pour plus de détails : https://etherscan.io/tx/0x47da1ac72d488f746865891c9196c1632ae04f018b285b762b2b564ad1d3a9e5

Transactions impliquées dans l'attaque

Grâce à l'analyse des données ZAN KYT, l'attaquant avant de retirer le jeton NOBL à la personne vulnérable contract , en utilisant la vulnérabilité du contrat pour permettre au contrat vulnérable de donner à l'attaquant l'approbation du hachage de transaction du jeton comme suit (seules les transactions sur Ethereum sont répertoriées) :

Actuellement, l'attaquant a transféré une partie des gains illégaux à une autre adresse 0xd84f48b7D1AaFA7bd5905c95c5d1ffB2625AdA46 , il n'y a actuellement aucune autre action. Le développeur du contrat de réclamation (0x5a4bC2bdA1f6B9929b6efdCef4728246bEc4C635) a contacté l'attaquant via le chat Blockscan, a admis la vulnérabilité du contrat et a supposé que son comportement était une opération chapeau blanc, en espérant que l'attaquant le contacterait dans les 24 heures.

Recommandations de sécurité

En analysant cet incident d'attaque, nous avons les suggestions suivantes :

1. Revoir strictement le fonctionnement de l'autorisation de jeton dans le projet. Les développeurs de projets et les auditeurs contractuels doivent clarifier quels scénarios commerciaux nécessitent une autorisation de jeton et quels scénarios commerciaux nécessitent une autorisation de jeton recyclé pour éviter qu'une autorisation de jeton non récupérée ou des autorisations redondantes inattendues ne soient utilisées par des attaquants.

2. Le projet devrait mettre en place un mécanisme de suspension d'urgence. Il est recommandé que les projets impliquant la circulation des capitaux établissent un mécanisme de suspension complet afin que les pertes puissent être stoppées à temps lorsqu'une attaque se produit.

Cet article a été co-écrit par Cara (compte X @Cara6289) et XiG (compte X @SHXiGi) de l'équipe ZAN.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!