Analyse de l'incident d'attaque du projet Pump par un Hacker
Récemment, le projet Pump a été victime d'un grave incident de sécurité, entraînant d'importantes pertes financières. Cet article analysera les détails de cet incident.
Processus d'attaque
Cette attaque n'a pas été réalisée par un hacker talentueux, mais probablement par un ancien employé du projet Pump. L'attaquant a maîtrisé le portefeuille de permissions utilisé par Pump pour créer des paires de trading sur Raydium, que nous appelons "compte attaqué". Pendant ce temps, tous les pools LP de Bonding Curve sur Pump qui n'ont pas encore atteint les normes de mise en ligne sur Raydium sont appelés "compte préparatoire".
L'attaquant a obtenu une grande quantité de fonds via un prêt éclair pour remplir tous les pools qui n'atteignaient pas les normes de Raydium. Normalement, lorsque le pool atteint les normes, les SOL dans le "compte préparatoire" devraient être transférés dans le "compte attaqué". Cependant, l'attaquant a siphonné les SOL transférés au cours de ce processus, empêchant ainsi les tokens qui auraient dû être listés sur Raydium et verrouillés dans le pool de le faire.
Analyse des victimes
Il est à noter que le fournisseur de prêts flash n'a pas subi de pertes, car le prêt a été remboursé dans le même bloc. De plus, les jetons déjà lancés sur Raydium ne devraient pas être affectés, car les LP sont déjà verrouillés.
Les véritables victimes sont les utilisateurs dans les piscines de Pump qui n'étaient pas encore remplies avant l'attaque. Les SOL achetés par ces utilisateurs ont été transférés par les attaquants, ce qui explique pourquoi le montant des pertes initialement estimé atteignait 80 millions de dollars. Cependant, selon les dernières nouvelles, la perte réelle est d'environ 2 millions de dollars.
Exploration des causes de l’attaque
Il est évident 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 antérieures de l'attaquant. Semblable aux robots qui ont massivement acheté des clés au début de FriendTech V1, il est très probable que cela ait été mis en place par les responsables pour guider l'enthousiasme initial.
On peut oser supposer que le projet Pump, pour réaliser un démarrage à froid, a peut-être laissé les hackers responsables de l'utilisation des fonds du projet pour remplir le pool des nouveaux tokens émis (comme $test, $alon, etc.), afin qu'ils puissent être lancés sur Raydium et créer de l'engouement. Cependant, ils n'avaient pas prévu que cela deviendrait finalement une porte d'entrée pour une menace interne.
Leçons tirées
Pour les projets de type imitation, il ne suffit pas de copier les fonctionnalités de surface. Développer un produit ne signifie pas nécessairement que des gens viendront échanger. Lors de l'exploitation de plateformes d'entraide, il est crucial de fournir un élan initial.
Plus important encore, l'équipe du projet doit accorder une grande importance à la gestion des droits et aux mesures de sécurité. Cet incident prouve une fois de plus que les menaces internes peuvent être plus dangereuses et plus difficiles à prévenir que les attaques externes.
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.
23 J'aime
Récompense
23
7
Reposter
Partager
Commentaire
0/400
FundingMartyr
· 08-07 20:28
Les traîtres causent le plus de mal.
Voir l'originalRépondre0
TokenTherapist
· 08-05 18:16
Les traîtres seront punis par le ciel.
Voir l'originalRépondre0
WhaleMinion
· 08-05 12:38
Les traîtres agissent avec la plus grande cruauté.
Voir l'originalRépondre0
HodlNerd
· 08-05 12:34
Les menaces internes dominent statistiquement les exploits.
Voir l'originalRépondre0
TideReceder
· 08-05 12:23
Un ancien employé trahit son entreprise.
Voir l'originalRépondre0
SandwichHunter
· 08-05 12:13
Les employés internes doivent être attrapés.
Voir l'originalRépondre0
MetaverseVagabond
· 08-05 12:11
C'est encore les opérations de permission qui causent des problèmes.
Le projet Pump a été attaqué par un Hacker interne, entraînant une perte de 2 millions de dollars.
Analyse de l'incident d'attaque du projet Pump par un Hacker
Récemment, le projet Pump a été victime d'un grave incident de sécurité, entraînant d'importantes pertes financières. Cet article analysera les détails de cet incident.
Processus d'attaque
Cette attaque n'a pas été réalisée par un hacker talentueux, mais probablement par un ancien employé du projet Pump. L'attaquant a maîtrisé le portefeuille de permissions utilisé par Pump pour créer des paires de trading sur Raydium, que nous appelons "compte attaqué". Pendant ce temps, tous les pools LP de Bonding Curve sur Pump qui n'ont pas encore atteint les normes de mise en ligne sur Raydium sont appelés "compte préparatoire".
L'attaquant a obtenu une grande quantité de fonds via un prêt éclair pour remplir tous les pools qui n'atteignaient pas les normes de Raydium. Normalement, lorsque le pool atteint les normes, les SOL dans le "compte préparatoire" devraient être transférés dans le "compte attaqué". Cependant, l'attaquant a siphonné les SOL transférés au cours de ce processus, empêchant ainsi les tokens qui auraient dû être listés sur Raydium et verrouillés dans le pool de le faire.
Analyse des victimes
Il est à noter que le fournisseur de prêts flash n'a pas subi de pertes, car le prêt a été remboursé dans le même bloc. De plus, les jetons déjà lancés sur Raydium ne devraient pas être affectés, car les LP sont déjà verrouillés.
Les véritables victimes sont les utilisateurs dans les piscines de Pump qui n'étaient pas encore remplies avant l'attaque. Les SOL achetés par ces utilisateurs ont été transférés par les attaquants, ce qui explique pourquoi le montant des pertes initialement estimé atteignait 80 millions de dollars. Cependant, selon les dernières nouvelles, la perte réelle est d'environ 2 millions de dollars.
Exploration des causes de l’attaque
Il est évident 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 antérieures de l'attaquant. Semblable aux robots qui ont massivement acheté des clés au début de FriendTech V1, il est très probable que cela ait été mis en place par les responsables pour guider l'enthousiasme initial.
On peut oser supposer que le projet Pump, pour réaliser un démarrage à froid, a peut-être laissé les hackers responsables de l'utilisation des fonds du projet pour remplir le pool des nouveaux tokens émis (comme $test, $alon, etc.), afin qu'ils puissent être lancés sur Raydium et créer de l'engouement. Cependant, ils n'avaient pas prévu que cela deviendrait finalement une porte d'entrée pour une menace interne.
Leçons tirées
Pour les projets de type imitation, il ne suffit pas de copier les fonctionnalités de surface. Développer un produit ne signifie pas nécessairement que des gens viendront échanger. Lors de l'exploitation de plateformes d'entraide, il est crucial de fournir un élan initial.
Plus important encore, l'équipe du projet doit accorder une grande importance à la gestion des droits et aux mesures de sécurité. Cet incident prouve une fois de plus que les menaces internes peuvent être plus dangereuses et plus difficiles à prévenir que les attaques externes.