Análise de incidente de segurança da plataforma Pump

Recentemente, ocorreu um grave incidente de segurança na plataforma Pump, resultando na perda de fundos de muitos usuários. Este artigo fará uma análise aprofundada dos antecedentes e desdobramentos deste evento.

Processo de Ataque

O atacante não é um hacker habilidoso, mas provavelmente um ex-funcionário da plataforma Pump. Ele possui a carteira de permissões usada pela Pump para criar pares de negociação de tokens em algum DEX, a qual chamamos de "conta de vítima". E todos os fundos LP de Bonding Curve da Pump que ainda não atingiram os padrões para serem listados em algum DEX, chamamos de "conta de preparação".

O atacante primeiro obteve um empréstimo relâmpago de uma certa plataforma de empréstimos, para preencher todos os pools de tokens que não atendiam aos padrões de listagem. Normalmente, quando o pool atinge os padrões de listagem, o SOL na "conta de preparação" deve ser transferido para a "conta da vítima". Mas o atacante retirou o SOL transferido nesse momento, fazendo com que os tokens que deveriam ter sido listados e bloqueados no pool não conseguissem ser listados a tempo.

Análise de Vítimas

De acordo com a análise, as vítimas foram principalmente usuários que já tinham comprado tokens que ainda não estavam completos no fundo na plataforma Pump antes do ataque ocorrer. Seus SOL foram transferidos pelos métodos de ataque mencionados. Isso também explica por que a perda inicial estimada poderia chegar a 80 milhões de dólares (os dados mais recentes mostram que a perda real é de cerca de 2 milhões de dólares).

Vale a pena notar que os tokens que já estão listados em alguma DEX, devido ao LP estar bloqueado, não devem ser afetados por este ataque.

Especulação sobre a identidade do atacante

O atacante possui a chave privada da "conta vítima", o que sem dúvida expõe uma grave negligência da plataforma na gestão de permissões. Podemos supor que encher o fundo de tokens pode ter sido uma das responsabilidades de trabalho do atacante anteriormente.

De forma análoga ao que fazem outras plataformas, o Pump pode ter atribuído a este funcionário a responsabilidade de usar os fundos do projeto para preencher a piscina de novos tokens emitidos (muito possivelmente tokens de teste que ele próprio emitiu), para que esses tokens pudessem ser listados na bolsa e gerar entusiasmo. Não se esperava que isso se tornasse, afinal, uma brecha de ameaça interna.

Lições Aprendidas

1. Para projetos semelhantes, não basta apenas imitar a superfície. Para atrair usuários para negociar, é necessário fornecer um impulso inicial.

2. A equipe do projeto deve dar grande importância à gestão de permissões e às medidas de segurança. É crucial distribuir permissões de forma adequada, realizar auditorias regulares e prevenir riscos internos.

3. Os usuários devem manter-se atentos ao participar de novas plataformas, especialmente em relação às negociações de tokens que não estão completamente preenchidos ou que ainda não foram listados em bolsas de negociação mainstream.

4. A equipa do projeto deve estabelecer um mecanismo de gestão de riscos abrangente, incluindo múltiplas assinaturas, níveis de permissão, entre outros, para reduzir o risco de falha única.

5. Realizar auditorias de segurança e testes de penetração regularmente, para detectar e corrigir potenciais vulnerabilidades de forma oportuna.

6. Reforçar a formação e a educação ética dos colaboradores, estabelecer uma cultura empresarial saudável e reduzir os riscos de ameaças internas.

Este evento lembra-nos novamente que, na indústria de criptomoedas em rápida evolução, a segurança é sempre a prioridade número um. Tanto os desenvolvedores de projetos quanto os usuários precisam estar sempre vigilantes e tomar as medidas de segurança necessárias.