Detalhes do incidente de roubo do Pump

Recentemente, a plataforma Pump enfrentou um grave incidente de roubo de fundos. Este artigo irá analisar detalhadamente a sequência de eventos e discutir as lições aprendidas.

Análise do processo de ataque

O autor deste incidente não é um hacker habilidoso, mas muito provavelmente um ex-funcionário do Pump. Esta pessoa tinha acesso a uma carteira de permissões usada para criar pares de negociação em uma determinada plataforma de negociação descentralizada, que chamamos de "conta roubada". Ao mesmo tempo, o pool de liquidez de tokens que ainda não atingiram os padrões de listagem no Pump é chamado de "conta de preparação".

O atacante primeiro obteve um empréstimo relâmpago através de uma 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, o SOL na conta de reserva é transferido para a conta roubada. No entanto, o atacante retirou o SOL transferido durante esse processo, fazendo com que esses tokens, que deveriam ser listados e ter a liquidez bloqueada, não fossem listados como esperado.

Análise de vítimas

De acordo com a análise, 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 listados na plataforma de negociação descentralizada, devido à liquidez já bloqueada, também não devem ser afetados.

Os verdadeiros prejudicados foram os usuários que compraram tokens em todos os pools não preenchidos na plataforma Pump antes do ataque. Seus SOL foram transferidos durante o ataque mencionado, o que também explica por que o valor das perdas inicialmente estimado era tão alto. No entanto, as últimas notícias indicam que a perda real foi de cerca de 2 milhões de dólares.

Possíveis razões para um atacante obter a chave privada

Sem dúvida, isso reflete uma grande negligência da equipe do projeto na gestão de permissões. Podemos supor que preencher o pool de tokens pode ter sido uma das responsabilidades anteriores do atacante. Semelhante a algumas plataformas sociais que usam bots oficiais nas fases iniciais para estimular a atividade de negociação, o Pump pode também ter deixado o atacante responsável por preencher o pool de liquidez dos novos tokens emitidos com fundos do projeto (muito possivelmente incluindo alguns tokens de teste), a fim de atrair atenção e realizar um lançamento a frio. Infelizmente, isso acabou se tornando uma brecha para ameaças internas.

Lições Aprendidas

1. Para os imitadores, simplesmente copiar as funcionalidades superficiais não é suficiente. É necessário perceber que desenvolver um produto por si só não atrai automaticamente os utilizadores. Em projetos colaborativos, fornecer um impulso inicial é crucial.

2. A equipe do projeto deve dar grande importância à gestão de permissões e às medidas de segurança. Este incidente destaca novamente a gravidade das ameaças internas, sublinhando a necessidade de estabelecer e melhorar mecanismos de atribuição de permissões e monitorização.

3. Os utilizadores devem manter-se alerta ao participar em plataformas emergentes, especialmente em relação a projetos que não foram devidamente verificados. Investir de forma diversificada, pesquisar cuidadosamente o histórico dos projetos e prestar atenção ao feedback da comunidade são métodos eficazes para reduzir riscos.

4. A regulamentação da indústria e os mecanismos de autorregulação precisam ser aprimorados. A ocorrência de eventos semelhantes destaca a necessidade de fortalecer a autorregulação da indústria e estabelecer mecanismos de auditoria mais rigorosos.

Este incidente soou o alarme para todo o ecossistema de criptomoedas, lembrando-nos de que, na busca pela inovação, não podemos negligenciar os princípios básicos de segurança e gestão de riscos. Apenas encontrando um equilíbrio entre segurança e inovação é que podemos impulsionar o desenvolvimento saudável da indústria.