Poolz subit une attaque par dépassement arithmétique, avec une perte d'environ 66,5 milliers de dollars.
Dans la nuit du 15 mars 2023, Poolz a été attaqué sur les réseaux Ethereum, BNB Chain et Polygon, entraînant des pertes de plusieurs actifs de tokens, d'une valeur totale d'environ 665 000 dollars. Les attaquants ont exploité une vulnérabilité de dépassement arithmétique dans le contrat intelligent, contournant avec succès les restrictions sur le transfert de fonds.
Selon la surveillance des données en chaîne, cette attaque implique plusieurs tokens, y compris MEE, ESNC, DON, ASW, KMON, POOLZ, etc. Les attaquants ont échangé une partie des tokens de profit contre des BNB, mais ces fonds n'ont pas encore été transférés.
Le processus d'attaque se divise principalement en trois étapes :
L'attaquant a d'abord échangé une petite quantité de jetons MNZ via un certain DEX.
Ensuite, la fonction CreateMassPools du contrat Poolz a été appelée. Cette fonction était censée être utilisée pour créer en masse des pools de liquidité et fournir une liquidité initiale, mais elle présente une vulnérabilité critique.
La vulnérabilité se trouve dans la fonction getArraySum. Cette fonction additionne les éléments du tableau _StartAmount, mais elle ne prend pas en compte les situations de débordement. Un attaquant a soigneusement construit un tableau qui provoque un débordement de uint256, ce qui fait que la valeur de retour de la fonction est 1, alors que la valeur réelle enregistrée de _StartAmount est un nombre immense.
Enfin, l'attaquant appelle la fonction withdraw pour retirer des fonds, complétant ainsi l'ensemble du processus d'attaque.
Cet incident souligne à nouveau le danger des problèmes de dépassement arithmétique dans les contrats intelligents. Pour prévenir des attaques similaires, les développeurs devraient envisager les recommandations suivantes :
Utilisez une version plus récente du compilateur Solidity, qui intègre un mécanisme de vérification des débordements.
Dans les versions inférieures de Solidity, il est possible d'importer des bibliothèques de sécurité tierces comme SafeMath d'OpenZeppelin pour traiter les opérations sur les entiers.
Effectuer un audit complet du code, en mettant particulièrement l'accent sur les parties impliquant des calculs mathématiques.
Mettre en œuvre des mesures de sécurité supplémentaires telles que la signature multiple pour ajouter une couche de protection aux opérations critiques.
Cet événement nous rappelle à nouveau que, dans l'écosystème blockchain, le code est la loi. Les équipes de développement doivent toujours rester vigilantes et améliorer continuellement les pratiques de sécurité pour protéger les actifs des utilisateurs et la réputation du projet.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
17 J'aime
Récompense
17
6
Partager
Commentaire
0/400
DataPickledFish
· Il y a 12h
typique débutant rédacteur de contrats
Voir l'originalRépondre0
AltcoinMarathoner
· Il y a 13h
Un autre obstacle dans le marathon DeFi
Voir l'originalRépondre0
TokenVelocity
· Il y a 13h
Pourquoi notre protection est-elle si faible ?
Voir l'originalRépondre0
ImpermanentPhobia
· Il y a 13h
Le contrat a encore un trou, débordement.
Voir l'originalRépondre0
ForkYouPayMe
· Il y a 14h
Un autre exemple de débordement arithmétique
Voir l'originalRépondre0
degenonymous
· Il y a 14h
Les vulnérabilités des contrats sont difficilement évitables
Poolz subit une attaque par débordement arithmétique, perte de 665 000 dollars, plusieurs actifs multi-chaînes affectés.
Poolz subit une attaque par dépassement arithmétique, avec une perte d'environ 66,5 milliers de dollars.
Dans la nuit du 15 mars 2023, Poolz a été attaqué sur les réseaux Ethereum, BNB Chain et Polygon, entraînant des pertes de plusieurs actifs de tokens, d'une valeur totale d'environ 665 000 dollars. Les attaquants ont exploité une vulnérabilité de dépassement arithmétique dans le contrat intelligent, contournant avec succès les restrictions sur le transfert de fonds.
Selon la surveillance des données en chaîne, cette attaque implique plusieurs tokens, y compris MEE, ESNC, DON, ASW, KMON, POOLZ, etc. Les attaquants ont échangé une partie des tokens de profit contre des BNB, mais ces fonds n'ont pas encore été transférés.
Le processus d'attaque se divise principalement en trois étapes :
L'attaquant a d'abord échangé une petite quantité de jetons MNZ via un certain DEX.
Ensuite, la fonction CreateMassPools du contrat Poolz a été appelée. Cette fonction était censée être utilisée pour créer en masse des pools de liquidité et fournir une liquidité initiale, mais elle présente une vulnérabilité critique.
La vulnérabilité se trouve dans la fonction getArraySum. Cette fonction additionne les éléments du tableau _StartAmount, mais elle ne prend pas en compte les situations de débordement. Un attaquant a soigneusement construit un tableau qui provoque un débordement de uint256, ce qui fait que la valeur de retour de la fonction est 1, alors que la valeur réelle enregistrée de _StartAmount est un nombre immense.
Enfin, l'attaquant appelle la fonction withdraw pour retirer des fonds, complétant ainsi l'ensemble du processus d'attaque.
Cet incident souligne à nouveau le danger des problèmes de dépassement arithmétique dans les contrats intelligents. Pour prévenir des attaques similaires, les développeurs devraient envisager les recommandations suivantes :
Utilisez une version plus récente du compilateur Solidity, qui intègre un mécanisme de vérification des débordements.
Dans les versions inférieures de Solidity, il est possible d'importer des bibliothèques de sécurité tierces comme SafeMath d'OpenZeppelin pour traiter les opérations sur les entiers.
Effectuer un audit complet du code, en mettant particulièrement l'accent sur les parties impliquant des calculs mathématiques.
Mettre en œuvre des mesures de sécurité supplémentaires telles que la signature multiple pour ajouter une couche de protection aux opérations critiques.
Cet événement nous rappelle à nouveau que, dans l'écosystème blockchain, le code est la loi. Les équipes de développement doivent toujours rester vigilantes et améliorer continuellement les pratiques de sécurité pour protéger les actifs des utilisateurs et la réputation du projet.