Analyse de l'incident de vulnérabilité des smart contracts Pump
Récemment, la plateforme Pump a subi un incident de vulnérabilité des smart contracts, entraînant une perte d'environ 2 millions de dollars. Cet article analysera en détail le déroulement de l'incident, les méthodes d'attaque et leurs impacts.
Analyse du processus d'attaque
L'attaquant n'est pas un hacker avancé, mais probablement un ancien employé de Pump. Il a accès à un portefeuille de permissions utilisé pour créer des paires de trading de jetons sur une certaine plateforme d'échange décentralisée, que nous appelons "compte vulnérable". Le pool de liquidité des jetons qui n'ont pas encore atteint les normes de listing sur Pump est appelé "compte préparatoire".
L'attaquant a d'abord obtenu un prêt flash d'une plateforme de prêt, afin de remplir tous les pools de liquidités des tokens qui n'atteignaient pas les standards de mise en vente. Normalement, lorsque le pool atteint les standards de mise en vente, le SOL dans le compte préparatoire serait transféré au compte exploit. Cependant, l'attaquant a retiré le SOL transféré pendant ce processus, ce qui a empêché ces tokens d'être mis en vente comme prévu (en raison d'un manque de fonds dans le pool).
Analyse des victimes
Selon l'analyse, les victimes sont principalement des utilisateurs qui avaient acheté des tokens dont les pools n'étaient pas encore complètement remplis sur la plateforme Pump avant l'attaque. Les SOL de ces utilisateurs ont été transférés par la méthode d'attaque mentionnée ci-dessus, ce qui explique également pourquoi le montant des pertes est si élevé.
Il convient de noter que les jetons déjà répertoriés, dont la liquidité est verrouillée, ne devraient pas être affectés. De plus, les fonds des prêts flash ont été remboursés dans le même bloc, donc la plateforme de prêt n'a également pas subi de pertes.
Discussion sur les causes des vulnérabilités
Cet incident a révélé de graves défauts dans la gestion des autorisations de la plateforme Pump. Il est supposé que les attaquants auraient pu être responsables du remplissage des pools de tokens, similaire aux stratégies de market making adoptées par certaines plateformes à leurs débuts pour créer du buzz.
La plateforme Pump pourrait, pour réaliser un démarrage à froid, déléguer à des attaquants l'utilisation des fonds du projet pour alimenter les pools de nouveaux jetons émis (comme $test, $alon, etc.), afin que ces jetons puissent être listés et attirer l'attention. Cependant, cette pratique est finalement devenue une menace pour la sécurité.
Leçons apprises
La gestion des permissions est cruciale : l'équipe du projet doit contrôler strictement les permissions clés, mettre à jour régulièrement les clés et mettre en œuvre des mesures de sécurité telles que la signature multiple.
La stratégie de liquidité initiale doit être prudente : bien qu'il soit important de donner un coup de pouce initial aux nouveaux projets, il est nécessaire de trouver un équilibre entre sécurité et efficacité.
L'audit de code est indispensable : effectuez régulièrement des audits complets des smart contracts pour détecter et corriger rapidement les vulnérabilités potentielles.
Mécanisme de réponse d'urgence : établir un mécanisme de réponse rapide pour pouvoir agir rapidement en cas d'incident de sécurité, afin de minimiser les pertes.
Transparence et communication : Après un événement, communiquer rapidement et de manière transparente avec la communauté, expliquer la situation et proposer des solutions, aide à maintenir la confiance des utilisateurs.
Cet événement nous rappelle une fois de plus que dans le domaine en rapide évolution des cryptomonnaies, la sécurité est toujours la priorité absolue. Les équipes de projet doivent constamment améliorer les mesures de sécurité, et les utilisateurs doivent également rester vigilants et participer avec prudence à divers nouveaux projets.
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.
14 J'aime
Récompense
14
4
Partager
Commentaire
0/400
WhaleMinion
· 07-14 01:20
C'est encore un cas typique d'infiltration par un traître.
La vulnérabilité des smart contracts Pump a entraîné une perte de 2 millions de dollars, un ancien employé pourrait être impliqué.
Analyse de l'incident de vulnérabilité des smart contracts Pump
Récemment, la plateforme Pump a subi un incident de vulnérabilité des smart contracts, entraînant une perte d'environ 2 millions de dollars. Cet article analysera en détail le déroulement de l'incident, les méthodes d'attaque et leurs impacts.
Analyse du processus d'attaque
L'attaquant n'est pas un hacker avancé, mais probablement un ancien employé de Pump. Il a accès à un portefeuille de permissions utilisé pour créer des paires de trading de jetons sur une certaine plateforme d'échange décentralisée, que nous appelons "compte vulnérable". Le pool de liquidité des jetons qui n'ont pas encore atteint les normes de listing sur Pump est appelé "compte préparatoire".
L'attaquant a d'abord obtenu un prêt flash d'une plateforme de prêt, afin de remplir tous les pools de liquidités des tokens qui n'atteignaient pas les standards de mise en vente. Normalement, lorsque le pool atteint les standards de mise en vente, le SOL dans le compte préparatoire serait transféré au compte exploit. Cependant, l'attaquant a retiré le SOL transféré pendant ce processus, ce qui a empêché ces tokens d'être mis en vente comme prévu (en raison d'un manque de fonds dans le pool).
Analyse des victimes
Selon l'analyse, les victimes sont principalement des utilisateurs qui avaient acheté des tokens dont les pools n'étaient pas encore complètement remplis sur la plateforme Pump avant l'attaque. Les SOL de ces utilisateurs ont été transférés par la méthode d'attaque mentionnée ci-dessus, ce qui explique également pourquoi le montant des pertes est si élevé.
Il convient de noter que les jetons déjà répertoriés, dont la liquidité est verrouillée, ne devraient pas être affectés. De plus, les fonds des prêts flash ont été remboursés dans le même bloc, donc la plateforme de prêt n'a également pas subi de pertes.
Discussion sur les causes des vulnérabilités
Cet incident a révélé de graves défauts dans la gestion des autorisations de la plateforme Pump. Il est supposé que les attaquants auraient pu être responsables du remplissage des pools de tokens, similaire aux stratégies de market making adoptées par certaines plateformes à leurs débuts pour créer du buzz.
La plateforme Pump pourrait, pour réaliser un démarrage à froid, déléguer à des attaquants l'utilisation des fonds du projet pour alimenter les pools de nouveaux jetons émis (comme $test, $alon, etc.), afin que ces jetons puissent être listés et attirer l'attention. Cependant, cette pratique est finalement devenue une menace pour la sécurité.
Leçons apprises
La gestion des permissions est cruciale : l'équipe du projet doit contrôler strictement les permissions clés, mettre à jour régulièrement les clés et mettre en œuvre des mesures de sécurité telles que la signature multiple.
La stratégie de liquidité initiale doit être prudente : bien qu'il soit important de donner un coup de pouce initial aux nouveaux projets, il est nécessaire de trouver un équilibre entre sécurité et efficacité.
L'audit de code est indispensable : effectuez régulièrement des audits complets des smart contracts pour détecter et corriger rapidement les vulnérabilités potentielles.
Mécanisme de réponse d'urgence : établir un mécanisme de réponse rapide pour pouvoir agir rapidement en cas d'incident de sécurité, afin de minimiser les pertes.
Transparence et communication : Après un événement, communiquer rapidement et de manière transparente avec la communauté, expliquer la situation et proposer des solutions, aide à maintenir la confiance des utilisateurs.
Cet événement nous rappelle une fois de plus que dans le domaine en rapide évolution des cryptomonnaies, la sécurité est toujours la priorité absolue. Les équipes de projet doivent constamment améliorer les mesures de sécurité, et les utilisateurs doivent également rester vigilants et participer avec prudence à divers nouveaux projets.