A equipe com um fundo puramente técnico carece seriamente de um básico "instinto de risco financeiro".
Escrito por: Haotian
Após ler o relatório de "revisão" sobre a segurança de ataques cibernéticos do @CetusProtocol, você encontrará um fenômeno "intrigante": os detalhes técnicos são divulgados de forma bastante transparente, a resposta a emergências é digna de um manual, mas na questão mais crucial de "por que foi hackeado", a resposta parece evitar o cerne da questão:
O relatório utiliza uma grande extensão para explicar a função checked\_shlw da biblioteca integer-mate, que verifica erros (deveria ser ≤2^192, mas na prática é ≤2^256), e qualifica isso como uma "má interpretação semântica". Embora essa descrição seja tecnicamente válida, desvia habilmente o foco para a responsabilidade externa, como se a Cetus também fosse uma vítima inocente desse defeito técnico.
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 um único token pode obter uma parte de liquidez a um preço exorbitante?
Analisando o caminho do ataque do hacker, descobrir-se-á que, para realizar um ataque perfeito, o hacker deve atender a quatro condições: verificação de estouro de erro incorreta, operações de deslocamento amplas, regras de arredondamento para cima, e falta de verificação de viabilidade econômica.
Cetus negligenciou cada uma das condições de "gatilho", por exemplo: aceitar a entrada do usuário 2^200, um número astronômico, realizar operações de deslocamento extremo e perigosas, confiar completamente no mecanismo de verificação de bibliotecas externas e, o mais fatal, quando o sistema calculou um resultado absurdo de "1 token por uma quota exorbitante", não houve nenhuma verificação de senso econômico antes de ser executado.
Assim, os pontos que o Cetus realmente deve refletir são os seguintes:
1）Por que é que a utilização de bibliotecas externas gerais não foi devidamente testada em termos de segurança? Embora a biblioteca integer-mate tenha características como ser open source, popular e amplamente utilizada, a Cetus usou-a para gerir ativos de mais de cem milhões de dólares sem ter uma compreensão adequada de onde estão os limites de segurança dessa biblioteca, se a função da biblioteca falhar, se há alternativas adequadas, entre outras questões. É evidente que a Cetus carece da mais básica consciência de proteção da 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, quanto mais aberto é um sistema financeiro maduro, mais precisa de limites claros.
Quando o sistema permite a entrada de números astronômicos elaborados por atacantes, a equipe claramente não pensou se essa demanda de liquidez é razoável. Mesmo o maior fundo de hedge do mundo não poderia precisar de uma participação de liquidez tão exagerada. É evidente que a equipe da Cetus carece de profissionais de gestão de risco com intuição financeira;
Por que ainda não há nenhum problema encontrado com antecedência após várias rodadas de auditorias de segurança? Esta frase expõe inadvertidamente um mal-entendido cognitivo fatal: a equipe do projeto terceiriza a responsabilidade de segurança para a empresa de segurança e considera a auditoria como uma medalha de ouro para isenção. Mas a realidade é dura: os engenheiros de auditoria de segurança são bons em encontrar bugs de código, e quem teria pensado que poderia ser errado testar o sistema para calcular a fantástica taxa de troca?
Essa validação que atravessa as fronteiras da matemática, criptografia e economia é a maior zona cega da segurança DeFi moderna. As empresas de auditoria dirão "Este é um defeito de design do modelo econômico, não um problema de lógica de código"; as equipes do projeto reclamam "a auditoria não encontrou problemas"; e os usuários só sabem que seu dinheiro desapareceu!
Veja, no fundo, isso expõe a lacuna de segurança sistêmica na indústria DeFi: equipes com formação puramente técnica carecem gravemente de um "instinto para riscos financeiros" básico.
E, a partir do relatório da Cetus, a equipe claramente não refletiu adequadamente.
Em vez de focar apenas nas deficiências técnicas que levaram ao ataque hacker, creio que a partir da Cetus, todas as equipas DeFi devem 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: trazer especialistas em gestão de risco financeiro para preencher as lacunas de conhecimento da equipe técnica; implementar um mecanismo de auditoria multifacetado que não se limite apenas à auditoria de código, mas que também inclua auditorias de modelos econômicos quando necessário; desenvolver um "instinto financeiro", simular vários cenários de ataque e as respectivas medidas de resposta, e manter-se sensível a operações anômalas em todos os momentos, entre outros.
Isso me lembra da experiência anterior em uma empresa de segurança, incluindo um consenso entre grandes nomes da segurança do setor como @evilcos, @chiachih_wu, @yajinzhou, @mikelee205.
À medida que a indústria se torna mais madura, os problemas de bugs técnicos a nível de código tendem a diminuir, enquanto os "bugs de consciência" da lógica de negócios, com fronteiras pouco claras e responsabilidades ambíguas, são o maior desafio.
As empresas de auditoria podem apenas garantir que o código não tem Bugs, mas como é possível 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 razão fundamental para muitos "casos de desvio de responsabilidade" que ainda sofreram ataques de hackers após auditorias de segurança anteriores está aqui.)
O futuro do DeFi pertence a equipes que têm habilidades sólidas em tecnologia de código e uma compreensão profunda da lógica de negócios!
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Cetus questões de segurança: O que as equipes de Finanças Descentralizadas devem ter em atenção?
Escrito por: Haotian
Após ler o relatório de "revisão" sobre a segurança de ataques cibernéticos do @CetusProtocol, você encontrará um fenômeno "intrigante": os detalhes técnicos são divulgados de forma bastante transparente, a resposta a emergências é digna de um manual, mas na questão mais crucial de "por que foi hackeado", a resposta parece evitar o cerne da questão:
O relatório utiliza uma grande extensão para explicar a função
checked\_shlwda bibliotecainteger-mate, que verifica erros (deveria ser ≤2^192, mas na prática é ≤2^256), e qualifica isso como uma "má interpretação semântica". Embora essa descrição seja tecnicamente válida, desvia habilmente o foco para a responsabilidade externa, como se a Cetus também fosse uma vítima inocente desse defeito técnico.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 um único token pode obter uma parte de liquidez a um preço exorbitante?Analisando o caminho do ataque do hacker, descobrir-se-á que, para realizar um ataque perfeito, o hacker deve atender a quatro condições: verificação de estouro de erro incorreta, operações de deslocamento amplas, regras de arredondamento para cima, e falta de verificação de viabilidade econômica.
Cetus negligenciou cada uma das condições de "gatilho", por exemplo: aceitar a entrada do usuário 2^200, um número astronômico, realizar operações de deslocamento extremo e perigosas, confiar completamente no mecanismo de verificação de bibliotecas externas e, o mais fatal, quando o sistema calculou um resultado absurdo de "1 token por uma quota exorbitante", não houve nenhuma verificação de senso econômico antes de ser executado.
Assim, os pontos que o Cetus realmente deve refletir são os seguintes:
1）Por que é que a utilização de bibliotecas externas gerais não foi devidamente testada em termos de segurança? Embora a biblioteca
integer-matetenha características como ser open source, popular e amplamente utilizada, a Cetus usou-a para gerir ativos de mais de cem milhões de dólares sem ter uma compreensão adequada de onde estão os limites de segurança dessa biblioteca, se a função da biblioteca falhar, se há alternativas adequadas, entre outras questões. É evidente que a Cetus carece da mais básica consciência de proteção da segurança da cadeia de suprimentos;Quando o sistema permite a entrada de números astronômicos elaborados por atacantes, a equipe claramente não pensou se essa demanda de liquidez é razoável. Mesmo o maior fundo de hedge do mundo não poderia precisar de uma participação de liquidez tão exagerada. É evidente que a equipe da Cetus carece de profissionais de gestão de risco com intuição financeira;
Essa validação que atravessa as fronteiras da matemática, criptografia e economia é a maior zona cega da segurança DeFi moderna. As empresas de auditoria dirão "Este é um defeito de design do modelo econômico, não um problema de lógica de código"; as equipes do projeto reclamam "a auditoria não encontrou problemas"; e os usuários só sabem que seu dinheiro desapareceu!
Veja, no fundo, isso expõe a lacuna de segurança sistêmica na indústria DeFi: equipes com formação puramente técnica carecem gravemente de um "instinto para riscos financeiros" básico.
E, a partir do relatório da Cetus, a equipe claramente não refletiu adequadamente.
Em vez de focar apenas nas deficiências técnicas que levaram ao ataque hacker, creio que a partir da Cetus, todas as equipas DeFi devem 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: trazer especialistas em gestão de risco financeiro para preencher as lacunas de conhecimento da equipe técnica; implementar um mecanismo de auditoria multifacetado que não se limite apenas à auditoria de código, mas que também inclua auditorias de modelos econômicos quando necessário; desenvolver um "instinto financeiro", simular vários cenários de ataque e as respectivas medidas de resposta, e manter-se sensível a operações anômalas em todos os momentos, entre outros.
Isso me lembra da experiência anterior em uma empresa de segurança, incluindo um consenso entre grandes nomes da segurança do setor como @evilcos, @chiachih_wu, @yajinzhou, @mikelee205.
À medida que a indústria se torna mais madura, os problemas de bugs técnicos a nível de código tendem a diminuir, enquanto os "bugs de consciência" da lógica de negócios, com fronteiras pouco claras e responsabilidades ambíguas, são o maior desafio.
As empresas de auditoria podem apenas garantir que o código não tem Bugs, mas como é possível 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 razão fundamental para muitos "casos de desvio de responsabilidade" que ainda sofreram ataques de hackers após auditorias de segurança anteriores está aqui.)
O futuro do DeFi pertence a equipes que têm habilidades sólidas em tecnologia de código e uma compreensão profunda da lógica de negócios!