Cetus : quelles sont les leçons à retenir en matière de sécurité ? Que doivent savoir les équipes DeFi ?
TechFlow SélectionTechFlow Sélection
Cetus : quelles sont les leçons à retenir en matière de sécurité ? Que doivent savoir les équipes DeFi ?
À partir de Cetus, toutes les équipes DeFi devraient sortir des limites d'une pensée purement technique et développer réellement une conscience des risques sécuritaires d'« ingénieur financier ».
Dédié à des analyses Web3 approfondiesRédaction : Haotian
Après avoir lu le rapport de « reconstitution » de l'attaque de sécurité de @CetusProtocol, vous remarquerez un phénomène « intrigant » : les détails techniques sont extrêmement transparents, la réponse d'urgence est presque exemplaire, mais sur la question fondamentale « pourquoi avoir été piraté ? », le rapport semble esquiver le cœur du sujet :
Le rapport consacre une grande partie à expliquer l’erreur dans la fonction `checked_shlw` de la bibliothèque `integer-mate` (la vérification aurait dû être ≤2^192, mais était en réalité ≤2^256), qualifiant cela de « malentendu sémantique ». Cette explication est techniquement correcte, mais habilement, elle déplace la responsabilité vers l’extérieur, comme si Cetus était lui-même une victime innocente de ce défaut technique.
Or voici la question : puisque `integer-mate` est une bibliothèque mathématique open source et largement utilisée, pourquoi précisément chez vous un token unique a-t-il pu obtenir une part de liquidité exorbitante ?
L’analyse du chemin d’attaque révèle que pour réussir parfaitement son attaque, le pirate devait simultanément remplir quatre conditions : erreur de vérification de dépassement, opération de décalage important, règle d’arrondi supérieur, et absence de validation de la cohérence économique.
Cetus a justement fait preuve de négligence sur chacune de ces conditions déclenchantes : accepter des entrées utilisateur comme 2^200, utiliser des opérations de décalage extrêmement dangereuses, faire entièrement confiance au mécanisme de vérification externe, et surtout — lorsque le système calcule un résultat absurde tel que « 1 token échangé contre une part colossale », il l’exécute sans aucune vérification basée sur le bon sens économique.
Ainsi, les véritables points sur lesquels Cetus devrait réfléchir sont les suivants :
1) Pourquoi avoir utilisé une bibliothèque externe générique sans effectuer de tests de sécurité rigoureux ? Bien que la bibliothèque `integer-mate` soit open source, populaire et largement utilisée, Cetus l’a employée pour gérer des actifs de plusieurs centaines de millions de dollars sans pleinement comprendre ses limites de sécurité ni envisager de solution de secours en cas de défaillance. Il est clair que Cetus manque de conscience fondamentale en matière de sécurité de la chaîne d'approvisionnement ;
2) Pourquoi autoriser des entrées numériques astronomiques sans limite ? Bien qu’un protocole DeFi cherche à être décentralisé, un système financier mature doit d’autant plus fixer des limites claires qu’il est ouvert.
Lorsque le système permet d’entrer des nombres soigneusement conçus par un attaquant, l’équipe n’a visiblement pas réfléchi à la pertinence d’une telle demande de liquidité. Même le plus grand fonds spéculatif mondial ne pourrait avoir besoin d’une part aussi extravagante. Il est évident que l’équipe Cetus manque de talents en gestion des risques dotés d’intuition financière ;
3) Comment se fait-il que plusieurs audits de sécurité n’aient pas permis de détecter le problème à l’avance ? Cette phrase révèle involontairement une erreur cognitive fatale : les projets externalisent la responsabilité de la sécurité aux sociétés spécialisées, considérant l’audit comme un sauf-conduit. Mais la réalité est cruelle : les ingénieurs d’audit savent repérer les bogues de code, mais qui irait tester si un ratio d’échange délirant calculé par le système est anormal ?
C’est précisément cette vérification transversale entre mathématiques, cryptographie et économie qui constitue le plus grand point aveugle de la sécurité moderne en DeFi. Les sociétés d’audit diront : « c’est un défaut de conception du modèle économique, pas un problème logique de code » ; les équipes projet répondront : « l’audit n’a rien trouvé » ; et les utilisateurs ne verront que leur argent disparaître !
Vous voyez, cela révèle en fin de compte une lacune systémique de sécurité dans l’industrie DeFi : les équipes purement techniques manquent gravement d’un « instinct de risque financier » de base.
Et d’après ce rapport de Cetus, l’équipe n’a visiblement pas suffisamment réfléchi.
Plutôt que de se limiter à corriger les insuffisances techniques liées à cet incident, je pense que tous les projets DeFi devraient, à partir de Cetus, dépasser leur vision purement technique et développer véritablement une conscience de sécurité propre aux « ingénieurs financiers ».
Par exemple : intégrer des experts en contrôle financier pour combler les lacunes techniques ; mettre en place un mécanisme d’audit pluridisciplinaire, en examinant non seulement le code mais aussi le modèle économique ; cultiver un « instinct financier », simuler divers scénarios d’attaque et leurs réponses, rester constamment vigilant face aux opérations anormales, etc.
Cela me rappelle mon expérience passée dans une société de sécurité, ainsi que les échanges avec des experts reconnus du secteur comme @evilcos, @chiachih_wu, @yajinzhou, @mikelee205, qui partagent ce même consensus :
Avec la maturité croissante du secteur, les bogues techniques au niveau du code diminueront progressivement, tandis que les « bogues cognitifs » liés à des logiques métier floues et à des responsabilités mal définies deviendront le plus grand défi.
Une société d’audit peut garantir l’absence de bogues dans le code, mais assurer que la « logique ait des limites » exige que l’équipe projet comprenne profondément l’essence métier et maîtrise les frontières de son application. (La racine de nombreux incidents de « report de responsabilité » après des audits sécuritaires réside précisément là.)
L’avenir de la DeFi appartient aux équipes qui maîtrisent non seulement le code, mais comprennent aussi profondément la logique métier !
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Haotian | CryptoInsight
