O Cetus Protocol publicou um relatório detalhado sobre a análise do incidente de segurança após ter sido alvo de um ataque hacker recente. Embora o relatório se destaque nos detalhes técnicos e na resposta a emergências, ele parece evitar a explicação das causas fundamentais do ataque.
O relatório destacou a verificação de erros da função checked_shlw na biblioteca integer-mate, qualificando-a como "mal-entendido semântico". Embora essa descrição seja tecnicamente correta, parece tentar atribuir a responsabilidade a fatores externos, atenuando a negligência da própria Cetus.
No entanto, uma análise mais aprofundada revela que o sucesso do ataque Hacker requer simultaneamente a satisfação de quatro condições: verificação de overflow incorreta, operações de deslocamento de grande magnitude, regras de arredondamento para cima e falta de validação de razoabilidade econômica. A Cetus apresenta descuidos evidentes nesses pontos críticos, como aceitar números astronômicos como entrada do usuário, adotar operações de deslocamento de grande magnitude com alto risco, confiar excessivamente no mecanismo de verificação de bibliotecas externas e, quando o sistema calcula uma taxa de troca claramente irracional, carece da necessária verificação de bom senso econômico.
Este evento expôs as deficiências da equipe Cetus em vários aspectos:
Consciência de segurança da cadeia de suprimentos fraca: embora tenha sido utilizado uma biblioteca de código aberto e amplamente aplicada, não foi plenamente compreendido os limites de segurança dessa biblioteca ao gerenciar ativos massivos.
Falta de capacidade de gestão de risco financeiro: permitir a entrada de números astronômicos que excedem a necessidade real demonstra que a equipe carece de profissionais de gestão de risco com intuição financeira.
Dependência excessiva de auditorias de segurança: confiar totalmente na responsabilidade de segurança a empresas de auditoria, ignorando a responsabilidade de segurança da própria equipe do projeto.
Este caso revela uma fraqueza sistemática comum na indústria DeFi: as equipas técnicas muitas vezes carecem de uma consciência básica dos riscos financeiros. Para melhorar esta situação, os projetos DeFi deveriam:
Introduzir especialistas em gestão de riscos financeiros para preencher as lacunas de conhecimento da equipe técnica
Estabelecer um mecanismo de auditoria múltipla, incluindo auditoria de código e auditoria de modelo econômico
Desenvolver a sensibilidade financeira da equipe, simular vários cenários de ataque e elaborar medidas de resposta adequadas
Com o desenvolvimento da indústria, os bugs técnicos puros podem gradualmente diminuir, mas os "bugs de consciência" na lógica de negócios se tornarão um desafio maior. O sucesso ou fracasso dos futuros projetos DeFi dependerá de a equipe conseguir, ao mesmo tempo, manter uma forte capacidade técnica, compreender profundamente a lógica de negócios e controlar efetivamente os limites de risco.
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.
17 Curtidas
Recompensa
17
9
Compartilhar
Comentário
0/400
GameFiCritic
· 20h atrás
Desviar responsabilidades para terceiros? As consequências de empilhar código de forma cega.
Ver originalResponder0
GateUser-4745f9ce
· 07-28 04:27
Cortar e passar a responsabilidade tão bem
Ver originalResponder0
ConsensusBot
· 07-28 00:39
A gestão descuidada de antigas tradições artísticas.
Ver originalResponder0
GasFeeBeggar
· 07-26 18:17
Humm, um cheiro típico de atirar a culpa.
Ver originalResponder0
BridgeJumper
· 07-26 18:15
Mais uma vez a culpa foi colocada no库呗, quantas vezes já?
Ver originalResponder0
rekt_but_resilient
· 07-26 18:12
Desvia a culpa com tanta habilidade.
Ver originalResponder0
MrRightClick
· 07-26 18:05
Avaliação positiva da técnica de transferir responsabilidade
Ver originalResponder0
ZeroRushCaptain
· 07-26 18:00
Como previ, a explosão foi como uma lista de mortos.
Revisão do incidente do Hacker Cetus revela as lacunas de segurança dos projetos DeFi e direções para melhorias
O Cetus Protocol publicou um relatório detalhado sobre a análise do incidente de segurança após ter sido alvo de um ataque hacker recente. Embora o relatório se destaque nos detalhes técnicos e na resposta a emergências, ele parece evitar a explicação das causas fundamentais do ataque.
O relatório destacou a verificação de erros da função checked_shlw na biblioteca integer-mate, qualificando-a como "mal-entendido semântico". Embora essa descrição seja tecnicamente correta, parece tentar atribuir a responsabilidade a fatores externos, atenuando a negligência da própria Cetus.
No entanto, uma análise mais aprofundada revela que o sucesso do ataque Hacker requer simultaneamente a satisfação de quatro condições: verificação de overflow incorreta, operações de deslocamento de grande magnitude, regras de arredondamento para cima e falta de validação de razoabilidade econômica. A Cetus apresenta descuidos evidentes nesses pontos críticos, como aceitar números astronômicos como entrada do usuário, adotar operações de deslocamento de grande magnitude com alto risco, confiar excessivamente no mecanismo de verificação de bibliotecas externas e, quando o sistema calcula uma taxa de troca claramente irracional, carece da necessária verificação de bom senso econômico.
Este evento expôs as deficiências da equipe Cetus em vários aspectos:
Consciência de segurança da cadeia de suprimentos fraca: embora tenha sido utilizado uma biblioteca de código aberto e amplamente aplicada, não foi plenamente compreendido os limites de segurança dessa biblioteca ao gerenciar ativos massivos.
Falta de capacidade de gestão de risco financeiro: permitir a entrada de números astronômicos que excedem a necessidade real demonstra que a equipe carece de profissionais de gestão de risco com intuição financeira.
Dependência excessiva de auditorias de segurança: confiar totalmente na responsabilidade de segurança a empresas de auditoria, ignorando a responsabilidade de segurança da própria equipe do projeto.
Este caso revela uma fraqueza sistemática comum na indústria DeFi: as equipas técnicas muitas vezes carecem de uma consciência básica dos riscos financeiros. Para melhorar esta situação, os projetos DeFi deveriam:
Com o desenvolvimento da indústria, os bugs técnicos puros podem gradualmente diminuir, mas os "bugs de consciência" na lógica de negócios se tornarão um desafio maior. O sucesso ou fracasso dos futuros projetos DeFi dependerá de a equipe conseguir, ao mesmo tempo, manter uma forte capacidade técnica, compreender profundamente a lógica de negócios e controlar efetivamente os limites de risco.