No dia 2 de dezembro, de acordo com dados monitorados na cadeia, um determinado projeto sofreu um ataque de hacker, resultando na emissão ilegal de uma grande quantidade de tokens. O atacante trocou parte dos tokens emitidos ilegalmente por BNB em uma DEX, enquanto a parte restante foi mantida na carteira. Além disso, o hacker também utilizou um serviço de transferência anônima para movimentar os fundos. Este incidente resultou na exaustão do pool de liquidez do token, levando a uma queda acentuada no preço da moeda, e como o atacante utilizou os tokens emitidos ilegalmente para empréstimos colaterais, isso também causou perdas na plataforma de empréstimos.
Após analisar os dados de várias transações, foi descoberto que, embora o chamador tenha utilizado endereços diferentes, isso resultou em uma emissão adicional de tokens. Investigações adicionais mostraram que o projeto realizou uma atualização de contrato antes de sofrer o ataque, e a função de emissão no novo contrato lógico não passou pelas necessárias verificações de permissão.
O atacante chamou uma função específica no contrato lógico através de um contrato proxy. Devido à falta de verificação de permissões nessa função, resultou na emissão ilegal de tokens. Após o ataque, a equipe do projeto atualizou rapidamente o contrato lógico, adicionando um mecanismo de verificação de permissões à função de emissão.
Atualmente, os hackers já converteram parte dos tokens emitidos de forma excessiva em BNB e transferiram, mas ainda há uma grande quantidade de tokens ilegalmente emitidos a permanecer na sua carteira.
A causa fundamental deste ataque reside no fato de que, durante a atualização do contrato, a função de emissão no novo contrato lógico carecia das devidas verificações de permissão. Ainda não está claro se isso se deve ao uso de código de contrato não auditado e testado de forma segura, ou se foi causado por um vazamento de chave privada que permitiu que um hacker atualizasse o contrato por conta própria. De qualquer forma, este evento mais uma vez lembra os usuários e as partes do projeto da importância de proteger adequadamente as chaves privadas e frases de recuperação das carteiras, ao mesmo tempo que enfatiza a necessidade de testes de segurança abrangentes durante as atualizações de contrato.
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.
13 Curtidas
Recompensa
13
5
Compartilhar
Comentário
0/400
SchroedingerAirdrop
· 15h atrás
又薅了一波idiotas
Ver originalResponder0
GasFeeNightmare
· 15h atrás
Mais uma vez, os contratos inteligentes causaram problemas!
Ver originalResponder0
TokenToaster
· 15h atrás
É mais uma armadilha de verificação de permissões, gm
Ver originalResponder0
Token_Sherpa
· 15h atrás
caso clássico de elasticidade da oferta que correu mal... mais um esquema ponzinômico que foi por água abaixo, para ser sincero
Ver originalResponder0
CountdownToBroke
· 15h atrás
Outra vez, idiotas fizeram as pessoas de parvas e puxaram o tapete.
Uma vulnerabilidade no contrato de um projeto levou a uma grande emissão de Tokens. Hacker retira BNB, causando agitação no mercado.
No dia 2 de dezembro, de acordo com dados monitorados na cadeia, um determinado projeto sofreu um ataque de hacker, resultando na emissão ilegal de uma grande quantidade de tokens. O atacante trocou parte dos tokens emitidos ilegalmente por BNB em uma DEX, enquanto a parte restante foi mantida na carteira. Além disso, o hacker também utilizou um serviço de transferência anônima para movimentar os fundos. Este incidente resultou na exaustão do pool de liquidez do token, levando a uma queda acentuada no preço da moeda, e como o atacante utilizou os tokens emitidos ilegalmente para empréstimos colaterais, isso também causou perdas na plataforma de empréstimos.
Após analisar os dados de várias transações, foi descoberto que, embora o chamador tenha utilizado endereços diferentes, isso resultou em uma emissão adicional de tokens. Investigações adicionais mostraram que o projeto realizou uma atualização de contrato antes de sofrer o ataque, e a função de emissão no novo contrato lógico não passou pelas necessárias verificações de permissão.
O atacante chamou uma função específica no contrato lógico através de um contrato proxy. Devido à falta de verificação de permissões nessa função, resultou na emissão ilegal de tokens. Após o ataque, a equipe do projeto atualizou rapidamente o contrato lógico, adicionando um mecanismo de verificação de permissões à função de emissão.
Atualmente, os hackers já converteram parte dos tokens emitidos de forma excessiva em BNB e transferiram, mas ainda há uma grande quantidade de tokens ilegalmente emitidos a permanecer na sua carteira.
A causa fundamental deste ataque reside no fato de que, durante a atualização do contrato, a função de emissão no novo contrato lógico carecia das devidas verificações de permissão. Ainda não está claro se isso se deve ao uso de código de contrato não auditado e testado de forma segura, ou se foi causado por um vazamento de chave privada que permitiu que um hacker atualizasse o contrato por conta própria. De qualquer forma, este evento mais uma vez lembra os usuários e as partes do projeto da importância de proteger adequadamente as chaves privadas e frases de recuperação das carteiras, ao mesmo tempo que enfatiza a necessidade de testes de segurança abrangentes durante as atualizações de contrato.