Analyse de l'incident d'attaque interne du projet Pump
Récemment, le projet Pump a été victime d'une attaque interne, entraînant des pertes considérables. Cet article analysera en détail cet événement.
Processus d'attaque
L'attaquant n'est pas un hacker externe, mais il est très probablement un ancien employé du projet Pump. Il a accès au portefeuille d'autorisation utilisé par Pump pour créer des paires de trading de jetons sur Raydium, que nous appelons "compte cible". Pendant ce temps, les jetons créés sur Pump mais qui n'ont pas encore atteint les normes de lancement sur Raydium sont appelés "compte préparatoire".
Des attaquants ont obtenu un prêt éclair via une plateforme de prêt, utilisant ces fonds pour remplir tous les pools qui n'atteignaient pas les normes de Raydium. En temps normal, lorsque le pool atteint les normes, les SOL dans le "compte préparatoire" devraient être transférés au "compte cible". Cependant, les attaquants ont retiré les SOL transférés durant ce processus, ce qui a empêché les tokens qui devaient être lancés sur Raydium et verrouillés dans le pool d'achever leur opération de lancement.
Analyse des victimes
Cette attaque n'a pas affecté les fonds de la plateforme de prêt, car le prêt éclair a été remboursé dans le même bloc. Les tokens déjà lancés sur Raydium, dont les LP sont verrouillés, ne devraient également pas être affectés.
Les véritables perdants sont les utilisateurs de Pump dont les piscines n'étaient pas encore remplies avant l'attaque. Tous les SOL qu'ils avaient achetés ont été transférés lors de l'attaque mentionnée ci-dessus. Cela explique également pourquoi la perte initialement estimée pourrait atteindre 80 millions de dollars ( Note : les dernières données indiquent que la perte réelle est d'environ 2 millions de dollars ).
Exploration des raisons de l'attaque
Il est clair que cet incident a révélé une négligence majeure de l'équipe du projet en matière de gestion des autorisations. Nous pouvons supposer que le remplissage du pool était peut-être l'une des responsabilités précédentes de l'attaquant, similaire à la façon dont certaines plateformes sociales utilisent des robots officiels pour simuler l'activité commerciale à leurs débuts.
Il est très probable que le projet Pump, afin de réaliser un démarrage à froid, ait chargé les attaquants d'utiliser les fonds du projet pour remplir la réserve des nouveaux tokens émis ( tels que $test, $alon, etc. ), afin de pouvoir être lancés sur Raydium et de faire monter les prix pour attirer l'attention. Mais ils n'avaient pas prévu que cela deviendrait finalement un point de rupture pour une attaque interne.
Résumé des leçons
Pour des projets similaires, il ne suffit pas de simplement imiter la surface. Il faut considérer comment fournir un élan initial, et ne pas penser que le produit entraînera naturellement des transactions.
Le projet doit accorder une grande importance à la gestion des droits et aux mesures de sécurité. Les menaces internes sont souvent plus dangereuses que les attaques externes, car les personnes internes détiennent des informations et des droits clés.
Lors de la conception du système, il est important de suivre le principe du moindre privilège, en veillant à ce que chaque rôle n'ait accès qu'aux ressources nécessaires à l'accomplissement de son travail.
Effectuer régulièrement des audits de sécurité et des vérifications des autorisations, afin de détecter et de corriger rapidement les vulnérabilités de sécurité potentielles.
Établir un processus de départ des employés complet et efficace, afin de s'assurer que tous les accès et informations sensibles soient récupérés en temps voulu lorsque l'employé part.
Cet événement nous rappelle encore une fois que dans le domaine des cryptomonnaies en rapide évolution, la sécurité doit toujours être la priorité absolue. Les équipes de projet doivent rester vigilantes et constamment améliorer les mesures de sécurité pour protéger les intérêts des utilisateurs et du projet lui-même.
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.
11 J'aime
Récompense
11
5
Partager
Commentaire
0/400
DegenWhisperer
· 07-18 14:09
pigeons encore pris 早说了别冲这种
Voir l'originalRépondre0
SleepTrader
· 07-17 10:57
Les traîtres font beaucoup de mal.
Voir l'originalRépondre0
MEVSupportGroup
· 07-15 19:32
Sans surprise, les traîtres sont toujours les plus cruels.
Voir l'originalRépondre0
gaslight_gasfeez
· 07-15 18:50
Se faire prendre pour des cons aussi doit se faire avec soin...
Analyse de l'incident d'attaque interne du projet Pump : un avertissement de perte de 2 millions de dollars
Analyse de l'incident d'attaque interne du projet Pump
Récemment, le projet Pump a été victime d'une attaque interne, entraînant des pertes considérables. Cet article analysera en détail cet événement.
Processus d'attaque
L'attaquant n'est pas un hacker externe, mais il est très probablement un ancien employé du projet Pump. Il a accès au portefeuille d'autorisation utilisé par Pump pour créer des paires de trading de jetons sur Raydium, que nous appelons "compte cible". Pendant ce temps, les jetons créés sur Pump mais qui n'ont pas encore atteint les normes de lancement sur Raydium sont appelés "compte préparatoire".
Des attaquants ont obtenu un prêt éclair via une plateforme de prêt, utilisant ces fonds pour remplir tous les pools qui n'atteignaient pas les normes de Raydium. En temps normal, lorsque le pool atteint les normes, les SOL dans le "compte préparatoire" devraient être transférés au "compte cible". Cependant, les attaquants ont retiré les SOL transférés durant ce processus, ce qui a empêché les tokens qui devaient être lancés sur Raydium et verrouillés dans le pool d'achever leur opération de lancement.
Analyse des victimes
Cette attaque n'a pas affecté les fonds de la plateforme de prêt, car le prêt éclair a été remboursé dans le même bloc. Les tokens déjà lancés sur Raydium, dont les LP sont verrouillés, ne devraient également pas être affectés.
Les véritables perdants sont les utilisateurs de Pump dont les piscines n'étaient pas encore remplies avant l'attaque. Tous les SOL qu'ils avaient achetés ont été transférés lors de l'attaque mentionnée ci-dessus. Cela explique également pourquoi la perte initialement estimée pourrait atteindre 80 millions de dollars ( Note : les dernières données indiquent que la perte réelle est d'environ 2 millions de dollars ).
Exploration des raisons de l'attaque
Il est clair que cet incident a révélé une négligence majeure de l'équipe du projet en matière de gestion des autorisations. Nous pouvons supposer que le remplissage du pool était peut-être l'une des responsabilités précédentes de l'attaquant, similaire à la façon dont certaines plateformes sociales utilisent des robots officiels pour simuler l'activité commerciale à leurs débuts.
Il est très probable que le projet Pump, afin de réaliser un démarrage à froid, ait chargé les attaquants d'utiliser les fonds du projet pour remplir la réserve des nouveaux tokens émis ( tels que $test, $alon, etc. ), afin de pouvoir être lancés sur Raydium et de faire monter les prix pour attirer l'attention. Mais ils n'avaient pas prévu que cela deviendrait finalement un point de rupture pour une attaque interne.
Résumé des leçons
Pour des projets similaires, il ne suffit pas de simplement imiter la surface. Il faut considérer comment fournir un élan initial, et ne pas penser que le produit entraînera naturellement des transactions.
Le projet doit accorder une grande importance à la gestion des droits et aux mesures de sécurité. Les menaces internes sont souvent plus dangereuses que les attaques externes, car les personnes internes détiennent des informations et des droits clés.
Lors de la conception du système, il est important de suivre le principe du moindre privilège, en veillant à ce que chaque rôle n'ait accès qu'aux ressources nécessaires à l'accomplissement de son travail.
Effectuer régulièrement des audits de sécurité et des vérifications des autorisations, afin de détecter et de corriger rapidement les vulnérabilités de sécurité potentielles.
Établir un processus de départ des employés complet et efficace, afin de s'assurer que tous les accès et informations sensibles soient récupérés en temps voulu lorsque l'employé part.
Cet événement nous rappelle encore une fois que dans le domaine des cryptomonnaies en rapide évolution, la sécurité doit toujours être la priorité absolue. Les équipes de projet doivent rester vigilantes et constamment améliorer les mesures de sécurité pour protéger les intérêts des utilisateurs et du projet lui-même.