Após ler o relatório de "análise" sobre o ataque cibernético à @CetusProtocol, você encontrará um fenômeno "interessante": os detalhes técnicos são divulgados 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 uma grande extensão para explicar a verificação de erros na função checked\_shlw da biblioteca integer-mate (deveria ser ≤2^192, 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 é: uma vez que integer-mate é uma biblioteca matemática de código aberto e amplamente utilizada, como é que ocorre um erro absurdo em que se pode obter uma enorme parte da liquidez por apenas 1 token?
Analisando o caminho de ataque dos hackers, descobrimos que, para realizar um ataque perfeito, os hackers devem satisfazer simultaneamente quatro condições: verificação de overflow incorreta, operações de deslocamento significativas, regra de arredondamento para cima e falta de verificação de viabilidade econômica.
Cetus descuidou em cada uma das condições de "disparo", como por exemplo: aceitar entradas do usuário como 2^200, usar operações de deslocamento extremamente perigosas, confiar completamente nos mecanismos de verificação de bibliotecas externas, e o mais mortal de tudo — quando o sistema calcula um resultado absurdo como "1 token por uma quota exorbitante", ele não executou nenhuma verificação de senso econômico e simplesmente o executou.
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 definir 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 cuidadosamente 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 pode precisar de uma cota de liquidez tão exagerada. É evidente que a equipe da Cetus carece de talentos em gestão de riscos com intuição financeira.
Por que, após várias auditorias de segurança, ainda não foi possível detectar problemas antecipadamente? Esta frase revela inadvertidamente uma falha de percepção fatal: a equipe do projeto terceiriza a responsabilidade de segurança para a empresa de segurança, tratando a auditoria como um passe livre de responsabilidade. Mas a realidade é cruel: os engenheiros de auditoria de segurança são especialistas em identificar bugs de código, quem imaginaria que testar o sistema para calcular proporções de troca absurdas poderia estar errado?
Esta validação que cruza as fronteiras da matemática, criptografia e economia é a maior lacuna de segurança do DeFi moderno. 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 dos projetos reclamam "A auditoria não encontrou problemas"; e os usuários só sabem que o seu dinheiro desapareceu!
Você vê, isso revela, em última análise, a deficiência de segurança sistêmica da indústria DeFi: equipes com formação puramente técnica carecem seriamente de um básico "olfato para riscos financeiros".
E a partir deste relatório da Cetus, a equipa claramente não fez uma reflexão adequada.
Em vez de se concentrar apenas nas deficiências técnicas relacionadas a este ataque hacker, eu acho que, a partir da Cetus, todas as equipes 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: introduzir especialistas em gestão de riscos financeiros para preencher as lacunas de conhecimento da equipe técnica; estabelecer um mecanismo de auditoria de múltiplas partes, não apenas focando na auditoria de código, mas também na auditoria de modelos econômicos, quando necessário; cultivar um "instinto financeiro", simular vários cenários de ataque e as respectivas medidas de resposta, mantendo sempre uma sensibilidade para operações anômalas, entre outros.
Isso me lembra da experiência anterior na empresa de segurança, incluindo o consenso entre os grandes nomes da segurança do setor @evilcos, @chiachih_wu, @yajinzhou, @mikelee205:
Com a maturação crescente da indústria, os problemas técnicos de Bug a nível de código tendem a diminuir, enquanto os "Bugs de consciência" na lógica de negócios, onde as fronteiras não são claras e as responsabilidades são ambíguas, representam o maior desafio.
As empresas de auditoria só podem garantir que o código não tem bugs, mas para alcançar "lógica com limites", a equipe do projeto precisa ter uma compreensão mais profunda da essência do negócio e a capacidade de controle de limites. (A raiz de muitos "incidentes de transferência de culpa" após auditorias de segurança, que ainda sofreram ataques de hackers, está exatamente aqui)
O futuro do DeFi pertence às equipas que dominam bem 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.
Recompensa
curtir
1
Compartilhar
Comentário
0/400
Insistant
· 05-28 04:13
Este tipo de coisa é 99% um caso de desvio de fundos.
Mais de 200 milhões de dólares foram roubados, quais lições o incidente de segurança da Cetus trouxe?
Após ler o relatório de "análise" sobre o ataque cibernético à @CetusProtocol, você encontrará um fenômeno "interessante": os detalhes técnicos são divulgados 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 uma grande extensão para explicar a verificação de erros na função
checked\_shlwda bibliotecainteger-mate(deveria ser ≤2^192, 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 é: uma vez que
integer-mateé uma biblioteca matemática de código aberto e amplamente utilizada, como é que ocorre um erro absurdo em que se pode obter uma enorme parte da liquidez por apenas 1 token?Analisando o caminho de ataque dos hackers, descobrimos que, para realizar um ataque perfeito, os hackers devem satisfazer simultaneamente quatro condições: verificação de overflow incorreta, operações de deslocamento significativas, regra de arredondamento para cima e falta de verificação de viabilidade econômica.
Cetus descuidou em cada uma das condições de "disparo", como por exemplo: aceitar entradas do usuário como 2^200, usar operações de deslocamento extremamente perigosas, confiar completamente nos mecanismos de verificação de bibliotecas externas, e o mais mortal de tudo — quando o sistema calcula um resultado absurdo como "1 token por uma quota exorbitante", ele não executou nenhuma verificação de senso econômico e simplesmente o executou.
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 definir 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 cuidadosamente 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 pode precisar de uma cota de liquidez tão exagerada. É evidente que a equipe da Cetus carece de talentos em gestão de riscos com intuição financeira.
Esta validação que cruza as fronteiras da matemática, criptografia e economia é a maior lacuna de segurança do DeFi moderno. 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 dos projetos reclamam "A auditoria não encontrou problemas"; e os usuários só sabem que o seu dinheiro desapareceu!
Você vê, isso revela, em última análise, a deficiência de segurança sistêmica da indústria DeFi: equipes com formação puramente técnica carecem seriamente de um básico "olfato para riscos financeiros".
E a partir deste relatório da Cetus, a equipa claramente não fez uma reflexão adequada.
Em vez de se concentrar apenas nas deficiências técnicas relacionadas a este ataque hacker, eu acho que, a partir da Cetus, todas as equipes 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: introduzir especialistas em gestão de riscos financeiros para preencher as lacunas de conhecimento da equipe técnica; estabelecer um mecanismo de auditoria de múltiplas partes, não apenas focando na auditoria de código, mas também na auditoria de modelos econômicos, quando necessário; cultivar um "instinto financeiro", simular vários cenários de ataque e as respectivas medidas de resposta, mantendo sempre uma sensibilidade para operações anômalas, entre outros.
Isso me lembra da experiência anterior na empresa de segurança, incluindo o consenso entre os grandes nomes da segurança do setor @evilcos, @chiachih_wu, @yajinzhou, @mikelee205:
Com a maturação crescente da indústria, os problemas técnicos de Bug a nível de código tendem a diminuir, enquanto os "Bugs de consciência" na lógica de negócios, onde as fronteiras não são claras e as responsabilidades são ambíguas, representam o maior desafio.
As empresas de auditoria só podem garantir que o código não tem bugs, mas para alcançar "lógica com limites", a equipe do projeto precisa ter uma compreensão mais profunda da essência do negócio e a capacidade de controle de limites. (A raiz de muitos "incidentes de transferência de culpa" após auditorias de segurança, que ainda sofreram ataques de hackers, está exatamente aqui)
O futuro do DeFi pertence às equipas que dominam bem a tecnologia de código e compreendem profundamente a lógica de negócios!