O Cetus Protocol lançou recentemente um relatório de análise de segurança sobre o incidente de ataque de Hacker. Este relatório é bastante transparente em termos de detalhes técnicos e resposta a emergências, sendo considerado de nível de livro didático. No entanto, ao explicar "por que foi hackeado", a atitude do relatório parece evitar a questão central.
O relatório destacou a explicação do erro de verificação da função checked_shlw na biblioteca integer-mate, qualificando-o como "mal-entendido semântico". Embora essa descrição seja tecnicamente correta, parece desviar o foco para uma responsabilidade externa, como se a Cetus também fosse uma vítima desse defeito técnico.
No entanto, vale a pena pensar: uma vez que o integer-mate é uma biblioteca matemática de código aberto amplamente utilizada, por que surgiu uma vulnerabilidade tão grave aqui no Cetus? Ao analisar o caminho do ataque, pode-se concluir que, para que o Hacker realize um ataque perfeito, é necessário satisfazer simultaneamente quatro condições: verificação de estouro incorreta, operações de deslocamento significativo, regra de arredondamento para cima e falta de verificação de viabilidade econômica.
Surpreendentemente, o Cetus cometeu negligências em cada uma das condições de "gatilho". Por exemplo, o sistema aceitou números astronômicos inseridos pelo usuário, adotou cálculos de deslocamento extremamente perigosos e confiou completamente no mecanismo de verificação de bibliotecas externas. O mais fatal é que, quando o sistema calculou um resultado absurdo como "1 token por uma quota exorbitante", não houve qualquer verificação de senso econômico antes de executar diretamente.
Assim, as verdadeiras questões que a Cetus deve refletir incluem:
Por que usar bibliotecas externas genéricas sem realizar testes de segurança adequados? Embora a biblioteca integer-mate possua características como ser open source, popular e amplamente utilizada, a Cetus, ao usá-la para gerenciar ativos tão grandes, parece não ter compreendido completamente os limites de segurança dessa biblioteca, nem considerou alternativas para o caso de falha da biblioteca. Isso reflete a falta de consciência da Cetus em relação à segurança da cadeia de suprimentos.
Por que permitir a entrada de números astronômicos sem estabelecer limites? Embora os protocolos DeFi busquem a descentralização, sistemas financeiros maduros também precisam de limites claros enquanto estão abertos. Permitir a entrada de números tão exagerados indica que a equipe pode carecer de profissionais de gestão de riscos com intuição financeira.
Por que, após várias auditorias de segurança, ainda não foram detectados problemas antecipadamente? Isso expõe um erro de percepção fatal: a equipe do projeto delega completamente a responsabilidade pela segurança a empresas de segurança, considerando a auditoria como um passe livre. No entanto, os engenheiros de auditoria de segurança são especialistas em detectar bugs no código, mas podem não pensar em testar o desempenho do sistema em situações extremas.
Esta verificação que atravessa as fronteiras da matemática, criptografia e economia é precisamente a maior lacuna na segurança moderna do DeFi. As empresas de auditoria podem considerar isso uma falha no design do modelo econômico e não um problema de lógica de código, enquanto os desenvolvedores do projeto podem reclamar que a auditoria não detectou problemas, e os usuários acabam por arcar com as perdas.
Este evento expôs a fragilidade sistêmica de segurança na indústria DeFi: equipes com formação puramente técnica muitas vezes carecem de um "apreço pelo risco financeiro" básico. De acordo com o relatório da Cetus, a equipe parece não ter reconhecido isso plenamente.
Para a Cetus e para toda a indústria DeFi, é importante sair das limitações do pensamento puramente técnico e cultivar uma verdadeira consciência de risco de segurança entre os "engenheiros financeiros". Pode-se considerar a introdução de especialistas em gestão de riscos financeiros para preencher as lacunas de conhecimento da equipe técnica; estabelecer um mecanismo de auditoria e revisão multi-partes, que não apenas se concentre na auditoria de código, mas também valorize a auditoria de modelos econômicos; cultivar um "instinto financeiro", simular vários cenários de ataque e desenvolver medidas de resposta adequadas, mantendo uma vigilância elevada sobre operações anormais.
Com o desenvolvimento da indústria, os bugs técnicos a nível de código podem gradualmente diminuir, mas a lógica de negócios com "bugs de consciência" que têm fronteiras pouco claras e responsabilidades confusas se tornará o maior desafio. As empresas de auditoria podem garantir que o código não tenha bugs, mas como conseguir "lógica com fronteiras" requer que a equipe do projeto tenha uma compreensão mais profunda da essência do negócio e capacidade de controle de fronteiras.
O futuro do DeFi pertence àqueles que possuem não apenas habilidades técnicas de codificação sólidas, mas também uma compreensão profunda da lógica de negócios. Apenas equipes que possuem essas duas capacidades poderão realmente se estabelecer e ter sucesso neste setor desafiador.
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.
20 Curtidas
Recompensa
20
6
Compartilhar
Comentário
0/400
GasWhisperer
· 07-17 18:44
os padrões do pool de mem nunca mentem... integer-mate era apenas o Gate, não a vulnerabilidade central para ser honesto
Ver originalResponder0
DataOnlooker
· 07-17 15:56
O mestre em passar a responsabilidade, este Cetus.
Ver originalResponder0
ImpermanentLossEnjoyer
· 07-15 05:30
As perdas ainda podem ser analisadas, 香嗷
Ver originalResponder0
DegenApeSurfer
· 07-15 05:30
Quem está vivo, que assuma a culpa.
Ver originalResponder0
SatoshiLegend
· 07-15 05:30
Por que os projetos DeFi apresentam frequentemente esse tipo de erro de estouro de inteiro? Antes de investigar a fundo, é necessário compreender o algoritmo pow.
Ver originalResponder0
GasOptimizer
· 07-15 05:28
Desculpas bem fundadas, de fato foi um erro de não verificar.
Reflexão sobre o incidente do hacker Cetus: a segurança das Finanças Descentralizadas precisa sair do pensamento puramente técnico
O Cetus Protocol lançou recentemente um relatório de análise de segurança sobre o incidente de ataque de Hacker. Este relatório é bastante transparente em termos de detalhes técnicos e resposta a emergências, sendo considerado de nível de livro didático. No entanto, ao explicar "por que foi hackeado", a atitude do relatório parece evitar a questão central.
O relatório destacou a explicação do erro de verificação da função checked_shlw na biblioteca integer-mate, qualificando-o como "mal-entendido semântico". Embora essa descrição seja tecnicamente correta, parece desviar o foco para uma responsabilidade externa, como se a Cetus também fosse uma vítima desse defeito técnico.
No entanto, vale a pena pensar: uma vez que o integer-mate é uma biblioteca matemática de código aberto amplamente utilizada, por que surgiu uma vulnerabilidade tão grave aqui no Cetus? Ao analisar o caminho do ataque, pode-se concluir que, para que o Hacker realize um ataque perfeito, é necessário satisfazer simultaneamente quatro condições: verificação de estouro incorreta, operações de deslocamento significativo, regra de arredondamento para cima e falta de verificação de viabilidade econômica.
Surpreendentemente, o Cetus cometeu negligências em cada uma das condições de "gatilho". Por exemplo, o sistema aceitou números astronômicos inseridos pelo usuário, adotou cálculos de deslocamento extremamente perigosos e confiou completamente no mecanismo de verificação de bibliotecas externas. O mais fatal é que, quando o sistema calculou um resultado absurdo como "1 token por uma quota exorbitante", não houve qualquer verificação de senso econômico antes de executar diretamente.
Assim, as verdadeiras questões que a Cetus deve refletir incluem:
Por que usar bibliotecas externas genéricas sem realizar testes de segurança adequados? Embora a biblioteca integer-mate possua características como ser open source, popular e amplamente utilizada, a Cetus, ao usá-la para gerenciar ativos tão grandes, parece não ter compreendido completamente os limites de segurança dessa biblioteca, nem considerou alternativas para o caso de falha da biblioteca. Isso reflete a falta de consciência da Cetus em relação à segurança da cadeia de suprimentos.
Por que permitir a entrada de números astronômicos sem estabelecer limites? Embora os protocolos DeFi busquem a descentralização, sistemas financeiros maduros também precisam de limites claros enquanto estão abertos. Permitir a entrada de números tão exagerados indica que a equipe pode carecer de profissionais de gestão de riscos com intuição financeira.
Por que, após várias auditorias de segurança, ainda não foram detectados problemas antecipadamente? Isso expõe um erro de percepção fatal: a equipe do projeto delega completamente a responsabilidade pela segurança a empresas de segurança, considerando a auditoria como um passe livre. No entanto, os engenheiros de auditoria de segurança são especialistas em detectar bugs no código, mas podem não pensar em testar o desempenho do sistema em situações extremas.
Esta verificação que atravessa as fronteiras da matemática, criptografia e economia é precisamente a maior lacuna na segurança moderna do DeFi. As empresas de auditoria podem considerar isso uma falha no design do modelo econômico e não um problema de lógica de código, enquanto os desenvolvedores do projeto podem reclamar que a auditoria não detectou problemas, e os usuários acabam por arcar com as perdas.
Este evento expôs a fragilidade sistêmica de segurança na indústria DeFi: equipes com formação puramente técnica muitas vezes carecem de um "apreço pelo risco financeiro" básico. De acordo com o relatório da Cetus, a equipe parece não ter reconhecido isso plenamente.
Para a Cetus e para toda a indústria DeFi, é importante sair das limitações do pensamento puramente técnico e cultivar uma verdadeira consciência de risco de segurança entre os "engenheiros financeiros". Pode-se considerar a introdução de especialistas em gestão de riscos financeiros para preencher as lacunas de conhecimento da equipe técnica; estabelecer um mecanismo de auditoria e revisão multi-partes, que não apenas se concentre na auditoria de código, mas também valorize a auditoria de modelos econômicos; cultivar um "instinto financeiro", simular vários cenários de ataque e desenvolver medidas de resposta adequadas, mantendo uma vigilância elevada sobre operações anormais.
Com o desenvolvimento da indústria, os bugs técnicos a nível de código podem gradualmente diminuir, mas a lógica de negócios com "bugs de consciência" que têm fronteiras pouco claras e responsabilidades confusas se tornará o maior desafio. As empresas de auditoria podem garantir que o código não tenha bugs, mas como conseguir "lógica com fronteiras" requer que a equipe do projeto tenha uma compreensão mais profunda da essência do negócio e capacidade de controle de fronteiras.
O futuro do DeFi pertence àqueles que possuem não apenas habilidades técnicas de codificação sólidas, mas também uma compreensão profunda da lógica de negócios. Apenas equipes que possuem essas duas capacidades poderão realmente se estabelecer e ter sucesso neste setor desafiador.