o projeto aBNBc sofreu um ataque de Hacker, a emissão massiva de Token levou a um big dump de preço

Recentemente, uma instituição de monitoramento de dados descobriu que o projeto aBNBc foi alvo de um Hacker, resultando em uma massiva emissão adicional de Token. O Hacker explorou uma vulnerabilidade para emitir uma grande quantidade de Token aBNBc, dos quais uma parte já foi trocada por BNB em uma exchange descentralizada, enquanto a outra parte ainda permanece na carteira do Hacker. Além disso, o Hacker também utilizou ferramentas de transferência anônima para mover os fundos. Este incidente de ataque resultou na exaustão do pool de liquidez do Token aBNBc, fazendo com que o preço da moeda caísse drasticamente. Mais grave ainda, os atacantes também utilizaram os Tokens aBNBc emitidos para empréstimos colaterais, causando perdas à plataforma de empréstimos.

Através da análise de múltiplas transações, os investigadores descobriram que a função de emissão adicional foi chamada por endereços diferentes, mas todos resultaram na emissão adicional de Tokens. Investigações adicionais mostraram que o projeto tinha realizado uma atualização de contrato antes de sofrer o ataque, e a função de emissão adicional na nova lógica do contrato carecia da verificação de permissões necessária.

Após o ataque, a equipe do projeto atualizou novamente o contrato lógico, adicionando um mecanismo de verificação de permissões à função de emissão adicional na nova versão. No entanto, essa medida chegou tarde demais, não conseguindo reverter as perdas já causadas.

Sobre o fluxo de fundos, sabe-se que os hackers trocaram parte do aBNBc emitido por BNB e transferiram, enquanto uma grande quantidade do restante do aBNBc ainda permanece na carteira controlada pelos hackers.

A raiz do incidente de ataque reside na negligência durante a atualização do contrato. A função de emissão do contrato lógico carece de verificação de permissões, oferecendo uma oportunidade para o Hacker. Atualmente, não está claro se isso ocorreu devido ao uso de código de contrato não auditado e testado com segurança, ou se foi causado por uma violação da chave privada que permitiu ao Hacker atualizar o contrato por conta própria.

De qualquer forma, este evento lembra novamente aos usuários e às equipes de projetos que devem armazenar adequadamente as chaves privadas das carteiras e as frases de recuperação, e não devem armazená-las de maneira aleatória. Além disso, ao realizar a atualização de contratos, é necessário realizar testes de segurança abrangentes para prevenir vulnerabilidades e riscos potenciais.