Après avoir lu le rapport d’examen de la sécurité des pirates informatiques de @CetusProtocol, vous découvrirez un phénomène « intriguant » : les détails techniques sont divulgués de manière assez transparente, et la réponse d’urgence est de niveau classique, mais la torture de l’âme la plus critique de « pourquoi a-t-il été piraté » semble être évasive :
Le rapport consacre une grande partie à expliquer la fonction checked\_shlw de la bibliothèque integer-mate pour vérifier les erreurs (devrait être ≤2^192, en réalité ≤2^256), et qualifie cela de « malentendu sémantique ». Bien que cette déclaration 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 largement utilisée, comment se fait-il qu'il y ait une erreur absurde chez vous où un seul token permet d'obtenir une part de liquidité exorbitante ?
L'analyse des chemins 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ébordement incorrecte, des opérations de décalage importantes, des règles d'arrondi vers le haut, et un manque de vérification de la rationalité économique.
Cetus a été "négligent" à chaque condition de "déclenchement", par exemple : accepter une entrée utilisateur comme 2^200, utiliser des opérations de décalage massives extrêmement dangereuses, faire entièrement confiance aux mécanismes de vérification des bibliothèques externes, et le plus mortel est — lorsque le système a calculé un résultat aussi absurde que "1 token contre une part à prix exorbitant", il n'y avait aucune vérification de bon sens économique avant l'exécution.
Ainsi, les points que Cetus devrait réellement réfléchir sont les suivants :
Pourquoi le choix d'une bibliothèque externe générique n'a-t-il pas été accompagné 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 utilisation répandue, 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 solutions de rechange appropriées en cas de défaillance de la bibliothèque, etc. Il est évident que Cetus manque de la conscience de base de la sécurité de la chaîne d'approvisionnement ;
Pourquoi est-il permis d'entrer des chiffres astronomiques sans limite ? Bien que les protocoles DeFi cherchent à être décentralisés, un système financier mature, plus il est ouvert, plus il a besoin de limites claires.
Lorsque le système a autorisé un montant astronomique soigneusement construit par un attaquant, l’équipe ne s’est apparemment pas demandé si une telle exigence de liquidité était raisonnable. Même le plus grand fonds spéculatif du monde n’aura probablement pas besoin d’une part aussi exagérée de liquidités. De toute évidence, l’équipe de Cetus manquait de talents en gestion des risques et d’une intuition financière.
Pourquoi n’y a-t-il toujours aucun problème trouvé à l’avance après plusieurs séries d’audits de sécurité ? Cette phrase expose par inadvertance un malentendu cognitif fatal : l’équipe de projet sous-traite la responsabilité de la sécurité à l’entreprise de sécurité et considère l’audit comme une médaille d’or pour l’exemption. Mais la réalité est dure : les ingénieurs d’audit de sécurité sont doués pour trouver des bogues de code, et qui aurait pensé qu’il pourrait être erroné de tester le système pour calculer le fantastique taux d’échange ?
Cette vérification à la croisée 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, pas un problème de logique de code » ; les équipes de projet se plaignent que « l'audit n'a pas trouvé de problème » ; tandis que les utilisateurs ne savent que leur argent a disparu !
Tu vois, cela révèle en fin de compte la faiblesse systémique en matière de sécurité de l'industrie DeFi : les équipes ayant un background purement technique manquent gravement de la « sensibilité au risque financier » fondamentale.
Et d'après ce rapport de Cetus, l'équipe n'a manifestement pas suffisamment réfléchi.
Plutôt que de se concentrer uniquement sur les défauts techniques liés à cette attaque de hacker, je pense qu'à partir de Cetus, toutes les équipes DeFi devraient abandonner les limitations d'une pensée purement technique et vraiment cultiver la sensibilisation aux risques de sécurité des "ingénieurs financiers".
Par exemple : faire appel à des experts en gestion des risques financiers pour combler les lacunes de connaissance de l'équipe technique ; établir un mécanisme d'audit et de révision impliquant plusieurs parties, pas seulement l'audit de code, mais aussi l'audit des modèles économiques lorsque cela est nécessaire ; développer un « sens financier », simuler divers scénarios d'attaque et les mesures de réponse correspondantes, et rester constamment attentif aux opérations anormales, etc.
Cela me rappelle l'expérience professionnelle antérieure dans des sociétés de sécurité, y compris le consensus partagé lors des échanges avec des grands noms de l'industrie tels que @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 :
Avec la maturation 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 constitueront le plus grand défi.
Les sociétés d'audit ne peuvent garantir que le code est exempt de bugs, mais pour parvenir à « des logiques avec des limites », l'équipe du projet doit avoir une compréhension plus approfondie de l'essence de l'entreprise et être capable de gérer ces limites. (La raison fondamentale des nombreux « incidents de blâme » où des attaques de hackers ont eu lieu même après des audits de sécurité réside ici.)
L'avenir de la DeFi appartient aux équipes qui maîtrisent parfaitement la technologie du code 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.
Cetus problèmes de sécurité : Quelles sont les choses dont l'équipe DeFi doit être consciente ?
Auteur : Haotian
Après avoir lu le rapport d’examen de la sécurité des pirates informatiques de @CetusProtocol, vous découvrirez un phénomène « intriguant » : les détails techniques sont divulgués de manière assez transparente, et la réponse d’urgence est de niveau classique, mais la torture de l’âme la plus critique de « pourquoi a-t-il été piraté » semble être évasive :
Le rapport consacre une grande partie à expliquer la fonction
checked\_shlwde la bibliothèqueinteger-matepour vérifier les erreurs (devrait être ≤2^192, en réalité ≤2^256), et qualifie cela de « malentendu sémantique ». Bien que cette déclaration 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 largement utilisée, comment se fait-il qu'il y ait une erreur absurde chez vous où un seul token permet d'obtenir une part de liquidité exorbitante ?L'analyse des chemins 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ébordement incorrecte, des opérations de décalage importantes, des règles d'arrondi vers le haut, et un manque de vérification de la rationalité économique.
Cetus a été "négligent" à chaque condition de "déclenchement", par exemple : accepter une entrée utilisateur comme 2^200, utiliser des opérations de décalage massives extrêmement dangereuses, faire entièrement confiance aux mécanismes de vérification des bibliothèques externes, et le plus mortel est — lorsque le système a calculé un résultat aussi absurde que "1 token contre une part à prix exorbitant", il n'y avait aucune vérification de bon sens économique avant l'exécution.
Ainsi, les points que Cetus devrait réellement réfléchir sont les suivants :
Pourquoi le choix d'une bibliothèque externe générique n'a-t-il pas été accompagné 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 utilisation répandue, 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 solutions de rechange appropriées en cas de défaillance de la bibliothèque, etc. Il est évident que Cetus manque de la conscience de base de la sécurité de la chaîne d'approvisionnement ;Pourquoi est-il permis d'entrer des chiffres astronomiques sans limite ? Bien que les protocoles DeFi cherchent à être décentralisés, un système financier mature, plus il est ouvert, plus il a besoin de limites claires.
Lorsque le système a autorisé un montant astronomique soigneusement construit par un attaquant, l’équipe ne s’est apparemment pas demandé si une telle exigence de liquidité était raisonnable. Même le plus grand fonds spéculatif du monde n’aura probablement pas besoin d’une part aussi exagérée de liquidités. De toute évidence, l’équipe de Cetus manquait de talents en gestion des risques et d’une intuition financière.
Cette vérification à la croisée 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, pas un problème de logique de code » ; les équipes de projet se plaignent que « l'audit n'a pas trouvé de problème » ; tandis que les utilisateurs ne savent que leur argent a disparu !
Tu vois, cela révèle en fin de compte la faiblesse systémique en matière de sécurité de l'industrie DeFi : les équipes ayant un background purement technique manquent gravement de la « sensibilité au risque financier » fondamentale.
Et d'après ce rapport de Cetus, l'équipe n'a manifestement pas suffisamment réfléchi.
Plutôt que de se concentrer uniquement sur les défauts techniques liés à cette attaque de hacker, je pense qu'à partir de Cetus, toutes les équipes DeFi devraient abandonner les limitations d'une pensée purement technique et vraiment cultiver la sensibilisation aux risques de sécurité des "ingénieurs financiers".
Par exemple : faire appel à des experts en gestion des risques financiers pour combler les lacunes de connaissance de l'équipe technique ; établir un mécanisme d'audit et de révision impliquant plusieurs parties, pas seulement l'audit de code, mais aussi l'audit des modèles économiques lorsque cela est nécessaire ; développer un « sens financier », simuler divers scénarios d'attaque et les mesures de réponse correspondantes, et rester constamment attentif aux opérations anormales, etc.
Cela me rappelle l'expérience professionnelle antérieure dans des sociétés de sécurité, y compris le consensus partagé lors des échanges avec des grands noms de l'industrie tels que @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 :
Avec la maturation 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 constitueront le plus grand défi.
Les sociétés d'audit ne peuvent garantir que le code est exempt de bugs, mais pour parvenir à « des logiques avec des limites », l'équipe du projet doit avoir une compréhension plus approfondie de l'essence de l'entreprise et être capable de gérer ces limites. (La raison fondamentale des nombreux « incidents de blâme » où des attaques de hackers ont eu lieu même après des audits de sécurité réside ici.)
L'avenir de la DeFi appartient aux équipes qui maîtrisent parfaitement la technologie du code tout en ayant une compréhension approfondie de la logique commerciale !