Alors que les protocoles DeFi continuent de se réchauffer dans l'écosystème Ethereum, CipherTrace voit de plus en plus d'exploits et de vecteurs d'attaque se faire jour. La semaine dernière, le 28 décembre 2020, le contrat d'extraction de bouclier de Cover Protocol, Blacksmith, a été exploité. Les pirates ont utilisé un bogue dans le contrat minier pour frapper une quantité infinie de jetons COVER et drainer plus de 4.4 millions de dollars du projet.
Protocole de couverture libéré leur post-mortem hier déclarant que, inconnu des développeurs, le bogue était présent depuis le déploiement initial du contrat Blacksmith, soulignant l'importance d'audits de sécurité approfondis et de pentesting de contrats intelligentsQue sont les contrats intelligents? Un contrat intelligent est un pro de l'informatique… Plus.
Une chronologie de la frappe infinie
La chronologie de l'attaquant initial
- Le nouveau pool de liquidités Balancer était ajoutée au contrat Blacksmith.sol.
- Attaquant Cautions 1,326,879.99 XNUMX XNUMX jetons BPT dans le contrat Blacksmith.sol.
- Même attaquant alors exécute l'exploit, en retirant des fonds du contrat.
- L'attaquant a pu continuer frapper des récompenses et retirer des fonds s'élevant à environ 4.4 M $.
Dans une tournure intéressante des événements, les prétendus «hackers blancs» liés à Grap Finance ont également exploité le bogue pour générer environ 4 millions de dollars de jetons COVER. Grap Finance a finalement retourné les fonds à Cover Protocol.
Chronologie des comptes détenus en externe (EOA) de Grap Finance Deployer
- Le nouveau pool de liquidité était , pour l'extraction de liquidité.
- EOA de déploiement de Grap Finance déposé 15,255.55 BPT (DAI / Base) dans le pool sur Cover via le contrat Blacksmith.sol.
- Environ quatre minutes plus tard, les fonds ont été retiré sur la couverture laissant 1 Wei dans le solde EOA du Deployer Grap Finance.
- Un autre utilisateur extérieur retiré la majeure partie de leur solde provient du contrat Blacksmith.sol à peu près à la même époque qui a conduit Grap Finance avec toutes les liquidités pour le pool DAI / Basis sur le contrat Blacksmith.sol.
- Déployeur de Grap Finance déposé retour 15,255.55 BPT (DAI / Base) dans la piscine.
- Puis Grap Finance Deployer prétentions les récompenses et, en raison de l'exploit, les frappes 40,796,131,214,802,500,000.21 COUVERTURE.
- Après avoir brûlé les jetons frappés, Grap Finance Deployer envoie retour Ether to Cover déclarant «La prochaine fois, prends soin de ta propre merde.»
Comment frapper des jetons infinis - Une analyse technique
Contexte
Cet exploit nous ramène aux fondamentaux du langage de programmation Solidity, qui est utilisé pour mettre en œuvre des contrats intelligents au sein d'Ethereum. Une fois ces contrats compilés, la machine virtuelle Ethereum (EVM) sera en mesure de comprendre les instructions (c'est-à-dire les opcodes) qui sont utilisées pour exécuter diverses fonctions et manipuler la mémoire et le stockage. L'EVM dispose de trois zones différentes où il peut stocker des données: mémoire, stockage et pile. Comprendre ces domaines est important pour comprendre comment le bogue a été exploité.
Semblable à la mémoire RAM (Random Access Memory) sur un périphérique informatique, le "Mémoire»Le mot-clé dans Solidity alloue de la mémoire pour une variable spécifique. Dans ce cas, cette variable porte sur une fonction spécifique. La mémoire est effacée une fois la fonction exécutée, mais pourrait rester si le contenu de cette mémoire est mis en mémoire avant le retour de la fonction.
Le "storage”Dans Solidity permet aux variables d'agir comme un pointeur dans le stockage des données dans des mappages ou des structures de données. Les données de stockage sont persistantes entre les appels de fonction et les transactions. Sous le capot, le stockage est essentiellement un magasin de valeurs-clés qui mappe des mots de 256 bits à des mots de 256 bits.
Notez que l'EVM n'est pas une machine de registre mais une machine de pile - ainsi tous les calculs sont effectués sur une zone de données appelée la pile. La pile a une capacité maximale de 1024 éléments, mais seuls les 16 premiers sont facilement accessibles, ce qui peut être utilisé pour échanger l'élément le plus haut avec l'un des 16 éléments en dessous et plus.
L'insecte
Les pirates ont exploité Blacksmith.sol de Cover Protocol, un contrat de Shield Mining qui permet aux acteurs d'être récompensés dans les jetons du projet ou du pool spécifique, tels que les jetons CLAIM et NOCLAIM, dans le protocole de couverture.
Pour mieux comprendre le bug, regardons d'abord le public piscines variable qui est un mappage (c'est-à-dire le stockage des données):
At ligne 118, on voit que le contrat met en cache les données du pool en mémoire via le mot clé «memory».
Puis sur ligne 121, le contrat met à jour le pool en stockage lorsque le updatePool (adresse _lpToken) fonction utilise une Pool de stockage de piscine variable.
Cependant, si vous regardez plus loin dans le caution (adresse _lpToken, uint256 _amount) fonction, il utilise la même pool variable de la ligne 118 qui a été mise en mémoire cache dans la fonction pour les calculs pour pool.accRewardsPerToken. À ce stade, le pool variable a été copiée à partir du piscines mappage et a été enregistré dans la mémoire.
Par conséquent, toute modification apportée au pool variable dans le caution (adresse _lpToken, uint256 _amount) ne changera pas le piscines mappage dans le stockage en chaîne du contrat en raison du fait que les variables qui utilisent le mot-clé «memory» sont uniquement étendues dans la fonction elle-même. À partir de là, le contrat met à jour le pool.accRewardsPerToken au sein du updatePool (adresse _lpToken) fonction, qui utilise le stockage. Alors maintenant, dans le updatePool (adresse _lpToken) fonction le pool.accRewardsPerToken qui est mis à jour augmente considérablement car il s'agissait techniquement d'un nouveau pool et non associé au pool en mémoire.
Suite à cette vulnérabilité et à une mauvaise utilisation entre la mémoire et le stockage, le mineur.rewardWriteoff au sein du caution (adresse _lpToken, uint256 _amount) la fonction est mal calculée et utilise le mauvais pool.accRewardsPerToken, car nous sommes toujours dans la fonction de dépôt qui gère une instance en mémoire cache de pool.
En plus de la fonction de dépôt, n'importe qui, comme Grap Finance, peut obtenir une quantité insensée de jetons frappés lors de l'exécution du claimRewards (adresse _lpToken) fonction. Cette fonction, qui sert à récupérer leurs récompenses, finit par appeler _claimCoverRewards (pool de mémoire de pool, mineur de mémoire mineur) qui fait référence au mineur.rewardWriteoff que nous avons souligné ci-dessus. Comme cette variable est beaucoup plus petite que la valeur réelle pool.accRewardsPerToken, le contrat entraîne la création d'une abondance de jetons.
Faits marquants
CipherTrace espère que ce contexte dans le bogue exploité met en lumière l'importance d'audits de sécurité approfondis et de pentesting des contrats intelligents sur n'importe quel blockchainUne blockchain - la technologie sous-jacente au bitcoin et à d'autres c… Plus on choisit de se déployer sur. Alors que Grap Finance a retourné les fonds reçus grâce à l'exploit, le pirate informatique d'origine était toujours en mesure de retirer plus de 4 millions de dollars du protocole DeFi, et la valeur du jeton COVER a depuis chuté de près de 99%.
Source : https://ciphertrace.com/infinite-minting-exploit-nets-attacker-4-4m/