Análise do incidente de ataque de Hacker ao projeto Pump
Recentemente, o projeto Pump sofreu um grave incidente de segurança, resultando em grandes perdas financeiras. Este artigo irá analisar os detalhes deste evento.
Processo de ataque
Este ataque não foi realizado por hackers habilidosos, mas provavelmente por um ex-funcionário do projeto Pump. O atacante teve acesso à carteira de permissões utilizada pelo Pump para criar pares de negociação na Raydium, que chamamos de "conta atacada". Ao mesmo tempo, todos os fundos de LP de Bonding Curve que ainda não atingiram os padrões para serem listados na Raydium são chamados de "conta preparada".
Os atacantes obtiveram uma grande quantidade de fundos através de um empréstimo relâmpago, para encher todas as piscinas que não atingiram o padrão Raydium. Normalmente, quando a piscina atinge o padrão, o SOL na "conta de preparação" deve ser transferido para a "conta atacada". No entanto, os atacantes retiraram o SOL transferido durante esse processo, fazendo com que os tokens que deveriam ter sido listados na Raydium e bloqueados nas piscinas não conseguissem ser listados.
Análise de Vítimas
É importante notar que o fornecedor do empréstimo relâmpago não sofreu perdas, pois o empréstimo foi devolvido dentro do mesmo bloco. Além disso, os tokens que já estão disponíveis na Raydium, devido ao LP estar bloqueado, também não devem ser afetados.
Os verdadeiros prejudicados são os usuários em todos os Pump pools que ainda não estavam cheios antes do ataque. Os SOL comprados por esses usuários foram transferidos pelos atacantes, o que também explica por que o valor das perdas inicialmente estimado chegou a 80 milhões de dólares. No entanto, de acordo com as últimas notícias, a perda real é de cerca de 2 milhões de dólares.
Investigação das razões do ataque
É evidente que este incidente expôs uma grande negligência da equipe do projeto na gestão de permissões. Podemos especular que encher a piscina pode ter sido uma das responsabilidades anteriores do atacante. Semelhante aos bots que compraram em massa chaves no início do FriendTech V1, é muito provável que tenham sido configurados oficialmente para direcionar o entusiasmo inicial.
Pode-se especular ousadamente que o projeto Pump, para realizar o arranque a frio, pode ter deixado que os atacantes fossem responsáveis por usar os fundos do projeto para preencher a piscina de novos tokens emitidos (como $test, $alon, etc.), para que eles possam ser lançados na Raydium e gerar entusiasmo. No entanto, eles não previram que isso acabaria por se tornar um ponto de entrada para ameaças internas.
Lições aprendidas
Para projetos de imitação, copiar apenas as funcionalidades superficiais não é suficiente. Apenas desenvolver um produto não significa que as pessoas virão negociar. Ao operar plataformas de ajuda mútua, é crucial fornecer um impulso inicial.
Mais importante ainda, a equipe do projeto deve dar grande atenção à gestão de permissões e às medidas de segurança. Este incidente mais uma vez prova que ameaças internas podem ser mais perigosas e difíceis de prevenir do que ataques externos.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
23 Curtidas
Recompensa
23
7
Repostar
Compartilhar
Comentário
0/400
FundingMartyr
· 08-07 20:28
Os traidores causam os maiores danos.
Ver originalResponder0
TokenTherapist
· 08-05 18:16
Os traidores serão punidos pelo céu.
Ver originalResponder0
WhaleMinion
· 08-05 12:38
Os traidores agem de forma mais cruel.
Ver originalResponder0
HodlNerd
· 08-05 12:34
Ameaças internas dominam estatisticamente os exploits.
Ver originalResponder0
TideReceder
· 08-05 12:23
Ex-funcionário que trai a empresa
Ver originalResponder0
SandwichHunter
· 08-05 12:13
Os funcionários internos devem ser apanhados.
Ver originalResponder0
MetaverseVagabond
· 08-05 12:11
Foi mais uma vez um problema causado por operações de permissão.
O projeto Pump foi alvo de um ataque interno de Hacker, resultando numa perda de 2 milhões de dólares.
Análise do incidente de ataque de Hacker ao projeto Pump
Recentemente, o projeto Pump sofreu um grave incidente de segurança, resultando em grandes perdas financeiras. Este artigo irá analisar os detalhes deste evento.
Processo de ataque
Este ataque não foi realizado por hackers habilidosos, mas provavelmente por um ex-funcionário do projeto Pump. O atacante teve acesso à carteira de permissões utilizada pelo Pump para criar pares de negociação na Raydium, que chamamos de "conta atacada". Ao mesmo tempo, todos os fundos de LP de Bonding Curve que ainda não atingiram os padrões para serem listados na Raydium são chamados de "conta preparada".
Os atacantes obtiveram uma grande quantidade de fundos através de um empréstimo relâmpago, para encher todas as piscinas que não atingiram o padrão Raydium. Normalmente, quando a piscina atinge o padrão, o SOL na "conta de preparação" deve ser transferido para a "conta atacada". No entanto, os atacantes retiraram o SOL transferido durante esse processo, fazendo com que os tokens que deveriam ter sido listados na Raydium e bloqueados nas piscinas não conseguissem ser listados.
Análise de Vítimas
É importante notar que o fornecedor do empréstimo relâmpago não sofreu perdas, pois o empréstimo foi devolvido dentro do mesmo bloco. Além disso, os tokens que já estão disponíveis na Raydium, devido ao LP estar bloqueado, também não devem ser afetados.
Os verdadeiros prejudicados são os usuários em todos os Pump pools que ainda não estavam cheios antes do ataque. Os SOL comprados por esses usuários foram transferidos pelos atacantes, o que também explica por que o valor das perdas inicialmente estimado chegou a 80 milhões de dólares. No entanto, de acordo com as últimas notícias, a perda real é de cerca de 2 milhões de dólares.
Investigação das razões do ataque
É evidente que este incidente expôs uma grande negligência da equipe do projeto na gestão de permissões. Podemos especular que encher a piscina pode ter sido uma das responsabilidades anteriores do atacante. Semelhante aos bots que compraram em massa chaves no início do FriendTech V1, é muito provável que tenham sido configurados oficialmente para direcionar o entusiasmo inicial.
Pode-se especular ousadamente que o projeto Pump, para realizar o arranque a frio, pode ter deixado que os atacantes fossem responsáveis por usar os fundos do projeto para preencher a piscina de novos tokens emitidos (como $test, $alon, etc.), para que eles possam ser lançados na Raydium e gerar entusiasmo. No entanto, eles não previram que isso acabaria por se tornar um ponto de entrada para ameaças internas.
Lições aprendidas
Para projetos de imitação, copiar apenas as funcionalidades superficiais não é suficiente. Apenas desenvolver um produto não significa que as pessoas virão negociar. Ao operar plataformas de ajuda mútua, é crucial fornecer um impulso inicial.
Mais importante ainda, a equipe do projeto deve dar grande atenção à gestão de permissões e às medidas de segurança. Este incidente mais uma vez prova que ameaças internas podem ser mais perigosas e difíceis de prevenir do que ataques externos.