Análise do incidente de ataque interno ao projeto Pump

Recentemente, o projeto Pump sofreu um ataque interno, resultando em perdas significativas. Este artigo irá analisar detalhadamente este evento.

Processo de Ataque

O atacante não é um hacker externo, mas provavelmente um ex-funcionário do projeto Pump. Ele tem o controle da carteira de permissões usada pelo Pump para criar pares de negociação de tokens na Raydium, que chamamos de "conta alvo". Ao mesmo tempo, os tokens criados no Pump, mas que ainda não atingiram os padrões de listagem da Raydium, são chamados de "conta de preparação".

O atacante obteve um empréstimo relâmpago através de uma plataforma de empréstimo, utilizando esses fundos para preencher todos os pools que não atingiam o padrão do Raydium. Normalmente, quando o pool atinge o padrão, o SOL na "conta de preparação" deve ser transferido para a "conta alvo". No entanto, o atacante retirou o SOL transferido durante esse processo, fazendo com que os tokens que deveriam ser listados no Raydium e bloquear o pool não conseguissem completar a operação de listagem.

Análise de Vítimas

Este ataque não afetou os fundos da plataforma de empréstimos, pois o empréstimo relâmpago foi devolvido na mesma bloco. Os tokens que já estão disponíveis na Raydium, devido ao LP já estar bloqueado, também não devem ser afetados.

Os verdadeiros prejuízos foram sofridos pelos usuários do Pump que ainda não tinham preenchido a piscina antes do ataque. O SOL que compraram foi transferido na sequência do ataque mencionado. Isso também explica por que a perda inicial estimada poderia chegar a 80 milhões de dólares ( Nota: os dados mais recentes mostram que 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 de trabalho anteriores do atacante. Semelhante à prática de algumas plataformas sociais na fase inicial de usar robôs oficiais para simular a atividade de negociação.

É muito provável que o projeto Pump, para realizar um arranque a frio, tenha deixado os atacantes responsáveis por usar os fundos do projeto para preencher o fundo dos novos tokens emitidos ( como $test, $alon, etc. ), permitindo que estes fossem lançados na Raydium e aumentassem o preço para atrair atenção. Mas eles não previram que isso acabaria por se tornar uma brecha para um ataque interno.

Resumo das lições

1. Para projetos semelhantes, apenas imitar a superfície não é suficiente. É preciso considerar como fornecer o impulso inicial, em vez de simplesmente achar que, tendo um produto, as transações ocorrerão naturalmente.

2. O projeto deve dar grande importância à gestão de permissões e medidas de segurança. As ameaças internas costumam ser mais perigosas do que os ataques externos, pois os funcionários internos detêm informações e permissões críticas.

3. Ao projetar sistemas, deve-se seguir o princípio do menor privilégio, garantindo que cada papel possa acessar apenas os recursos necessários para realizar seu trabalho.

4. Realizar auditorias de segurança e verificações de permissões regularmente, identificando e corrigindo rapidamente potenciais vulnerabilidades de segurança.

5. Estabelecer um processo de saída de funcionários eficaz, garantindo que todas as permissões e informações sensíveis sejam recuperadas em tempo útil quando um funcionário deixar a empresa.

Este evento nos lembra mais uma vez que, no campo das criptomoedas em rápida evolução, a segurança deve ser sempre a prioridade número um. As equipes dos projetos devem manter-se constantemente alerta e aprimorar as medidas de segurança para proteger os interesses dos usuários e do próprio projeto.