Le protocole Cetus a été piraté, révélant les faiblesses en matière de sécurité de la Finance décentralisée : un écart urgent à combler entre la technologie et la finance.
Réflexions et enseignements sur l'incident d'attaque de hacker du protocole Cetus
Un protocole a récemment publié un rapport de sécurité sur une attaque de Hacker intitulé "retour d'expérience". Le rapport est assez transparent dans la divulgation des détails techniques et de la réponse d'urgence, pouvant être qualifié de niveau manuel. Cependant, en répondant à la question centrale "pourquoi a-t-on été hacké", le rapport semble un peu éluder le sujet.
Le rapport explique en détail l'erreur de vérification de la fonction checked_shlw dans la bibliothèque integer-mate (devrait être ≤2^192, en réalité ≤2^256) et la qualifie de "malentendu sémantique". Bien que cette description soit techniquement irréprochable, elle déplace habilement le focus sur la responsabilité externe, laissant entendre que le protocole lui-même est également une victime innocente de ce défaut technique.
Cependant, il est intéressant de réfléchir : puisque integer-mate est une bibliothèque mathématique open-source largement utilisée, pourquoi une erreur aussi absurde est-elle survenue dans ce protocole, permettant d'obtenir une part de liquidité exorbitante avec seulement 1 jeton ?
L'analyse des chemins d'attaque des hackers révèle que pour réussir une attaque, quatre conditions doivent être simultanément remplies : un contrôle de débordement défectueux, des opérations de décalage massif, des règles d'arrondi et un manque de vérification de la rationalité économique. À la surprise générale, le protocole a montré des "négligences" sur chaque condition de "déclenchement" : accepter des entrées utilisateur telles que 2^200, effectuer des opérations de décalage massif extrêmement dangereuses, et faire totalement confiance aux mécanismes de vérification des bibliothèques externes. Le plus mortel est que lorsque le système a calculé un résultat manifestement irrationnel tel que "1 token contre une part exorbitante", il a été exécuté directement sans aucun contrôle de bon sens économique.
Donc, les véritables questions qui nécessitent une réflexion sur ce protocole incluent :
Pourquoi n'y a-t-il pas eu de tests de sécurité suffisants lors de l'adoption de bibliothèques externes générales ? Bien que la bibliothèque integer-mate possède des caractéristiques telles que l'open source, la popularité et une large utilisation, il est clair que le protocole manque d'une compréhension approfondie des limites de sécurité de cette bibliothèque lorsqu'il s'agit de gérer des actifs d'une valeur de plusieurs millions de dollars, ainsi que des alternatives en cas de défaillance des fonctionnalités de la bibliothèque. Cela met en évidence le manque de sensibilisation du protocole à la sécurité de la chaîne d'approvisionnement.
Pourquoi autoriser l'entrée de nombres astronomiques sans définir de limites raisonnables ? Bien que les protocoles de finance décentralisée visent l'ouverture, un système financier mature nécessite des limites claires. Autoriser l'entrée de valeurs aussi exagérées montre que l'équipe manque 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étectés à l'avance ? Cela reflète une erreur de perception fatale : l'équipe du projet externalise entièrement la responsabilité de la sécurité aux entreprises de sécurité, considérant l'audit comme une carte d'immunité. Cependant, les ingénieurs en audit de sécurité sont principalement spécialisés dans la détection des vulnérabilités dans le code et prennent rarement en compte les problèmes qui pourraient survenir lorsque le système de test calcule des ratios d'échange extrêmement déraisonnables.
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 point aveugle dans le domaine de la sécurité des finances décentralisées modernes. Les sociétés d'audit peuvent considérer cela comme un défaut de conception du modèle économique plutôt que comme un problème de logique de code ; les équipes de projet peuvent se plaindre que l'audit n'a pas détecté le problème ; et finalement, ce sont les actifs des utilisateurs qui en souffrent.
Cet événement a révélé les lacunes systémiques en matière de sécurité dans l'industrie de la finance décentralisée : les équipes ayant un profil purement technique manquent souvent d'un "odorat du risque financier".
D'après le rapport de ce protocole, l'équipe semble ne pas avoir pleinement réalisé cela. Au lieu de se concentrer uniquement sur les défauts techniques de cette attaque de hacker, toutes les équipes de finance décentralisée devraient transcender les limites de la pensée purement technique et vraiment cultiver la conscience des risques de sécurité des "ingénieurs financiers".
Les mesures spécifiques peuvent inclure : l'introduction d'experts en gestion des risques financiers pour combler les lacunes de connaissances de l'équipe technique ; l'établissement d'un mécanisme d'audit et de révision multilatéral, qui ne se concentre pas seulement sur l'audit des codes, mais accorde également une importance à l'audit des modèles économiques ; le développement d'un "odorat financier", la simulation de divers scénarios d'attaque et des mesures de réponse appropriées, et le maintien d'une vigilance élevée face aux opérations anormales.
Cela fait penser au consensus des professionnels de la sécurité : à mesure que l'industrie mûrit, les vulnérabilités techniques au niveau du code pur vont progressivement diminuer, tandis que les "vulnérabilités de conscience" liées à la logique métier, qui sont floues et aux responsabilités mal définies, deviendront le plus grand défi.
Les sociétés d'audit peuvent s'assurer que le code ne contient pas de vulnérabilités, mais la manière de réaliser "la logique a des limites" nécessite que l'équipe du projet ait une compréhension plus approfondie de la nature des affaires et des capacités de contrôle des limites. Cela explique également pourquoi de nombreux projets ayant subi un audit de sécurité continuent d'être victimes d'attaques de hackers.
L'avenir de la finance décentralisée appartiendra sans aucun doute à des équipes qui non seulement maîtrisent la technologie du code, mais qui comprennent également profondément la logique commerciale !
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.
11 J'aime
Récompense
11
3
Partager
Commentaire
0/400
ShibaSunglasses
· 07-25 08:46
Vraiment un maître du rejet de responsabilité.
Voir l'originalRépondre0
AirdropHunterWang
· 07-23 02:57
Encore se faire prendre pour des cons, prêt à Rug Pull
Le protocole Cetus a été piraté, révélant les faiblesses en matière de sécurité de la Finance décentralisée : un écart urgent à combler entre la technologie et la finance.
Réflexions et enseignements sur l'incident d'attaque de hacker du protocole Cetus
Un protocole a récemment publié un rapport de sécurité sur une attaque de Hacker intitulé "retour d'expérience". Le rapport est assez transparent dans la divulgation des détails techniques et de la réponse d'urgence, pouvant être qualifié de niveau manuel. Cependant, en répondant à la question centrale "pourquoi a-t-on été hacké", le rapport semble un peu éluder le sujet.
Le rapport explique en détail l'erreur de vérification de la fonction checked_shlw dans la bibliothèque integer-mate (devrait être ≤2^192, en réalité ≤2^256) et la qualifie de "malentendu sémantique". Bien que cette description soit techniquement irréprochable, elle déplace habilement le focus sur la responsabilité externe, laissant entendre que le protocole lui-même est également une victime innocente de ce défaut technique.
Cependant, il est intéressant de réfléchir : puisque integer-mate est une bibliothèque mathématique open-source largement utilisée, pourquoi une erreur aussi absurde est-elle survenue dans ce protocole, permettant d'obtenir une part de liquidité exorbitante avec seulement 1 jeton ?
L'analyse des chemins d'attaque des hackers révèle que pour réussir une attaque, quatre conditions doivent être simultanément remplies : un contrôle de débordement défectueux, des opérations de décalage massif, des règles d'arrondi et un manque de vérification de la rationalité économique. À la surprise générale, le protocole a montré des "négligences" sur chaque condition de "déclenchement" : accepter des entrées utilisateur telles que 2^200, effectuer des opérations de décalage massif extrêmement dangereuses, et faire totalement confiance aux mécanismes de vérification des bibliothèques externes. Le plus mortel est que lorsque le système a calculé un résultat manifestement irrationnel tel que "1 token contre une part exorbitante", il a été exécuté directement sans aucun contrôle de bon sens économique.
Donc, les véritables questions qui nécessitent une réflexion sur ce protocole incluent :
Pourquoi n'y a-t-il pas eu de tests de sécurité suffisants lors de l'adoption de bibliothèques externes générales ? Bien que la bibliothèque integer-mate possède des caractéristiques telles que l'open source, la popularité et une large utilisation, il est clair que le protocole manque d'une compréhension approfondie des limites de sécurité de cette bibliothèque lorsqu'il s'agit de gérer des actifs d'une valeur de plusieurs millions de dollars, ainsi que des alternatives en cas de défaillance des fonctionnalités de la bibliothèque. Cela met en évidence le manque de sensibilisation du protocole à la sécurité de la chaîne d'approvisionnement.
Pourquoi autoriser l'entrée de nombres astronomiques sans définir de limites raisonnables ? Bien que les protocoles de finance décentralisée visent l'ouverture, un système financier mature nécessite des limites claires. Autoriser l'entrée de valeurs aussi exagérées montre que l'équipe manque 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étectés à l'avance ? Cela reflète une erreur de perception fatale : l'équipe du projet externalise entièrement la responsabilité de la sécurité aux entreprises de sécurité, considérant l'audit comme une carte d'immunité. Cependant, les ingénieurs en audit de sécurité sont principalement spécialisés dans la détection des vulnérabilités dans le code et prennent rarement en compte les problèmes qui pourraient survenir lorsque le système de test calcule des ratios d'échange extrêmement déraisonnables.
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 point aveugle dans le domaine de la sécurité des finances décentralisées modernes. Les sociétés d'audit peuvent considérer cela comme un défaut de conception du modèle économique plutôt que comme un problème de logique de code ; les équipes de projet peuvent se plaindre que l'audit n'a pas détecté le problème ; et finalement, ce sont les actifs des utilisateurs qui en souffrent.
Cet événement a révélé les lacunes systémiques en matière de sécurité dans l'industrie de la finance décentralisée : les équipes ayant un profil purement technique manquent souvent d'un "odorat du risque financier".
D'après le rapport de ce protocole, l'équipe semble ne pas avoir pleinement réalisé cela. Au lieu de se concentrer uniquement sur les défauts techniques de cette attaque de hacker, toutes les équipes de finance décentralisée devraient transcender les limites de la pensée purement technique et vraiment cultiver la conscience des risques de sécurité des "ingénieurs financiers".
Les mesures spécifiques peuvent inclure : l'introduction d'experts en gestion des risques financiers pour combler les lacunes de connaissances de l'équipe technique ; l'établissement d'un mécanisme d'audit et de révision multilatéral, qui ne se concentre pas seulement sur l'audit des codes, mais accorde également une importance à l'audit des modèles économiques ; le développement d'un "odorat financier", la simulation de divers scénarios d'attaque et des mesures de réponse appropriées, et le maintien d'une vigilance élevée face aux opérations anormales.
Cela fait penser au consensus des professionnels de la sécurité : à mesure que l'industrie mûrit, les vulnérabilités techniques au niveau du code pur vont progressivement diminuer, tandis que les "vulnérabilités de conscience" liées à la logique métier, qui sont floues et aux responsabilités mal définies, deviendront le plus grand défi.
Les sociétés d'audit peuvent s'assurer que le code ne contient pas de vulnérabilités, mais la manière de réaliser "la logique a des limites" nécessite que l'équipe du projet ait une compréhension plus approfondie de la nature des affaires et des capacités de contrôle des limites. Cela explique également pourquoi de nombreux projets ayant subi un audit de sécurité continuent d'être victimes d'attaques de hackers.
L'avenir de la finance décentralisée appartiendra sans aucun doute à des équipes qui non seulement maîtrisent la technologie du code, mais qui comprennent également profondément la logique commerciale !