Reflexão e lições sobre o ataque do hacker ao protocolo Cetus

Recentemente, um protocolo publicou um relatório de segurança sobre um ataque de Hacker, intitulado "revisão". O relatório é bastante transparente em relação aos detalhes técnicos e à resposta de emergência, sendo considerado de nível de livro didático. No entanto, ao responder à questão central "por que fomos hackeados", o relatório parece evitar o cerne da questão.

O relatório explica em detalhe o erro de verificação da função checked_shlw na biblioteca integer-mate (deveria ser ≤2^192, mas na prática é ≤2^256), e qualifica-o como "mal-entendido semântico". Embora essa descrição seja tecnicamente inatacável, ela habilmente desvia o foco para responsabilidades externas, como se o protocolo em si fosse também uma vítima inocente dessa falha técnica.

No entanto, vale a pena refletir: uma vez que o integer-mate é uma biblioteca matemática de código aberto amplamente utilizada, por que surgiu um erro tão absurdo neste protocolo, permitindo que apenas 1 token consiga obter uma enorme participação de liquidez?

Analisando o caminho de ataque do Hacker, pode-se descobrir que, para que um ataque seja bem-sucedido, quatro condições devem ser atendidas simultaneamente: verificação de estouro incorreta, operações de deslocamento extremo, regras de arredondamento para cima e falta de validação de viabilidade econômica. Surpreendentemente, o protocolo apresentou "negligência" em cada uma das condições de "disparo": aceitar entradas do usuário como 2^200, usar operações de deslocamento extremas e confiar totalmente no mecanismo de verificação de bibliotecas externas. O mais mortal é que, quando o sistema calculou um resultado claramente irracional como "1 token trocado por uma parte exorbitante", não houve nenhuma verificação de senso econômico antes de executar diretamente.

Portanto, as questões que o protocolo realmente precisa refletir incluem:

1. Por que não foram realizados testes de segurança adequados ao adotar bibliotecas externas genéricas? Embora a biblioteca integer-mate tenha características como ser de código aberto, popular e amplamente utilizada, ao gerenciar ativos de centenas de milhões de dólares, o protocolo claramente carece de uma compreensão aprofundada dos limites de segurança dessa biblioteca, bem como de planos de contingência em caso de falha das funcionalidades da biblioteca. Isso expõe a falta de conscientização do protocolo sobre a segurança da cadeia de suprimentos.

2. Por que permitir a entrada de números astronômicos sem estabelecer limites razoáveis? Embora os protocolos de finanças descentralizadas busquem a abertura, um sistema financeiro maduro, quanto mais aberto for, mais precisará de limites claros. Permitir a entrada de valores tão exagerados mostra que a equipe carece de talentos em gestão de riscos com intuição financeira.

3. Por que, após várias auditorias de segurança, ainda não foi possível identificar problemas antecipadamente? Isso reflete um erro de percepção fatal: a equipe do projeto terceiriza completamente a responsabilidade de segurança para a empresa de segurança, tratando a auditoria como um passe livre de responsabilidade. No entanto, os engenheiros de auditoria de segurança são principalmente especializados em descobrir vulnerabilidades no código e raramente consideram os problemas que podem surgir quando o sistema de testes calcula uma taxa de troca extremamente irracional.

Esta validação que atravessa as fronteiras da matemática, criptografia e economia é precisamente a maior lacuna na segurança das finanças descentralizadas modernas. As empresas de auditoria podem considerar que isto pertence a falhas no design do modelo econômico e não a problemas de lógica de código; os desenvolvedores do projeto podem reclamar que a auditoria não conseguiu identificar os problemas; e, no final, os ativos dos usuários são os que sofrem.

Este evento expôs as lacunas de segurança sistémica na indústria de finanças descentralizadas: equipas com formação puramente técnica frequentemente carecem de um "instinto de risco financeiro" básico.

De acordo com o relatório desse protocolo, a equipe parece não ter plena consciência disso. Em vez de se concentrar apenas nas falhas técnicas do ataque hacker, todas as equipes de finanças descentralizadas deveriam ultrapassar as limitações do pensamento puramente técnico e realmente cultivar a consciência de risco de segurança dos "engenheiros financeiros".

As medidas específicas podem incluir: a introdução de especialistas em gestão de riscos financeiros para preencher as lacunas de conhecimento da equipe técnica; a criação de um mecanismo de auditoria e revisão de múltiplas partes interessadas, que não apenas se concentre na auditoria de código, mas também dê importância à auditoria de modelos econômicos; o desenvolvimento de um "olfato financeiro", simulando vários cenários de ataque e as correspondentes medidas de resposta, mantendo uma alta vigilância sobre operações anormais, etc.

Isso nos lembra o consenso dos profissionais da indústria de segurança: à medida que a indústria se torna mais madura, as vulnerabilidades técnicas puras no nível do código tendem a diminuir, enquanto as "vulnerabilidades de consciência" na lógica de negócios, que são pouco claras e de responsabilidades nebulosas, se tornarão o maior desafio.

As empresas de auditoria podem garantir que o código não tenha falhas, mas como implementar "lógica com limites" requer que a equipe do projeto tenha uma compreensão mais profunda da essência do negócio e habilidades de controle de limites. Isso também explica a razão fundamental pela qual muitos projetos que passaram por auditorias de segurança ainda sofrem ataques de Hacker.

O futuro das finanças descentralizadas pertencerá, sem dúvida, às equipes que não apenas dominam a tecnologia de código, mas também compreendem profundamente a lógica de negócios!