Le projet Poolz a été attaqué en raison d'une vulnérabilité de débordement arithmétique, avec une perte d'environ 665 000 dollars.
Récemment, un incident d'attaque contre le projet Poolz a suscité une large attention au sein de la communauté des cryptomonnaies. Selon les données de surveillance en chaîne, l'attaque a eu lieu le 15 mars 2023, impliquant les réseaux Ethereum, BNB Chain et Polygon. L'attaquant a exploité une vulnérabilité de débordement arithmétique dans le contrat intelligent, réussissant à voler un montant important de jetons, d'une valeur totale d'environ 66,5 milliers de dollars.
Détails de l'attaque
L'attaquant a mené cette attaque en suivant les étapes suivantes :
Tout d'abord, vous avez échangé une certaine quantité de jetons MNZ sur une bourse décentralisée.
Ensuite, la fonction CreateMassPools du contrat Poolz a été appelée. Cette fonction était censée permettre aux utilisateurs de créer des pools de liquidité en masse et de fournir une liquidité initiale, mais elle présente une grave vulnérabilité.
Le problème se trouve dans la fonction getArraySum. Cette fonction est utilisée pour calculer la quantité de liquidités initiales fournies par l'utilisateur, mais elle n'a pas réussi à gérer correctement les cas de dépassement d'entier.
L'attaquant a habilement construit les paramètres d'entrée de sorte que le tableau _StartAmount contienne des nombres supérieurs à la valeur maximale de uint256. Cela a entraîné un dépassement de la somme accumulée, et la valeur de retour finale est de 1.
En raison du fait que le contrat utilise la valeur d'origine _StartAmount lors de l'enregistrement des attributs de la piscine, et non le nombre réel de jetons transférés, un attaquant n'a besoin de transférer qu'un seul jeton pour créer une piscine ayant une liquidité bien supérieure à la réalité.
Enfin, l'attaquant a extrait une grande quantité de jetons non autorisés en appelant la fonction withdraw, complétant ainsi l'ensemble du processus d'attaque.
Actifs volés
Cette attaque a entraîné des pertes pour plusieurs jetons, y compris mais sans s'y limiter :
2 805 805 MEE
525,134 ESNC
774 997 DON
2 007 504 238 ASW
6,510,689 KMON
2,521,065 POOLZ
35,976,107 DCD
760,845 PORTX
L'attaquant a échangé une partie des jetons volés contre des BNB, mais au moment du rapport, ces fonds n'avaient pas encore été transférés de l'adresse de l'attaquant.
Conseils de prévention
Pour éviter des vulnérabilités similaires de débordement arithmétique, les experts recommandent de prendre les mesures suivantes :
Utilisez une version plus récente du compilateur Solidity, ces versions effectueront automatiquement des vérifications de dépassement lors de la compilation.
Pour les projets utilisant une version plus ancienne de Solidity, il est recommandé d'intégrer la bibliothèque SafeMath d'OpenZeppelin pour gérer les calculs d'entiers afin d'éviter les problèmes de débordement.
Effectuer un audit de code complet, en prêtant une attention particulière aux parties impliquant des opérations sur de grands nombres.
Mettre en œuvre une validation stricte des entrées pour s'assurer que les paramètres fournis par l'utilisateur sont dans une plage raisonnable.
Envisagez d'ajouter des mécanismes de sécurité tels que des signatures multiples ou des verrous temporels dans les opérations critiques.
Cet incident souligne à nouveau l'importance de la sécurité des contrats intelligents, rappelant aux développeurs et aux équipes de projet qu'ils doivent rester vigilants et continuer à améliorer la sécurité du code. De plus, cela rappelle aux utilisateurs d'être particulièrement prudents lorsqu'ils interagissent avec des projets de finance décentralisée, en particulier lors de la participation à des projets nouvellement lancés ou non suffisamment audités.
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.
18 J'aime
Récompense
18
8
Partager
Commentaire
0/400
GateUser-a5fa8bd0
· 07-23 01:44
Encore un problème avec le contrat, tsk tsk.
Voir l'originalRépondre0
SellTheBounce
· 07-20 10:40
Encore un pigeon chute à zéro, un scénario familier.
Voir l'originalRépondre0
DataBartender
· 07-20 02:14
Écouter un discours et boire une tasse de thé.
Voir l'originalRépondre0
GasFeeCrying
· 07-20 02:13
Encore une histoire noire, je me suis échappé.
Voir l'originalRépondre0
LazyDevMiner
· 07-20 02:13
Un autre cas d'avertissement de dépassement de zéro.
Voir l'originalRépondre0
DEXRobinHood
· 07-20 02:13
Encore une entreprise sombre, qui est la prochaine ?
Voir l'originalRépondre0
SandwichVictim
· 07-20 02:08
Encore un projet qui a pris les gens pour des idiots, il s'est échappé.
Le projet Poolz a subi une attaque par débordement arithmétique, entraînant une perte de 665 000 $ en actifs de chiffrement.
Le projet Poolz a été attaqué en raison d'une vulnérabilité de débordement arithmétique, avec une perte d'environ 665 000 dollars.
Récemment, un incident d'attaque contre le projet Poolz a suscité une large attention au sein de la communauté des cryptomonnaies. Selon les données de surveillance en chaîne, l'attaque a eu lieu le 15 mars 2023, impliquant les réseaux Ethereum, BNB Chain et Polygon. L'attaquant a exploité une vulnérabilité de débordement arithmétique dans le contrat intelligent, réussissant à voler un montant important de jetons, d'une valeur totale d'environ 66,5 milliers de dollars.
Détails de l'attaque
L'attaquant a mené cette attaque en suivant les étapes suivantes :
Tout d'abord, vous avez échangé une certaine quantité de jetons MNZ sur une bourse décentralisée.
Ensuite, la fonction CreateMassPools du contrat Poolz a été appelée. Cette fonction était censée permettre aux utilisateurs de créer des pools de liquidité en masse et de fournir une liquidité initiale, mais elle présente une grave vulnérabilité.
Le problème se trouve dans la fonction getArraySum. Cette fonction est utilisée pour calculer la quantité de liquidités initiales fournies par l'utilisateur, mais elle n'a pas réussi à gérer correctement les cas de dépassement d'entier.
L'attaquant a habilement construit les paramètres d'entrée de sorte que le tableau _StartAmount contienne des nombres supérieurs à la valeur maximale de uint256. Cela a entraîné un dépassement de la somme accumulée, et la valeur de retour finale est de 1.
En raison du fait que le contrat utilise la valeur d'origine _StartAmount lors de l'enregistrement des attributs de la piscine, et non le nombre réel de jetons transférés, un attaquant n'a besoin de transférer qu'un seul jeton pour créer une piscine ayant une liquidité bien supérieure à la réalité.
Enfin, l'attaquant a extrait une grande quantité de jetons non autorisés en appelant la fonction withdraw, complétant ainsi l'ensemble du processus d'attaque.
Actifs volés
Cette attaque a entraîné des pertes pour plusieurs jetons, y compris mais sans s'y limiter :
L'attaquant a échangé une partie des jetons volés contre des BNB, mais au moment du rapport, ces fonds n'avaient pas encore été transférés de l'adresse de l'attaquant.
Conseils de prévention
Pour éviter des vulnérabilités similaires de débordement arithmétique, les experts recommandent de prendre les mesures suivantes :
Utilisez une version plus récente du compilateur Solidity, ces versions effectueront automatiquement des vérifications de dépassement lors de la compilation.
Pour les projets utilisant une version plus ancienne de Solidity, il est recommandé d'intégrer la bibliothèque SafeMath d'OpenZeppelin pour gérer les calculs d'entiers afin d'éviter les problèmes de débordement.
Effectuer un audit de code complet, en prêtant une attention particulière aux parties impliquant des opérations sur de grands nombres.
Mettre en œuvre une validation stricte des entrées pour s'assurer que les paramètres fournis par l'utilisateur sont dans une plage raisonnable.
Envisagez d'ajouter des mécanismes de sécurité tels que des signatures multiples ou des verrous temporels dans les opérations critiques.
Cet incident souligne à nouveau l'importance de la sécurité des contrats intelligents, rappelant aux développeurs et aux équipes de projet qu'ils doivent rester vigilants et continuer à améliorer la sécurité du code. De plus, cela rappelle aux utilisateurs d'être particulièrement prudents lorsqu'ils interagissent avec des projets de finance décentralisée, en particulier lors de la participation à des projets nouvellement lancés ou non suffisamment audités.