Depth analyse de la situation difficile de Safe : Guard peut-il reconstruire la tour de Babel des contrats ?
Le 21 février 2025, l'industrie des cryptomonnaies a connu la crise de gestion d'actifs la plus grave de son histoire. Un portefeuille multi-signatures d'une plateforme d'échange a été attaqué de manière ciblée, près de 1,5 milliard de dollars d'actifs ont disparu silencieusement à travers une transaction "signée légalement". Une analyse en chaîne ultérieure a montré que l'attaquant avait obtenu les droits multi-signatures grâce à une attaque d'ingénierie sociale précise, en utilisant la fonction deleGatecall du contrat Safe pour implanter une logique malveillante, contournant finalement le mécanisme de vérification multi-signatures et transférant les fonds vers une adresse anonyme.
Cet événement révèle une réalité brutale : "la multi-signature" n'est pas équivalente à "la sécurité absolue". Même avec des mécanismes de sécurité comme le portefeuille multi-signatures Safe, s'il manque des mesures de protection supplémentaires, il existe toujours un risque d'être compromis. Ce n'est pas non plus le premier cas d'attaque contre un portefeuille multi-signatures Safe. L'année dernière, deux plateformes ont respectivement perdu 230 millions de dollars et 50 millions de dollars, ayant toutes deux subi des attaques similaires. Les incidents d'attaques sur les portefeuilles multi-signatures Safe présentent les caractéristiques techniques suivantes :
Dépendance excessive au mécanisme de signature : transférer toute la responsabilité de sécurité à la gestion de la clé privée.
Défense dynamique manquante : manque de scan de risque en temps réel avant l'exécution des transactions.
Contrôle d'accès grossier : aucune mécanique de liste blanche n'a été établie pour des opérations à haut risque telles que deleGatecall.
La question centrale de cette série d'événements ne réside pas dans le contrat Safe lui-même, mais dans les risques de sécurité lors du processus d'intégration de tout le système, en particulier lors de l'étape de validation en front-end. Cela nous pousse à réfléchir : comment renforcer la capacité de protection des portefeuilles multi-signatures grâce aux mécanismes de mesures de sécurité supplémentaires de Safe ?
Sûr
Safe est un portefeuille Multi-Sig à signatures multiples (, principalement utilisé pour la gestion du stockage et du transfert sécurisé d'actifs de grande valeur et de cryptomonnaies. En tant qu'infrastructure de gestion d'actifs décentralisée, il garantit la sécurité des opérations financières grâce à un mécanisme de validation collaborative à plusieurs parties, empêchant un administrateur unique ou un hacker d'exploiter un point de défaillance unique pour effectuer des opérations malveillantes. Il est largement utilisé dans des scénarios tels que la gouvernance DAO, la gestion de fonds d'entreprise, et les pools de fonds décentralisés. Ce contrat a été développé par l'équipe de Safe et constitue la solution de gestion d'actifs sur chaîne standard de l'industrie actuelle. Le contrat utilise la norme EIP-712 pour réaliser des signatures de données structurées, augmentant ainsi la sécurité et la vérifiabilité des données de transaction.
) Utilisation principale
Gestion de la sécurité des fonds : le contrat exige que plusieurs propriétaires prédéfinis ###Owners( confirment ensemble la transaction avant son exécution, ce qui permet d'éviter efficacement les erreurs ponctuelles ou les manipulations malveillantes, garantissant ainsi la sécurité des fonds.
Exécution et gestion des transactions : Grâce au mécanisme de vérification multi-signatures intégré, le contrat peut exécuter des transferts externes, appeler d'autres contrats ou traiter des logiques commerciales complexes lorsque les conditions de seuil de signature sont remplies, prenant en charge les paiements et les compensations de frais en jetons et en monnaies natives.
Extension modulaire : le contrat adopte une conception modulaire, en intégrant et en combinant plusieurs modules de gestion (comme OwnerManager, ModuleManager, GuardManager, FallbackManager, etc.), ce qui rend ses fonctionnalités flexibles et faciles à étendre, offrant un support personnalisé pour différents scénarios d'application.
) Analyse de fonction
La fonction execTransaction exécute une transaction validée par plusieurs signatures :
Calculer la valeur de hachage unique de la transaction (en combinant les paramètres de la transaction, le nonce, etc.) ;
Vérifier la validité de toutes les signatures, en s'assurant que chaque signature provient d'un propriétaire légitime ou d'une adresse préalablement approuvée ;
Appeler la logique métier de l'adresse cible et enregistrer l'état de succès ou d'échec après l'exécution de la transaction par des événements ;
Support de la gestion flexible des frais de gaz, garantissant un calcul précis des coûts de transaction lors du paiement des compensations.
La fonction checkContractSignatures & checkNSignatures vérifie les données de signature des transactions ou des messages :
Traiter séparément les signatures des comptes EOA, les signatures de contrat ###EIP-1271(, ainsi que les hachages pré-approuvés ;
Assurez-vous que les signatures sont disposées dans l'ordre des propriétaires et que chaque signature provient d'une adresse valide, afin de prévenir les attaques par rejeu et la falsification des signatures.
La fonction getTransactionHash génère un hachage de transaction, utilisé pour la vérification de signature et pour prévenir les attaques par rejeu :
Utiliser la norme EIP-712 pour le hachage structuré des données de transaction ;
Utiliser l'assemblage en ligne pour optimiser les opérations mémoire et améliorer l'efficacité des calculs ;
En combinant la valeur nonce actuelle, assurez-vous de l'unicité de chaque transaction.
La fonction handlePayment gère le paiement de la compensation de gas pendant le processus d'exécution de la transaction :
Calculer le montant à payer en fonction des frais de gas réellement consommés et des frais de base ;
Support des paiements en ETH et autres jetons, garantissant une compensation des frais précise et sans erreur.
onBeforeExecTransaction est une fonction de crochet virtuel interne qui est appelée avant l'exécution de la fonction execTransaction. Le but de cette fonction est de permettre aux sous-contrats héritant du contrat Safe d'effectuer un traitement logique personnalisé avant l'exécution de la transaction. Les paramètres reçus incluent :
à : adresse cible - adresse du contrat ou du compte que la transaction doit appeler
valeur : valeur d'Ethereum - quantité d'Ethereum envoyée avec la transaction
data : Données de charge - Contient les données d'appel avec le sélecteur de fonction et les paramètres.
opération : type d'opération - déterminer s'il s'agit de CALL ou DELEGateCALL
safeTxGas : Limite de gas de transaction - Quantité de gas réservée pour l'exécution de la transaction
baseGas : coût de gas de base - coût de gas indépendant de l'exécution de la transaction
gasPrice : prix du gaz - utilisé pour calculer le prix du gaz pour la compensation des frais de transaction
gasToken : adresse du jeton gas - jeton utilisé pour payer les frais de transaction
refundReceiver : destinataire du remboursement - adresse recevant la compensation des frais de transaction
signatures : ensemble de signatures - données de signature du propriétaire pour la transaction
Bien que les contrats de portefeuille multi-signatures offrent une solution efficace et sécurisée pour la gestion des actifs numériques grâce à leur conception de sécurité rigoureuse et leur structure modulaire flexible, réalisant un contrôle de sécurité complet depuis l'initialisation des transactions jusqu'à l'exécution finale, et devenant un outil important pour la gestion de la sécurité blockchain, il est également important de noter que la plupart des victimes dépendent des portefeuilles matériels pour signer, et que certains appareils matériels ont une mauvaise qualité d'affichage pour la signature de données structurées, ce qui peut amener les utilisateurs à ne pas être en mesure d'identifier avec précision les données de transaction dans un court laps de temps, entraînant ainsi un risque de "signature aveugle". Pour remédier à ce phénomène, en plus d'optimiser le matériel et son affichage de données, il est possible d'explorer l'ajout de confirmations multiples, d'alertes intelligentes et d'outils de vérification de signature améliorés, afin de réduire davantage les risques de sécurité liés à la signature aveugle.
![Depth analyse de la situation de Safe : Guard peut-il reconstruire la tour de Babel des contrats ?])https://img-cdn.gateio.im/webp-social/moments-e4f0b0daf2f48ba716dc7fdddcfdabec.webp(
Safe Guard
La fonctionnalité de sécurité importante introduite dans la version 1.3.0 du contrat Safe - le mécanisme Safe Guard. Ce mécanisme vise à fournir des conditions supplémentaires pour le schéma de signature multiple standard n-out-of-m, renforçant ainsi la sécurité des transactions. La valeur centrale de Safe Guard réside dans sa capacité à effectuer des vérifications de sécurité à différentes étapes de l'exécution des transactions :
Vérifiez avant la transaction )checkTransaction( : Le mécanisme Guard peut effectuer une vérification programmatique de tous les paramètres de la transaction avant son exécution, garantissant que la transaction respecte les règles de sécurité prédéfinies.
Vérifiez )checkAfterExecution( après la transaction : après l'exécution de la transaction, Guard effectuera également une vérification de sécurité supplémentaire pour s'assurer que l'état final du portefeuille Safe après l'exécution de la transaction correspond aux attentes.
) Analyse de l'architecture
Dans Safe, les transactions multi-signatures sont généralement exécutées via la fonction execTransaction. Lorsque Safe Guard est activé, lorsque l'utilisateur exécute une transaction multi-signature, le contrat Safe appelle la fonction checkTransaction du contrat Guard pour effectuer une vérification avant l'exécution de la transaction. Une fois l'exécution de la transaction multi-signature terminée, le contrat Safe appelle la fonction checkAfterExecution du contrat Guard pour vérifier le résultat de l'exécution de la transaction.
Lorsque le contrat Safe exécute une pré-vérification des transactions multi-signatures via le mécanisme Guard, sa fonction checkTransaction recevra l'ensemble des données contextuelles de la transaction, y compris l'adresse du contrat cible, le mode d'appel, les données d'exécution (comme deleGatecall), les informations de signature du propriétaire, la configuration de Gas et les informations de paiement. Ce mécanisme permet aux développeurs de mettre en œuvre des stratégies de gestion des risques multidimensionnelles, telles que la gestion des listes blanches de contrats (restriction des adresses interactives), la gestion des droits d'accès au niveau des fonctions (désactivation des sélecteurs de fonctions à haut risque), la limitation de la fréquence des transactions et des règles dynamiques basées sur le flux de fonds, etc. Grâce à une configuration raisonnable des stratégies Guard, il est possible de bloquer efficacement les attaquants tentant d'exploiter des failles en dehors du niveau contractuel.
Dans le contexte des récents incidents de sécurité, l'attention se porte de plus en plus sur la sécurité des contrats de portefeuilles multi-signatures. Les fournisseurs de portefeuilles matériels appellent à renforcer la capacité d'analyse et de protection des contrats Safe, afin de prévenir la récurrence de risques similaires. Suite à un incident sur une plateforme d'échange, de nombreux projets se sont concentrés sur les contrats Safe et explorent des solutions de mise à niveau et d'expansion basées sur le mécanisme Guard. Parmi eux, il existe des applications innovantes basées sur le mécanisme Guard, construisant une solution de sécurité intermédiaire reposant sur des portefeuilles multi-signatures Safe, offrant une protection supplémentaire entre les actifs sous-jacents et les actifs des utilisateurs. Son rôle central consiste à réaliser un contrôle très granulaire des transactions en passant les contrats cibles, les méthodes d'appel, les données d'exécution, les informations de signature du propriétaire, les informations de paiement et les informations de gaz dans la fonction checkTransaction, y compris le contrôle des permissions pour les appels de contrats sur liste blanche, les opérations de fonctions sur liste blanche, les cibles de transfert sur liste blanche et la fréquence des transactions.
Il est à noter que Safe lui-même ne fournit que des fonctionnalités de gestion et de rappel de Guard, la logique de vérification des transactions multi-signatures étant mise en œuvre par l'utilisateur. Sa sécurité dépend de la qualité de l'implémentation de Guard. Certaines solutions ont élargi cette idée en configurant un Guardian dédié pour chaque Vault, afin de spécifier les adresses cibles et les permissions d'opération autorisées. Cela a permis de réaliser trois grands éléments de contrôle des permissions : spécification des contrats autorisés, définition des opérations de fonction autorisées et exigences de validation ACL. Parallèlement, un mécanisme de gouvernance séparé a été adopté, où le Vault Guardian est responsable de l'exécution, tandis que le Governor contrôle les droits de gouvernance, garantissant que même en cas de problème avec le Guardian, des mesures correctives peuvent être prises rapidement pour protéger les actifs des utilisateurs. Une philosophie de conception similaire a également été appliquée dans les modules de sécurité d'autres projets, en interceptant les opérations critiques et en utilisant un mécanisme de liste blanche pour un contrôle minutieux des opérations à haut risque telles que l'installation de modules, la configuration de hooks et la gestion des validateurs, garantissant ainsi que seuls les contrats de confiance peuvent être ajoutés au système, offrant une protection de sécurité durable au portefeuille.
Dans une chaîne d'attaque d'événements sur une plateforme de trading, si le contrat Safe a déployé un mécanisme de Guard correctement configuré, les appels deleGatecall malveillants lancés par l'attaquant via execTransaction seront interceptés en plusieurs étapes lors de la phase de pré-vérification : la fonction checkTransaction de Guard identifie d'abord le type d'opération deleGatecall et déclenche les règles de désactivation (comme limiter strictement l'opération à des appels ordinaires), puis analyse le champ data pour détecter des adresses de contrats non conventionnels et des sélecteurs de fonctions à haut risque. Grâce aux stratégies de liste blanche de contrats prédéfinies et de listes noires de fonctions, la transaction est directement annulée, formant finalement un système de défense de « interception de stratégie → blocage logique », bloquant complètement la voie de la manipulation de stockage et du transfert de fonds.
![Depth Analyse de la situation difficile de Safe : Guard peut-il reconstruire la tour de Babel des contrats ?]###https://img-cdn.gateio.im/webp-social/moments-4947f64f2aa4163ee644b6f8e911c6f8.webp(
En résumé, Safe n'a proposé la fonctionnalité Guard qu'après la version 1.3.0. Bien que Guard puisse fournir un contrôle des transactions multi-signatures extrêmement granulaire, les utilisateurs rencontrent une barrière élevée lors de l'utilisation de cette fonctionnalité. Ils doivent mettre en œuvre eux-mêmes la logique de vérification de Guard, et une mise en œuvre approximative ou défectueuse de Guard peut ne pas aider les utilisateurs à améliorer la sécurité de leur portefeuille Safe. Par conséquent, il est nécessaire d'effectuer un audit de sécurité sur l'implémentation de Guard. Il ne fait aucun doute qu'une mise en œuvre de Guard sécurisée et appropriée peut considérablement améliorer la sécurité du portefeuille Safe.
Conclusion et perspectives
Un incident d'attaque sur une plateforme d'échange a mis en évidence l'importance de mettre à jour rapidement les infrastructures de sécurité. La plateforme utilisait la version v1.1.1 (<1.3.0) du contrat Safe, ce qui signifie qu'elle ne pouvait pas utiliser le mécanisme Guard, une caractéristique de sécurité clé. Si la plateforme avait mis à niveau vers la version 1.3.0 ou une version ultérieure du contrat Safe et mis en place un mécanisme Guard approprié, tel que spécifier une adresse de liste blanche unique pour recevoir des fonds et effectuer une validation stricte des ACL des fonctions de contrat, elle aurait pu éviter cette perte. Bien que cela ne soit qu'une hypothèse, cela fournit des idées importantes pour la gestion de la sécurité des actifs à l'avenir.
Le mécanisme Safe Guard ressemble à un système de sécurité intelligent installé sur un coffre-fort d'actifs numériques, dont l'efficacité dépend de la rigueur de la conception des règles et de la qualité de l'exécution. Face à des méthodes d'attaque de plus en plus sophistiquées, nous devons :
Validation automatisée : établir un mécanisme de validation des transactions automatisé
Ajustement dynamique des stratégies : ajustement en temps réel des stratégies de sécurité en fonction des renseignements sur les menaces
Défense multicouche : construction d'un système de défense en profondeur en combinant divers mécanismes de sécurité
Audit continu : réalisation d'audits de sécurité réguliers sur Guard
La gestion des actifs numériques à l'avenir sera une combinaison intelligente
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.
8 J'aime
Récompense
8
4
Partager
Commentaire
0/400
MetaverseLandlord
· 07-09 09:40
Safe a encore été piraté ? Je ne comprends pas.
Voir l'originalRépondre0
MEVictim
· 07-09 09:39
Eh, ce safe n'est qu'une blague.
Voir l'originalRépondre0
MechanicalMartel
· 07-09 09:39
Encore un smart contracts qui fait des vagues🤔
Voir l'originalRépondre0
SchrodingerWallet
· 07-09 09:26
Prendre les gens pour des idiots depuis quelques années, et ça continue à être du n'importe quoi.
Mécanisme Safe Guard : Nouvelle direction pour reconstruire l'architecture de sécurité du Portefeuille à signatures multiples
Depth analyse de la situation difficile de Safe : Guard peut-il reconstruire la tour de Babel des contrats ?
Le 21 février 2025, l'industrie des cryptomonnaies a connu la crise de gestion d'actifs la plus grave de son histoire. Un portefeuille multi-signatures d'une plateforme d'échange a été attaqué de manière ciblée, près de 1,5 milliard de dollars d'actifs ont disparu silencieusement à travers une transaction "signée légalement". Une analyse en chaîne ultérieure a montré que l'attaquant avait obtenu les droits multi-signatures grâce à une attaque d'ingénierie sociale précise, en utilisant la fonction deleGatecall du contrat Safe pour implanter une logique malveillante, contournant finalement le mécanisme de vérification multi-signatures et transférant les fonds vers une adresse anonyme.
Cet événement révèle une réalité brutale : "la multi-signature" n'est pas équivalente à "la sécurité absolue". Même avec des mécanismes de sécurité comme le portefeuille multi-signatures Safe, s'il manque des mesures de protection supplémentaires, il existe toujours un risque d'être compromis. Ce n'est pas non plus le premier cas d'attaque contre un portefeuille multi-signatures Safe. L'année dernière, deux plateformes ont respectivement perdu 230 millions de dollars et 50 millions de dollars, ayant toutes deux subi des attaques similaires. Les incidents d'attaques sur les portefeuilles multi-signatures Safe présentent les caractéristiques techniques suivantes :
La question centrale de cette série d'événements ne réside pas dans le contrat Safe lui-même, mais dans les risques de sécurité lors du processus d'intégration de tout le système, en particulier lors de l'étape de validation en front-end. Cela nous pousse à réfléchir : comment renforcer la capacité de protection des portefeuilles multi-signatures grâce aux mécanismes de mesures de sécurité supplémentaires de Safe ?
Sûr
Safe est un portefeuille Multi-Sig à signatures multiples (, principalement utilisé pour la gestion du stockage et du transfert sécurisé d'actifs de grande valeur et de cryptomonnaies. En tant qu'infrastructure de gestion d'actifs décentralisée, il garantit la sécurité des opérations financières grâce à un mécanisme de validation collaborative à plusieurs parties, empêchant un administrateur unique ou un hacker d'exploiter un point de défaillance unique pour effectuer des opérations malveillantes. Il est largement utilisé dans des scénarios tels que la gouvernance DAO, la gestion de fonds d'entreprise, et les pools de fonds décentralisés. Ce contrat a été développé par l'équipe de Safe et constitue la solution de gestion d'actifs sur chaîne standard de l'industrie actuelle. Le contrat utilise la norme EIP-712 pour réaliser des signatures de données structurées, augmentant ainsi la sécurité et la vérifiabilité des données de transaction.
) Utilisation principale
) Analyse de fonction
La fonction execTransaction exécute une transaction validée par plusieurs signatures :
La fonction checkContractSignatures & checkNSignatures vérifie les données de signature des transactions ou des messages :
La fonction getTransactionHash génère un hachage de transaction, utilisé pour la vérification de signature et pour prévenir les attaques par rejeu :
La fonction handlePayment gère le paiement de la compensation de gas pendant le processus d'exécution de la transaction :
onBeforeExecTransaction est une fonction de crochet virtuel interne qui est appelée avant l'exécution de la fonction execTransaction. Le but de cette fonction est de permettre aux sous-contrats héritant du contrat Safe d'effectuer un traitement logique personnalisé avant l'exécution de la transaction. Les paramètres reçus incluent :
Bien que les contrats de portefeuille multi-signatures offrent une solution efficace et sécurisée pour la gestion des actifs numériques grâce à leur conception de sécurité rigoureuse et leur structure modulaire flexible, réalisant un contrôle de sécurité complet depuis l'initialisation des transactions jusqu'à l'exécution finale, et devenant un outil important pour la gestion de la sécurité blockchain, il est également important de noter que la plupart des victimes dépendent des portefeuilles matériels pour signer, et que certains appareils matériels ont une mauvaise qualité d'affichage pour la signature de données structurées, ce qui peut amener les utilisateurs à ne pas être en mesure d'identifier avec précision les données de transaction dans un court laps de temps, entraînant ainsi un risque de "signature aveugle". Pour remédier à ce phénomène, en plus d'optimiser le matériel et son affichage de données, il est possible d'explorer l'ajout de confirmations multiples, d'alertes intelligentes et d'outils de vérification de signature améliorés, afin de réduire davantage les risques de sécurité liés à la signature aveugle.
![Depth analyse de la situation de Safe : Guard peut-il reconstruire la tour de Babel des contrats ?])https://img-cdn.gateio.im/webp-social/moments-e4f0b0daf2f48ba716dc7fdddcfdabec.webp(
Safe Guard
La fonctionnalité de sécurité importante introduite dans la version 1.3.0 du contrat Safe - le mécanisme Safe Guard. Ce mécanisme vise à fournir des conditions supplémentaires pour le schéma de signature multiple standard n-out-of-m, renforçant ainsi la sécurité des transactions. La valeur centrale de Safe Guard réside dans sa capacité à effectuer des vérifications de sécurité à différentes étapes de l'exécution des transactions :
) Analyse de l'architecture
Dans Safe, les transactions multi-signatures sont généralement exécutées via la fonction execTransaction. Lorsque Safe Guard est activé, lorsque l'utilisateur exécute une transaction multi-signature, le contrat Safe appelle la fonction checkTransaction du contrat Guard pour effectuer une vérification avant l'exécution de la transaction. Une fois l'exécution de la transaction multi-signature terminée, le contrat Safe appelle la fonction checkAfterExecution du contrat Guard pour vérifier le résultat de l'exécution de la transaction.
Lorsque le contrat Safe exécute une pré-vérification des transactions multi-signatures via le mécanisme Guard, sa fonction checkTransaction recevra l'ensemble des données contextuelles de la transaction, y compris l'adresse du contrat cible, le mode d'appel, les données d'exécution (comme deleGatecall), les informations de signature du propriétaire, la configuration de Gas et les informations de paiement. Ce mécanisme permet aux développeurs de mettre en œuvre des stratégies de gestion des risques multidimensionnelles, telles que la gestion des listes blanches de contrats (restriction des adresses interactives), la gestion des droits d'accès au niveau des fonctions (désactivation des sélecteurs de fonctions à haut risque), la limitation de la fréquence des transactions et des règles dynamiques basées sur le flux de fonds, etc. Grâce à une configuration raisonnable des stratégies Guard, il est possible de bloquer efficacement les attaquants tentant d'exploiter des failles en dehors du niveau contractuel.
Dans le contexte des récents incidents de sécurité, l'attention se porte de plus en plus sur la sécurité des contrats de portefeuilles multi-signatures. Les fournisseurs de portefeuilles matériels appellent à renforcer la capacité d'analyse et de protection des contrats Safe, afin de prévenir la récurrence de risques similaires. Suite à un incident sur une plateforme d'échange, de nombreux projets se sont concentrés sur les contrats Safe et explorent des solutions de mise à niveau et d'expansion basées sur le mécanisme Guard. Parmi eux, il existe des applications innovantes basées sur le mécanisme Guard, construisant une solution de sécurité intermédiaire reposant sur des portefeuilles multi-signatures Safe, offrant une protection supplémentaire entre les actifs sous-jacents et les actifs des utilisateurs. Son rôle central consiste à réaliser un contrôle très granulaire des transactions en passant les contrats cibles, les méthodes d'appel, les données d'exécution, les informations de signature du propriétaire, les informations de paiement et les informations de gaz dans la fonction checkTransaction, y compris le contrôle des permissions pour les appels de contrats sur liste blanche, les opérations de fonctions sur liste blanche, les cibles de transfert sur liste blanche et la fréquence des transactions.
Il est à noter que Safe lui-même ne fournit que des fonctionnalités de gestion et de rappel de Guard, la logique de vérification des transactions multi-signatures étant mise en œuvre par l'utilisateur. Sa sécurité dépend de la qualité de l'implémentation de Guard. Certaines solutions ont élargi cette idée en configurant un Guardian dédié pour chaque Vault, afin de spécifier les adresses cibles et les permissions d'opération autorisées. Cela a permis de réaliser trois grands éléments de contrôle des permissions : spécification des contrats autorisés, définition des opérations de fonction autorisées et exigences de validation ACL. Parallèlement, un mécanisme de gouvernance séparé a été adopté, où le Vault Guardian est responsable de l'exécution, tandis que le Governor contrôle les droits de gouvernance, garantissant que même en cas de problème avec le Guardian, des mesures correctives peuvent être prises rapidement pour protéger les actifs des utilisateurs. Une philosophie de conception similaire a également été appliquée dans les modules de sécurité d'autres projets, en interceptant les opérations critiques et en utilisant un mécanisme de liste blanche pour un contrôle minutieux des opérations à haut risque telles que l'installation de modules, la configuration de hooks et la gestion des validateurs, garantissant ainsi que seuls les contrats de confiance peuvent être ajoutés au système, offrant une protection de sécurité durable au portefeuille.
Dans une chaîne d'attaque d'événements sur une plateforme de trading, si le contrat Safe a déployé un mécanisme de Guard correctement configuré, les appels deleGatecall malveillants lancés par l'attaquant via execTransaction seront interceptés en plusieurs étapes lors de la phase de pré-vérification : la fonction checkTransaction de Guard identifie d'abord le type d'opération deleGatecall et déclenche les règles de désactivation (comme limiter strictement l'opération à des appels ordinaires), puis analyse le champ data pour détecter des adresses de contrats non conventionnels et des sélecteurs de fonctions à haut risque. Grâce aux stratégies de liste blanche de contrats prédéfinies et de listes noires de fonctions, la transaction est directement annulée, formant finalement un système de défense de « interception de stratégie → blocage logique », bloquant complètement la voie de la manipulation de stockage et du transfert de fonds.
![Depth Analyse de la situation difficile de Safe : Guard peut-il reconstruire la tour de Babel des contrats ?]###https://img-cdn.gateio.im/webp-social/moments-4947f64f2aa4163ee644b6f8e911c6f8.webp(
En résumé, Safe n'a proposé la fonctionnalité Guard qu'après la version 1.3.0. Bien que Guard puisse fournir un contrôle des transactions multi-signatures extrêmement granulaire, les utilisateurs rencontrent une barrière élevée lors de l'utilisation de cette fonctionnalité. Ils doivent mettre en œuvre eux-mêmes la logique de vérification de Guard, et une mise en œuvre approximative ou défectueuse de Guard peut ne pas aider les utilisateurs à améliorer la sécurité de leur portefeuille Safe. Par conséquent, il est nécessaire d'effectuer un audit de sécurité sur l'implémentation de Guard. Il ne fait aucun doute qu'une mise en œuvre de Guard sécurisée et appropriée peut considérablement améliorer la sécurité du portefeuille Safe.
Conclusion et perspectives
Un incident d'attaque sur une plateforme d'échange a mis en évidence l'importance de mettre à jour rapidement les infrastructures de sécurité. La plateforme utilisait la version v1.1.1 (<1.3.0) du contrat Safe, ce qui signifie qu'elle ne pouvait pas utiliser le mécanisme Guard, une caractéristique de sécurité clé. Si la plateforme avait mis à niveau vers la version 1.3.0 ou une version ultérieure du contrat Safe et mis en place un mécanisme Guard approprié, tel que spécifier une adresse de liste blanche unique pour recevoir des fonds et effectuer une validation stricte des ACL des fonctions de contrat, elle aurait pu éviter cette perte. Bien que cela ne soit qu'une hypothèse, cela fournit des idées importantes pour la gestion de la sécurité des actifs à l'avenir.
Le mécanisme Safe Guard ressemble à un système de sécurité intelligent installé sur un coffre-fort d'actifs numériques, dont l'efficacité dépend de la rigueur de la conception des règles et de la qualité de l'exécution. Face à des méthodes d'attaque de plus en plus sophistiquées, nous devons :
La gestion des actifs numériques à l'avenir sera une combinaison intelligente