Le protocole Cetus a récemment publié un rapport de rétrospective sur la sécurité concernant un incident de hacking. Ce rapport est assez transparent dans ses détails techniques et sa réponse d'urgence, ce qui en fait un modèle de référence. Cependant, en ce qui concerne l'explication de la question centrale "pourquoi nous avons été hackés", l'attitude du rapport semble quelque peu éluder le sujet.
Le rapport met en évidence l'erreur de vérification de la fonction checked_shlw dans la bibliothèque integer-mate, la qualifiant de "malentendu sémantique". Bien que cette description soit techniquement correcte, elle semble attirer l'attention sur des responsabilités externes, comme si Cetus était également une victime de ce défaut technique.
Cependant, il est intéressant de se demander pourquoi, étant donné qu'integer-mate est une bibliothèque mathématique open source largement utilisée, une vulnérabilité aussi grave est survenue ici chez Cetus ? L'analyse du chemin d'attaque révèle que pour qu'un hacker réussisse son attaque parfaite, il doit remplir simultanément quatre conditions : un contrôle de débordement incorrect, un décalage binaire important, une règle d'arrondi vers le haut et un manque de vérification de la viabilité économique.
Il est surprenant que Cetus ait négligé chaque condition de "déclenchement". Par exemple, le système a accepté des chiffres astronomiques entrés par les utilisateurs, a effectué des opérations de décalage massives extrêmement dangereuses et a totalement fait confiance au mécanisme de vérification des bibliothèques externes. Le plus mortel est que lorsque le système a calculé un résultat absurde de "1 token contre une part exorbitante", il a été exécuté directement sans aucune vérification de bon sens économique.
Ainsi, les véritables questions que Cetus devrait se poser incluent :
Pourquoi utiliser une bibliothèque externe générique sans effectuer de tests de sécurité adéquats ? Bien que la bibliothèque integer-mate possède des caractéristiques telles que l'open source, la popularité et une large utilisation, il semble que Cetus n'ait pas pleinement compris les limites de sécurité de cette bibliothèque lorsqu'il l'a utilisée pour gérer un actif aussi colossal, et n'a pas non plus envisagé de solutions de secours en cas de défaillance de la bibliothèque. Cela reflète un manque de sensibilisation à la sécurité de la chaîne d'approvisionnement chez Cetus.
Pourquoi permettre l'entrée de nombres astronomiques sans établir de limites ? Bien que les protocoles DeFi poursuivent la décentralisation, un système financier mature doit également avoir des limites claires tout en étant ouvert. Permettre l'entrée de chiffres aussi exagérés indique que l'équipe pourrait manquer de talents en gestion des risques ayant 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 ? Cela révèle une erreur de cognition fatale : l'équipe du projet externalise complètement la responsabilité de la sécurité à l'entreprise de sécurité, prenant l'audit comme une carte de décharge. Cependant, les ingénieurs en audit de sécurité sont spécialisés dans la détection des bugs dans le code, mais ils ne penseront peut-être pas à tester le comportement du système dans des conditions extrêmes.
Cette vérification 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 pourraient considérer cela comme un défaut de conception du modèle économique plutôt qu'un problème de logique de code, tandis que les équipes de projet pourraient se plaindre que l'audit n'a pas détecté le problème, et ce sont finalement les utilisateurs qui supportent les pertes.
Cet événement a révélé la lacune systémique en matière de sécurité dans l'industrie DeFi : les équipes ayant un background purement technique manquent souvent d'un "sens du risque financier" de base. D'après le rapport de Cetus, l'équipe semble ne pas avoir pleinement pris conscience de cela.
Pour Cetus et l'ensemble du secteur DeFi, il est important de sortir des limites de la pensée purement technique et de cultiver une véritable conscience des risques de sécurité des "ingénieurs financiers". Il peut être envisagé d'introduire des experts en gestion des risques financiers pour combler les zones d'ignorance de l'équipe technique ; établir un mécanisme d'audit et de révision multipartite, en se concentrant non seulement sur l'audit du code, mais aussi sur l'audit des modèles économiques ; développer un "odorat financier", simuler divers scénarios d'attaque et élaborer des mesures d'atténuation appropriées, et rester extrêmement vigilant face aux opérations anormales.
Avec le développement de l'industrie, les bugs techniques au niveau du code pourraient progressivement diminuer, mais les "bugs de conscience" de la logique métier, où les frontières ne sont pas claires et les responsabilités floues, deviendront le plus grand défi. Les sociétés d'audit peuvent s'assurer qu'il n'y a pas de bugs dans le code, mais comment établir des "logiques avec des frontières" nécessite que l'équipe de projet ait une compréhension plus approfondie de l'essence de l'entreprise et des capacités de contrôle des frontières.
L'avenir de la DeFi appartient à ceux qui ont non seulement une solide expertise technique en code, mais aussi une compréhension approfondie de la logique métier. Seules les équipes qui possèdent ces deux compétences peuvent réellement s'implanter et réussir dans cette industrie pleine de défis.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
20 J'aime
Récompense
20
6
Partager
Commentaire
0/400
GasWhisperer
· 07-17 18:44
les motifs de mempool ne mentent jamais... integer-mate n'était que la Gate, pas la vulnérabilité principale pour être honnête
Voir l'originalRépondre0
DataOnlooker
· 07-17 15:56
Le maître du rejet de responsabilité, ce Cetus.
Voir l'originalRépondre0
ImpermanentLossEnjoyer
· 07-15 05:30
Les pertes peuvent encore être révisées. 香嗷
Voir l'originalRépondre0
DegenApeSurfer
· 07-15 05:30
Celui qui est vivant doit porter le chapeau.
Voir l'originalRépondre0
SatoshiLegend
· 07-15 05:30
Pourquoi les projets DeFi rencontrent-ils souvent ce type d'erreur de dépassement de capacité ? Avant de remonter à la source, il faut d'abord comprendre l'algorithme pow.
Voir l'originalRépondre0
GasOptimizer
· 07-15 05:28
Critiques de la fuite de responsabilité, c'est vraiment une erreur de ne pas avoir vérifié.
Réflexion sur l'incident des hackers de Cetus : la sécurité DeFi doit sortir d'une pensée purement technique
Le protocole Cetus a récemment publié un rapport de rétrospective sur la sécurité concernant un incident de hacking. Ce rapport est assez transparent dans ses détails techniques et sa réponse d'urgence, ce qui en fait un modèle de référence. Cependant, en ce qui concerne l'explication de la question centrale "pourquoi nous avons été hackés", l'attitude du rapport semble quelque peu éluder le sujet.
Le rapport met en évidence l'erreur de vérification de la fonction checked_shlw dans la bibliothèque integer-mate, la qualifiant de "malentendu sémantique". Bien que cette description soit techniquement correcte, elle semble attirer l'attention sur des responsabilités externes, comme si Cetus était également une victime de ce défaut technique.
Cependant, il est intéressant de se demander pourquoi, étant donné qu'integer-mate est une bibliothèque mathématique open source largement utilisée, une vulnérabilité aussi grave est survenue ici chez Cetus ? L'analyse du chemin d'attaque révèle que pour qu'un hacker réussisse son attaque parfaite, il doit remplir simultanément quatre conditions : un contrôle de débordement incorrect, un décalage binaire important, une règle d'arrondi vers le haut et un manque de vérification de la viabilité économique.
Il est surprenant que Cetus ait négligé chaque condition de "déclenchement". Par exemple, le système a accepté des chiffres astronomiques entrés par les utilisateurs, a effectué des opérations de décalage massives extrêmement dangereuses et a totalement fait confiance au mécanisme de vérification des bibliothèques externes. Le plus mortel est que lorsque le système a calculé un résultat absurde de "1 token contre une part exorbitante", il a été exécuté directement sans aucune vérification de bon sens économique.
Ainsi, les véritables questions que Cetus devrait se poser incluent :
Pourquoi utiliser une bibliothèque externe générique sans effectuer de tests de sécurité adéquats ? Bien que la bibliothèque integer-mate possède des caractéristiques telles que l'open source, la popularité et une large utilisation, il semble que Cetus n'ait pas pleinement compris les limites de sécurité de cette bibliothèque lorsqu'il l'a utilisée pour gérer un actif aussi colossal, et n'a pas non plus envisagé de solutions de secours en cas de défaillance de la bibliothèque. Cela reflète un manque de sensibilisation à la sécurité de la chaîne d'approvisionnement chez Cetus.
Pourquoi permettre l'entrée de nombres astronomiques sans établir de limites ? Bien que les protocoles DeFi poursuivent la décentralisation, un système financier mature doit également avoir des limites claires tout en étant ouvert. Permettre l'entrée de chiffres aussi exagérés indique que l'équipe pourrait manquer de talents en gestion des risques ayant 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 ? Cela révèle une erreur de cognition fatale : l'équipe du projet externalise complètement la responsabilité de la sécurité à l'entreprise de sécurité, prenant l'audit comme une carte de décharge. Cependant, les ingénieurs en audit de sécurité sont spécialisés dans la détection des bugs dans le code, mais ils ne penseront peut-être pas à tester le comportement du système dans des conditions extrêmes.
Cette vérification 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 pourraient considérer cela comme un défaut de conception du modèle économique plutôt qu'un problème de logique de code, tandis que les équipes de projet pourraient se plaindre que l'audit n'a pas détecté le problème, et ce sont finalement les utilisateurs qui supportent les pertes.
Cet événement a révélé la lacune systémique en matière de sécurité dans l'industrie DeFi : les équipes ayant un background purement technique manquent souvent d'un "sens du risque financier" de base. D'après le rapport de Cetus, l'équipe semble ne pas avoir pleinement pris conscience de cela.
Pour Cetus et l'ensemble du secteur DeFi, il est important de sortir des limites de la pensée purement technique et de cultiver une véritable conscience des risques de sécurité des "ingénieurs financiers". Il peut être envisagé d'introduire des experts en gestion des risques financiers pour combler les zones d'ignorance de l'équipe technique ; établir un mécanisme d'audit et de révision multipartite, en se concentrant non seulement sur l'audit du code, mais aussi sur l'audit des modèles économiques ; développer un "odorat financier", simuler divers scénarios d'attaque et élaborer des mesures d'atténuation appropriées, et rester extrêmement vigilant face aux opérations anormales.
Avec le développement de l'industrie, les bugs techniques au niveau du code pourraient progressivement diminuer, mais les "bugs de conscience" de la logique métier, où les frontières ne sont pas claires et les responsabilités floues, deviendront le plus grand défi. Les sociétés d'audit peuvent s'assurer qu'il n'y a pas de bugs dans le code, mais comment établir des "logiques avec des frontières" nécessite que l'équipe de projet ait une compréhension plus approfondie de l'essence de l'entreprise et des capacités de contrôle des frontières.
L'avenir de la DeFi appartient à ceux qui ont non seulement une solide expertise technique en code, mais aussi une compréhension approfondie de la logique métier. Seules les équipes qui possèdent ces deux compétences peuvent réellement s'implanter et réussir dans cette industrie pleine de défis.