L'équipe ayant un parcours purement technique manque gravement d'un sens de base du « risque financier ».
Rédaction : Haotian
En lisant le rapport de « retour d'expérience » sur la sécurité des attaques informatiques 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 exemplaire, mais sur la question cruciale « pourquoi a-t-on été piraté », il semble esquiver le vrai problème.
Le rapport consacre une grande partie à expliquer 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 valable, 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 largement utilisée, pourquoi un erreur absurde s'est-elle produite chez vous où un seul token peut obtenir une part de liquidité exorbitante ?
L'analyse du chemin d'attaque des hackers révèle que pour réaliser une attaque parfaite, quatre conditions doivent être simultanément remplies : une vérification de dépassement incorrecte, des opérations de décalage importantes, des règles d'arrondi supérieur et un manque de vérification de la rationalité économique.
Cetus a été négligent dans chaque condition de « déclenchement », par exemple : accepter des entrées utilisateur comme 2^200, utiliser des opérations de déplacement à grande échelle extrêmement dangereuses, faire totalement confiance au mécanisme de vérification des bibliothèques externes, et le plus mortel - lorsque le système a calculé un résultat absurde de « 1 token pour une part à prix exorbitant », il n'a même pas effectué de vérification de bon sens économique avant d'exécuter directement.
Donc, les points que Cetus devrait vraiment réfléchir sont les suivants :
Pourquoi avoir utilisé une bibliothèque externe générale sans effectuer de tests de sécurité adéquats ? Bien que la bibliothèque integer-mate présente des caractéristiques telles que l'open source, la popularité et une large utilisation, Cetus l'utilise pour gérer des actifs de plusieurs centaines de millions de dollars sans avoir pleinement compris où se situent les limites de sécurité de cette bibliothèque, et s'il existe des alternatives appropriées en cas de défaillance de la bibliothèque, etc. Il est clair que Cetus manque de la conscience fondamentale de la protection 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, plus un système financier mature est ouvert, plus il a besoin de frontières claires.
Lorsque le système permet d'entrer des nombres astronomiques soigneusement construits par des attaquants, l'équipe n'a clairement pas réfléchi à la question de savoir si une telle demande de liquidité est raisonnable. Même le plus grand fonds de couverture au monde ne pourrait pas 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é, les problèmes n'ont-ils toujours pas été découverts à l'avance ? Cette phrase révèle involontairement une erreur de perception fatale : l'équipe du projet externalise la responsabilité de la sécurité à une société de sécurité et considère l'audit comme un laissez-passer. Mais la réalité est cruelle : les ingénieurs en audit de sécurité sont spécialisés dans la détection des bugs de code, qui aurait pensé à tester si le ratio d'échange calculé par le système était peut-être erroné, comme une absurde rumeur ?
Cette validation qui traverse les frontières des mathématiques, de la cryptographie et de l'économie est justement le plus grand point faible de la sécurité moderne de la DeFi. 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 que « l'audit n'a pas détecté de problème » ; et les utilisateurs ne savent que leur argent a disparu !
Tu vois, au fond, cela expose le point faible systémique de l'industrie DeFi : les équipes ayant uniquement un bagage technique manquent gravement de la « détection des risques financiers » de base.
Et d'après ce rapport de Cetus, l'équipe n'a manifestement pas réfléchi de manière adéquate.
Plutôt que de se concentrer uniquement sur les défauts techniques de cette attaque de hacker, je pense qu'à partir de Cetus, toutes les équipes DeFi devraient abandonner la limitation de la pensée purement technique et véritablement 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 en connaissances de l'équipe technique ; établir un mécanisme d'audit et de révision multi-parties, qui ne se limite pas à l'audit de code, un audit des modèles économiques nécessaires doit également être inclus ; développer un « odorat financier », simuler divers scénarios d'attaque et les mesures de réponse correspondantes, et rester sensible aux opérations anormales à tout moment, etc.
Cela me rappelle une expérience antérieure dans une société de sécurité, y compris le consensus entre les grands noms de l'industrie de la sécurité comme @evilcos, @chiachih_wu, @yajinzhou, @mikelee205.
Avec la maturité croissante de l'industrie, les problèmes de bogues techniques au niveau du code vont diminuer, tandis que les "bogues de conscience" liés à une logique métier floue et à des responsabilités mal définies représentent le plus grand défi.
Les sociétés d'audit peuvent uniquement s'assurer qu'il n'y a pas de bugs dans le code, mais pour garantir que la « logique a des limites », l'équipe du projet doit avoir une compréhension plus approfondie de la nature de l'entreprise et des capacités de contrôle des limites. (La cause fondamentale de nombreux "événements de délégation de responsabilité" où des attaques de hackers ont eu lieu malgré des audits de sécurité réside précisément ici.)
L'avenir de la DeFi appartient aux équipes qui maîtrisent les techniques de codage tout en comprenant profondément la logique des affaires!
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.
Problèmes de sécurité de Cetus : que doit garder à l'esprit l'équipe DeFi ?
Rédaction : Haotian
En lisant le rapport de « retour d'expérience » sur la sécurité des attaques informatiques 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 exemplaire, mais sur la question cruciale « pourquoi a-t-on été piraté », il semble esquiver le vrai problème.
Le rapport consacre une grande partie à expliquer la fonction
checked\_shlwde la bibliothèqueinteger-matequi 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 valable, 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 largement utilisée, pourquoi un erreur absurde s'est-elle produite chez vous où un seul token peut obtenir une part de liquidité exorbitante ?L'analyse du chemin d'attaque des hackers révèle que pour réaliser une attaque parfaite, quatre conditions doivent être simultanément remplies : une vérification de dépassement incorrecte, des opérations de décalage importantes, des règles d'arrondi supérieur et un manque de vérification de la rationalité économique.
Cetus a été négligent dans chaque condition de « déclenchement », par exemple : accepter des entrées utilisateur comme 2^200, utiliser des opérations de déplacement à grande échelle extrêmement dangereuses, faire totalement confiance au mécanisme de vérification des bibliothèques externes, et le plus mortel - lorsque le système a calculé un résultat absurde de « 1 token pour une part à prix exorbitant », il n'a même pas effectué de vérification de bon sens économique avant d'exécuter directement.
Donc, les points que Cetus devrait vraiment réfléchir sont les suivants :
Pourquoi avoir utilisé une bibliothèque externe générale sans effectuer de tests de sécurité adéquats ? Bien que la bibliothèque
integer-mateprésente des caractéristiques telles que l'open source, la popularité et une large utilisation, Cetus l'utilise pour gérer des actifs de plusieurs centaines de millions de dollars sans avoir pleinement compris où se situent les limites de sécurité de cette bibliothèque, et s'il existe des alternatives appropriées en cas de défaillance de la bibliothèque, etc. Il est clair que Cetus manque de la conscience fondamentale de la protection 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, plus un système financier mature est ouvert, plus il a besoin de frontières claires.
Lorsque le système permet d'entrer des nombres astronomiques soigneusement construits par des attaquants, l'équipe n'a clairement pas réfléchi à la question de savoir si une telle demande de liquidité est raisonnable. Même le plus grand fonds de couverture au monde ne pourrait pas 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 justement le plus grand point faible de la sécurité moderne de la DeFi. 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 que « l'audit n'a pas détecté de problème » ; et les utilisateurs ne savent que leur argent a disparu !
Tu vois, au fond, cela expose le point faible systémique de l'industrie DeFi : les équipes ayant uniquement un bagage technique manquent gravement de la « détection des risques financiers » de base.
Et d'après ce rapport de Cetus, l'équipe n'a manifestement pas réfléchi de manière adéquate.
Plutôt que de se concentrer uniquement sur les défauts techniques de cette attaque de hacker, je pense qu'à partir de Cetus, toutes les équipes DeFi devraient abandonner la limitation de la pensée purement technique et véritablement 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 en connaissances de l'équipe technique ; établir un mécanisme d'audit et de révision multi-parties, qui ne se limite pas à l'audit de code, un audit des modèles économiques nécessaires doit également être inclus ; développer un « odorat financier », simuler divers scénarios d'attaque et les mesures de réponse correspondantes, et rester sensible aux opérations anormales à tout moment, etc.
Cela me rappelle une expérience antérieure dans une société de sécurité, y compris le consensus entre les grands noms de l'industrie de la sécurité comme @evilcos, @chiachih_wu, @yajinzhou, @mikelee205.
Avec la maturité croissante de l'industrie, les problèmes de bogues techniques au niveau du code vont diminuer, tandis que les "bogues de conscience" liés à une logique métier floue et à des responsabilités mal définies représentent le plus grand défi.
Les sociétés d'audit peuvent uniquement s'assurer qu'il n'y a pas de bugs dans le code, mais pour garantir que la « logique a des limites », l'équipe du projet doit avoir une compréhension plus approfondie de la nature de l'entreprise et des capacités de contrôle des limites. (La cause fondamentale de nombreux "événements de délégation de responsabilité" où des attaques de hackers ont eu lieu malgré des audits de sécurité réside précisément ici.)
L'avenir de la DeFi appartient aux équipes qui maîtrisent les techniques de codage tout en comprenant profondément la logique des affaires!