【比推】O projeto GANA teve recentemente um grande incidente de segurança - o atacante apenas fez stake de algumas centenas de USDT, mas ao descongelar conseguiu retirar dezenas de milhares de USDT.
Um especialista em segurança descobriu que a raiz do problema estava na fuga da chave privada do proprietário do contrato GANA Payment Stake. Mas o atacante não transferiu os fundos de maneira simples e brusca; em vez disso, usou algumas técnicas: primeiro, contornou a verificação onlyEOA na função unstake usando a operação 7702 deleGate (essa verificação era originalmente para prevenir bots), e depois alterou discretamente os parâmetros Rate e Fee dentro do contrato.
Com esta combinação de movimentos, a proporção de troca entre stake e desestacar foi completamente distorcida. Essencialmente, isso foi feito ao alterar os parâmetros centrais do contrato inteligente, mudando as regras de saque para uma versão favorável ao atacante.
Este caso prova mais uma vez: a gestão de chaves privadas não pode ter qualquer negligência, e o design de permissões de contratos também precisa de múltiplas camadas de proteção.
Ver original
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.
10 Curtidas
Recompensa
10
3
Repostar
Compartilhar
Comentário
0/400
FlashLoanKing
· 23h atrás
Centenas de U tornaram-se dezenas de milhares, esta operação é realmente incrível, uma vez que a Chave privada vaze, tudo estará acabado.
Ver originalResponder0
SoliditySlayer
· 23h atrás
A divulgação da chave privada juntamente com a modificação de parâmetros, essa técnica é realmente algo... GANA realmente está em uma situação complicada desta vez
---
Trocar centenas por dezenas de milhares? Este negócio é extremamente vantajoso, não é de se admirar que algumas pessoas arrisquem tudo
---
Outra vez a chave privada do Owner, quando é que a equipa do projeto vai aprender a lição
---
Preciso olhar mais de perto a estratégia do 7702, sinto que essa lógica de ataque é um pouco severa
---
E a auditoria do contrato? Como é que um erro tão grande passou
---
Com stake é possível obter lucros dez vezes maiores, GANA está realmente ajudando os hackers
---
Crime técnico, o que mostra que o hacker realmente tem habilidades, não é apenas um script kiddie
---
Mais um projeto roubado, realmente precisamos aprender a nos proteger neste círculo
---
De centenas a dezenas de milhares, essa absuridade é comparável a fraudes no mundo real
Ver originalResponder0
NFTArchaeologist
· 23h atrás
Chave privada uma vez revelada está tudo acabado, esse tipo de erro básico é realmente impressionante
Trocar centenas por dezenas de milhares, quão ocioso deve ser
7702 essa armadilha, parece que preciso de mais aulas
Mais uma vez o problema da chave privada do Owner, quando é que a equipa do projeto vai aprender a lição
Esses detalhes de operação precisam ser bem estudados, há algo aí
GANA roubado: Chave privada vazada + alteração de parâmetros, todo o processo de ataque de centenas de U trocadas por dezenas de milhares de U.
【比推】O projeto GANA teve recentemente um grande incidente de segurança - o atacante apenas fez stake de algumas centenas de USDT, mas ao descongelar conseguiu retirar dezenas de milhares de USDT.
Um especialista em segurança descobriu que a raiz do problema estava na fuga da chave privada do proprietário do contrato GANA Payment Stake. Mas o atacante não transferiu os fundos de maneira simples e brusca; em vez disso, usou algumas técnicas: primeiro, contornou a verificação onlyEOA na função unstake usando a operação 7702 deleGate (essa verificação era originalmente para prevenir bots), e depois alterou discretamente os parâmetros Rate e Fee dentro do contrato.
Com esta combinação de movimentos, a proporção de troca entre stake e desestacar foi completamente distorcida. Essencialmente, isso foi feito ao alterar os parâmetros centrais do contrato inteligente, mudando as regras de saque para uma versão favorável ao atacante.
Este caso prova mais uma vez: a gestão de chaves privadas não pode ter qualquer negligência, e o design de permissões de contratos também precisa de múltiplas camadas de proteção.