Depois de ler o relatório de "revisão" sobre a segurança de ataques cibernéticos da @CetusProtocol, você perceberá um fenômeno "instigante": os detalhes técnicos são revelados de forma bastante transparente, a resposta de emergência é digna de um manual, mas na questão mais crucial do "por que fomos hackeados", parece evitar o cerne da questão:
O relatório dedica muito espaço para explicar o erro de verificação da função 'checked_shlw' da biblioteca 'inteiro-mate' (que deveria ≤ 2^192, mas na verdade ≤2^256) e caracteriza isso como um "mal-entendido semântico". Esta narrativa, embora tecnicamente válida, direciona habilmente o foco para a responsabilidade externa, como se Cetus fosse também uma vítima inocente dessa falha tecnológica.
A questão é: já que integer-mate é uma biblioteca matemática de código aberto e amplamente utilizada, como é que ocorreu um erro absurdo em que se pode obter uma quota de liquidez altíssima com apenas 1 token?
Analisar o caminho de ataque de hackers revela que, para realizar um ataque perfeito, os hackers devem satisfazer simultaneamente quatro condições: verificação de estouro de erro incorreta, operações de deslocamento significativas, regras de arredondamento para cima e falta de verificação de viabilidade econômica.
Cetus foi descuidado em cada uma das condições de "gatilho", como: aceitar a entrada do usuário de números astronômicos como 2^200, realizar operações de deslocamento em larga escala extremamente perigosas, confiar completamente nos mecanismos de verificação de bibliotecas externas, e o mais fatal - quando o sistema calculou um resultado absurdo de "1 token por uma parte valiosa", não houve nenhuma verificação de bom senso econômico antes da execução.
Portanto, os pontos que a Cetus realmente deve refletir são os seguintes:
Por que não faço testes de segurança quando uso bibliotecas externas comuns? Embora a biblioteca "inteiro-mate" seja de código aberto, popular e amplamente utilizada, o Cetus a usa para gerenciar centenas de milhões de dólares em ativos sem entender completamente onde estão os limites de segurança da biblioteca, se há alternativas adequadas se a biblioteca falhar, e assim por diante. Obviamente, a Cetus carece da mais básica consciência de segurança da cadeia de suprimentos;
Por que é permitido inserir números astronômicos sem estabelecer limites? Embora os protocolos DeFi devam buscar a descentralização, um sistema financeiro maduro, quanto mais aberto, mais precisa de limites claros.
Quando o sistema permite a entrada de números astronômicos meticulosamente elaborados por atacantes, a equipe claramente não pensou se essa demanda de liquidez é razoável. Mesmo o maior hedge fund do mundo não pode precisar de uma cota de liquidez tão exagerada. É evidente que a equipe da Cetus carece 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 identificados problemas? Esta frase revela inadvertidamente um erro de percepção fatal: a equipe do projeto terceiriza a responsabilidade pela segurança para a empresa de segurança, tratando a auditoria como um certificado de isenção de responsabilidade. Mas a realidade é cruel: os engenheiros de auditoria de segurança são bons em identificar bugs de código, quem poderia imaginar que ao testar o sistema para calcular uma proporção de troca absurda poderia haver algo errado?
A validação que atravessa as fronteiras da matemática, criptografia e economia é, de fato, a maior lacuna de segurança no DeFi moderno. As empresas de auditoria dirão que "é uma falha no design do modelo econômico, não um problema de lógica de código"; os desenvolvedores do projeto se queixam de que "a auditoria não encontrou problemas"; e os usuários só sabem que o seu dinheiro desapareceu!
Você vê, isso expõe, em última análise, a deficiência sistêmica de segurança na indústria DeFi: equipes com formação puramente técnica carecem seriamente de um básico "instinto para riscos financeiros".
E a partir deste relatório da Cetus, a equipe claramente não refletiu adequadamente.
Em vez de apenas focar nas deficiências técnicas relacionadas a este ataque hacker, eu acho que, a partir da Cetus, todas as equipes DeFi deveriam abandonar a limitação do pensamento puramente técnico e realmente cultivar a consciência de risco de segurança dos "engenheiros financeiros".
Por exemplo, introduzir especialistas em controle de risco financeiro para compensar os pontos cegos de conhecimento da equipe técnica; Realizar um mecanismo de revisão de auditoria multipartidária, não só para analisar a auditoria do código, mas também para compor a necessária auditoria do modelo económico; Cultive o "senso financeiro", simule vários cenários de ataque e contramedidas correspondentes e seja sensível a operações anormais em todos os momentos.
Isso me lembra da experiência anterior em empresas de segurança, incluindo a troca de ideias entre os grandes nomes da segurança da indústria @evilcos, @chiachih_wu, @yajinzhou, @mikelee205, que também tinham esse consenso:
Com o amadurecimento da indústria, os problemas de bugs técnicos a nível de código tendem a diminuir, enquanto a "consciência de bugs" na lógica de negócios, que é nebulosa e com responsabilidades pouco claras, representa o maior desafio.
As empresas de auditoria só podem garantir que o código não tem Bugs, mas como é que se pode garantir que a "lógica tem limites" requer que a equipe do projeto tenha uma compreensão mais profunda da essência do negócio e a capacidade de controlar esses limites. (A principal razão para muitos "incidentes de culpa" que ainda sofreram ataques de hackers após auditorias de segurança é exatamente esta.)
O futuro do DeFi pertence às equipas que dominam a tecnologia de código e compreendem profundamente a lógica de negócios!
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Cetus questões de segurança: O que a equipe DeFi deve estar atenta?
Autor: Haotian
Depois de ler o relatório de "revisão" sobre a segurança de ataques cibernéticos da @CetusProtocol, você perceberá um fenômeno "instigante": os detalhes técnicos são revelados de forma bastante transparente, a resposta de emergência é digna de um manual, mas na questão mais crucial do "por que fomos hackeados", parece evitar o cerne da questão:
O relatório dedica muito espaço para explicar o erro de verificação da função 'checked_shlw' da biblioteca 'inteiro-mate' (que deveria ≤ 2^192, mas na verdade ≤2^256) e caracteriza isso como um "mal-entendido semântico". Esta narrativa, embora tecnicamente válida, direciona habilmente o foco para a responsabilidade externa, como se Cetus fosse também uma vítima inocente dessa falha tecnológica.
A questão é: já que
integer-mateé uma biblioteca matemática de código aberto e amplamente utilizada, como é que ocorreu um erro absurdo em que se pode obter uma quota de liquidez altíssima com apenas 1 token?Analisar o caminho de ataque de hackers revela que, para realizar um ataque perfeito, os hackers devem satisfazer simultaneamente quatro condições: verificação de estouro de erro incorreta, operações de deslocamento significativas, regras de arredondamento para cima e falta de verificação de viabilidade econômica.
Cetus foi descuidado em cada uma das condições de "gatilho", como: aceitar a entrada do usuário de números astronômicos como 2^200, realizar operações de deslocamento em larga escala extremamente perigosas, confiar completamente nos mecanismos de verificação de bibliotecas externas, e o mais fatal - quando o sistema calculou um resultado absurdo de "1 token por uma parte valiosa", não houve nenhuma verificação de bom senso econômico antes da execução.
Portanto, os pontos que a Cetus realmente deve refletir são os seguintes:
Por que não faço testes de segurança quando uso bibliotecas externas comuns? Embora a biblioteca "inteiro-mate" seja de código aberto, popular e amplamente utilizada, o Cetus a usa para gerenciar centenas de milhões de dólares em ativos sem entender completamente onde estão os limites de segurança da biblioteca, se há alternativas adequadas se a biblioteca falhar, e assim por diante. Obviamente, a Cetus carece da mais básica consciência de segurança da cadeia de suprimentos;
Por que é permitido inserir números astronômicos sem estabelecer limites? Embora os protocolos DeFi devam buscar a descentralização, um sistema financeiro maduro, quanto mais aberto, mais precisa de limites claros.
Quando o sistema permite a entrada de números astronômicos meticulosamente elaborados por atacantes, a equipe claramente não pensou se essa demanda de liquidez é razoável. Mesmo o maior hedge fund do mundo não pode precisar de uma cota de liquidez tão exagerada. É evidente que a equipe da Cetus carece de profissionais de gestão de riscos com intuição financeira;
A validação que atravessa as fronteiras da matemática, criptografia e economia é, de fato, a maior lacuna de segurança no DeFi moderno. As empresas de auditoria dirão que "é uma falha no design do modelo econômico, não um problema de lógica de código"; os desenvolvedores do projeto se queixam de que "a auditoria não encontrou problemas"; e os usuários só sabem que o seu dinheiro desapareceu!
Você vê, isso expõe, em última análise, a deficiência sistêmica de segurança na indústria DeFi: equipes com formação puramente técnica carecem seriamente de um básico "instinto para riscos financeiros".
E a partir deste relatório da Cetus, a equipe claramente não refletiu adequadamente.
Em vez de apenas focar nas deficiências técnicas relacionadas a este ataque hacker, eu acho que, a partir da Cetus, todas as equipes DeFi deveriam abandonar a limitação do pensamento puramente técnico e realmente cultivar a consciência de risco de segurança dos "engenheiros financeiros".
Por exemplo, introduzir especialistas em controle de risco financeiro para compensar os pontos cegos de conhecimento da equipe técnica; Realizar um mecanismo de revisão de auditoria multipartidária, não só para analisar a auditoria do código, mas também para compor a necessária auditoria do modelo económico; Cultive o "senso financeiro", simule vários cenários de ataque e contramedidas correspondentes e seja sensível a operações anormais em todos os momentos.
Isso me lembra da experiência anterior em empresas de segurança, incluindo a troca de ideias entre os grandes nomes da segurança da indústria @evilcos, @chiachih_wu, @yajinzhou, @mikelee205, que também tinham esse consenso:
Com o amadurecimento da indústria, os problemas de bugs técnicos a nível de código tendem a diminuir, enquanto a "consciência de bugs" na lógica de negócios, que é nebulosa e com responsabilidades pouco claras, representa o maior desafio.
As empresas de auditoria só podem garantir que o código não tem Bugs, mas como é que se pode garantir que a "lógica tem limites" requer que a equipe do projeto tenha uma compreensão mais profunda da essência do negócio e a capacidade de controlar esses limites. (A principal razão para muitos "incidentes de culpa" que ainda sofreram ataques de hackers após auditorias de segurança é exatamente esta.)
O futuro do DeFi pertence às equipas que dominam a tecnologia de código e compreendem profundamente a lógica de negócios!