En lisant le rapport de sécurité sur le « retour d'expérience » de l'attaque de @CetusProtocol, vous découvrirez un phénomène « intéressant » : les détails techniques sont divulgués de manière assez transparente, la réponse d'urgence est même de niveau « manuel de référence », mais sur la question cruciale « pourquoi avons-nous été piratés », il semble qu'ils évitent de répondre à l'essentiel :
Le rapport explique en détail la fonction checked\_shlw de la bibliothèque integer-mate, qui vérifie les erreurs (devrait être ≤2^192, en réalité ≤2^256), et qualifie cela de « malentendu sémantique ». Bien que cette description soit techniquement valide, elle détourne habilement l'attention vers une responsabilité externe, comme si Cetus était également une victime innocente de ce défaut technique.
La question se pose, puisque integer-mate est une bibliothèque mathématique open source et largement utilisée, pourquoi y a-t-il eu chez vous une erreur absurde où un token pouvait obtenir une part de liquidité à prix d'or ?
L'analyse des chemins d'attaque des hackers révèle que pour réaliser une attaque parfaite, le hacker doit satisfaire simultanément quatre conditions : un contrôle de dépassement d'erreur incorrect, des opérations de décalage importantes, une règle d'arrondi vers le haut et un manque de vérification de la rationalité économique.
Cetus est « négligent » dans toutes les conditions de « déclenchement », telles que : accepter un nombre astronomique tel que l’entrée de l’utilisateur de 2^200, utiliser des calculs de grand déplacement extrêmement dangereux, faire complètement confiance au mécanisme de vérification des bibliothèques externes, et le plus fatal - lorsque le système calcule le résultat absurde de « 1 jeton pour une part de prix vertigineuse », il est directement exécuté sans aucun contrôle de bon sens économique.
Donc, les points que Cetus devrait vraiment réfléchir sont les suivants :
Pourquoi ne puis-je pas faire de tests de sécurité lorsque j’utilise des bibliothèques externes courantes ? Bien que la bibliothèque « integer-mate » soit open source, populaire et largement utilisée, Cetus l’utilise pour gérer des centaines de millions de dollars d’actifs sans comprendre pleinement où se trouvent les limites de sécurité de la bibliothèque, s’il existe des alternatives appropriées en cas de défaillance de la bibliothèque, etc. De toute évidence, Cetus n’a pas la connaissance la plus élémentaire de la sécurité de la chaîne d’approvisionnement ;
Pourquoi est-il permis d'entrer des chiffres astronomiques sans limites ? Bien que les protocoles DeFi devraient viser la décentralisation, un système financier mature, plus il est ouvert, plus il a besoin de limites claires.
Lorsque le système permet d'entrer des nombres astronomiques soigneusement construits par un attaquant, l'équipe n'a manifestement pas réfléchi à la question de savoir si une telle demande de liquidité est raisonnable. Même le plus grand fonds spéculatif au monde ne pourrait avoir besoin d'une part de liquidité aussi exagérée. Il est évident que l'équipe de Cetus manque de talents en gestion des risques dotés d'une intuition financière.
Pourquoi, après plusieurs audits de sécurité, n'a-t-on toujours pas découvert de problèmes à l'avance ? Cette phrase révèle involontairement un fatal biais cognitif : les responsables du projet externalisent la responsabilité de la sécurité à des sociétés de sécurité, prenant l'audit comme une carte de décharge. Mais la réalité est dure : les ingénieurs d'audit de sécurité sont spécialisés dans la détection des bugs du code, qui penserait à tester si le rapport d'échange calculé par le système pourrait être erroné, tel un conte de fées ?
Cette validation qui traverse les frontières des mathématiques, de la cryptographie et de l'économie est précisément le plus grand angle mort de la sécurité DeFi moderne. Les sociétés d'audit diront « c'est un défaut de conception du modèle économique, ce n'est pas un problème de logique de code » ; les équipes de projet se plaignent « l'audit n'a pas détecté de problème » ; et les utilisateurs ne savent que leur argent a disparu !
Vous voyez, cela expose en fin de compte la faiblesse systémique de la sécurité dans l'industrie DeFi : les équipes ayant un profil purement technique manquent gravement de la « sensibilité aux risques financiers » basique.
D'après le rapport de Cetus, l'équipe ne semble clairement pas avoir fait une réflexion adéquate.
Comparé aux défauts techniques liés à la récente attaque par un Hacker, je pense qu'à partir de Cetus, toutes les équipes DeFi devraient dépasser la limitation de la pensée purement technique et vraiment développer la conscience des risques de sécurité des « ingénieurs financiers ».
Par exemple : faire appel à des experts en gestion des risques financiers pour combler les lacunes de connaissances de l'équipe technique ; mettre en place un mécanisme d'audit et de vérification multi-parties, non seulement en examinant l'audit de code, mais aussi en complétant les audits de modèles économiques nécessaires ; développer un « odorat financier », simuler divers scénarios d'attaque et les mesures de réponse appropriées, et rester constamment sensible aux opérations anormales, etc.
Cela me rappelle mon expérience précédente dans une entreprise de sécurité, y compris le consensus entre les grands noms de l'industrie de la sécurité @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 :
Avec la maturité croissante de l'industrie, les problèmes de bugs techniques au niveau du code vont devenir de moins en moins fréquents, tandis que les "bugs de conscience" liés à une logique commerciale floue et à des responsabilités mal définies seront le plus grand défi.
Les sociétés d'audit ne peuvent s'assurer que le code est exempt de bugs, mais pour atteindre une « logique avec des limites », l'équipe du projet doit avoir une compréhension plus approfondie de la nature de l'activité et des capacités de contrôle des limites. (La raison fondamentale de nombreux « incidents de transfert de responsabilité » après des audits de sécurité, où des attaques de hackers ont néanmoins eu lieu, réside essentiellement ici.)
L'avenir de la DeFi appartient aux équipes qui maîtrisent parfaitement la technologie des codes tout en ayant une compréhension approfondie de la logique commerciale !
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Récompense
J'aime
1
Partager
Commentaire
0/400
Insistant
· 05-28 04:13
Dans 99 % des cas, c'est du vol par une personne de confiance.
Plus de 200 millions de dollars volés, quelles leçons l'incident de sécurité de Cetus nous a-t-il apportées ?
En lisant le rapport de sécurité sur le « retour d'expérience » de l'attaque de @CetusProtocol, vous découvrirez un phénomène « intéressant » : les détails techniques sont divulgués de manière assez transparente, la réponse d'urgence est même de niveau « manuel de référence », mais sur la question cruciale « pourquoi avons-nous été piratés », il semble qu'ils évitent de répondre à l'essentiel :
Le rapport explique en détail la fonction
checked\_shlwde la bibliothèqueinteger-mate, qui vérifie les erreurs (devrait être ≤2^192, en réalité ≤2^256), et qualifie cela de « malentendu sémantique ». Bien que cette description soit techniquement valide, elle détourne habilement l'attention vers une responsabilité externe, comme si Cetus était également une victime innocente de ce défaut technique.La question se pose, puisque
integer-mateest une bibliothèque mathématique open source et largement utilisée, pourquoi y a-t-il eu chez vous une erreur absurde où un token pouvait obtenir une part de liquidité à prix d'or ?L'analyse des chemins d'attaque des hackers révèle que pour réaliser une attaque parfaite, le hacker doit satisfaire simultanément quatre conditions : un contrôle de dépassement d'erreur incorrect, des opérations de décalage importantes, une règle d'arrondi vers le haut et un manque de vérification de la rationalité économique.
Cetus est « négligent » dans toutes les conditions de « déclenchement », telles que : accepter un nombre astronomique tel que l’entrée de l’utilisateur de 2^200, utiliser des calculs de grand déplacement extrêmement dangereux, faire complètement confiance au mécanisme de vérification des bibliothèques externes, et le plus fatal - lorsque le système calcule le résultat absurde de « 1 jeton pour une part de prix vertigineuse », il est directement exécuté sans aucun contrôle de bon sens économique.
Donc, les points que Cetus devrait vraiment réfléchir sont les suivants :
Pourquoi ne puis-je pas faire de tests de sécurité lorsque j’utilise des bibliothèques externes courantes ? Bien que la bibliothèque « integer-mate » soit open source, populaire et largement utilisée, Cetus l’utilise pour gérer des centaines de millions de dollars d’actifs sans comprendre pleinement où se trouvent les limites de sécurité de la bibliothèque, s’il existe des alternatives appropriées en cas de défaillance de la bibliothèque, etc. De toute évidence, Cetus n’a pas la connaissance la plus élémentaire de la sécurité de la chaîne d’approvisionnement ;
Pourquoi est-il permis d'entrer des chiffres astronomiques sans limites ? Bien que les protocoles DeFi devraient viser la décentralisation, un système financier mature, plus il est ouvert, plus il a besoin de limites claires.
Lorsque le système permet d'entrer des nombres astronomiques soigneusement construits par un attaquant, l'équipe n'a manifestement pas réfléchi à la question de savoir si une telle demande de liquidité est raisonnable. Même le plus grand fonds spéculatif au monde ne pourrait avoir besoin d'une part de liquidité aussi exagérée. Il est évident que l'équipe de Cetus manque de talents en gestion des risques dotés d'une intuition financière.
Cette validation qui traverse les frontières des mathématiques, de la cryptographie et de l'économie est précisément le plus grand angle mort de la sécurité DeFi moderne. Les sociétés d'audit diront « c'est un défaut de conception du modèle économique, ce n'est pas un problème de logique de code » ; les équipes de projet se plaignent « l'audit n'a pas détecté de problème » ; et les utilisateurs ne savent que leur argent a disparu !
Vous voyez, cela expose en fin de compte la faiblesse systémique de la sécurité dans l'industrie DeFi : les équipes ayant un profil purement technique manquent gravement de la « sensibilité aux risques financiers » basique.
D'après le rapport de Cetus, l'équipe ne semble clairement pas avoir fait une réflexion adéquate.
Comparé aux défauts techniques liés à la récente attaque par un Hacker, je pense qu'à partir de Cetus, toutes les équipes DeFi devraient dépasser la limitation de la pensée purement technique et vraiment développer la conscience des risques de sécurité des « ingénieurs financiers ».
Par exemple : faire appel à des experts en gestion des risques financiers pour combler les lacunes de connaissances de l'équipe technique ; mettre en place un mécanisme d'audit et de vérification multi-parties, non seulement en examinant l'audit de code, mais aussi en complétant les audits de modèles économiques nécessaires ; développer un « odorat financier », simuler divers scénarios d'attaque et les mesures de réponse appropriées, et rester constamment sensible aux opérations anormales, etc.
Cela me rappelle mon expérience précédente dans une entreprise de sécurité, y compris le consensus entre les grands noms de l'industrie de la sécurité @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 :
Avec la maturité croissante de l'industrie, les problèmes de bugs techniques au niveau du code vont devenir de moins en moins fréquents, tandis que les "bugs de conscience" liés à une logique commerciale floue et à des responsabilités mal définies seront le plus grand défi.
Les sociétés d'audit ne peuvent s'assurer que le code est exempt de bugs, mais pour atteindre une « logique avec des limites », l'équipe du projet doit avoir une compréhension plus approfondie de la nature de l'activité et des capacités de contrôle des limites. (La raison fondamentale de nombreux « incidents de transfert de responsabilité » après des audits de sécurité, où des attaques de hackers ont néanmoins eu lieu, réside essentiellement ici.)
L'avenir de la DeFi appartient aux équipes qui maîtrisent parfaitement la technologie des codes tout en ayant une compréhension approfondie de la logique commerciale !