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 de la cryptomonnaie a connu la crise de gestion d'actifs la plus grave de son histoire. Le portefeuille multi-signatures on-chain d'une plateforme d'échange a été ciblé et compromis, entraînant la perte silencieuse de près de 1,5 milliard de dollars d'actifs par le biais d'une transaction "signée légalement". L'analyse on-chain ultérieure a montré que l'attaquant avait obtenu les droits multi-signatures grâce à une attaque d'ingénierie sociale sophistiquée, exploitant 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 incident révèle une réalité cruelle : « la signature multiple » n'égale pas « la sécurité absolue ». Même un mécanisme de sécurité comme le portefeuille multi-signatures Safe, s'il manque de mesures de protection supplémentaires, reste vulnérable aux attaques. Ce n'est pas non plus le premier cas d'attaque contre un portefeuille multi-signatures Safe. L'année dernière, deux échanges bien connus ont respectivement perdu 230 millions de dollars et 50 millions de dollars, ayant tous deux subi des méthodes d'attaque similaires. Les incidents d'attaque contre les portefeuilles multi-signatures Safe présentent la même parenté technique :

• Dépendance excessive au mécanisme de signature : confier toute la responsabilité de la sécurité à la garde de la clé privée.
• Défense dynamique manquante : absence de scan de risque en temps réel avant l'exécution des transactions.
• Contrôle d'accès en gros : Pas de mécanisme de liste blanche établi pour des opérations à haut risque telles que deleGatecall.

Le problème central 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 l'ensemble du système, en particulier au niveau de la validation frontale. Cela nous pousse à réfléchir : comment renforcer la capacité de protection des portefeuilles multisignatures grâce aux mécanismes de mesures de sécurité supplémentaires de Safe ?

Sûr

Safe est un portefeuille multi-signatures ( Multi-Sig ), principalement utilisé pour la gestion de la sécurité des actifs de grande valeur et le stockage et le transfert de cryptomonnaies. En tant qu'infrastructure de gestion d'actifs décentralisée, il assure la sécurité des opérations de fonds grâce à un mécanisme de validation collaborative, empêchant un administrateur unique ou un hacker d'exploiter un point de défaillance unique pour des opérations malveillantes, et est largement utilisé dans la gouvernance DAO, la fiducie des fonds d'entreprise, les pools de fonds décentralisés, etc. Ce contrat a été développé par l'équipe de Safe (anciennement Gnosis Safe) et est la solution de gestion d'actifs en chaîne standard du secteur. 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éétablis (Owners) confirment ensemble la transaction avant qu'elle ne soit exécutée, ce qui permet d'éviter efficacement les erreurs uniques ou les manipulations malveillantes, garantissant ainsi la sécurité des fonds.
• Exécution et gestion des transactions : Grâce à un mécanisme de validation multisignature intégré, le contrat peut exécuter des transferts externes, appeler d'autres contrats ou traiter des logiques commerciales complexes, à condition de respecter les conditions de seuil de signature, en prenant en charge les paiements et les compensations de frais pour les tokens et les monnaies natives.
• Extension modulaire : Le contrat adopte une conception modulaire, permettant l'héritage et la combinaison de plusieurs modules de gestion (tels que OwnerManager, ModuleManager, GuardManager, FallbackManager, etc.), rendant ses fonctionnalités flexibles et faciles à étendre, offrant un support personnalisé pour différents scénarios d'application.

Analyse de la 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érifiez la validité de toutes les signatures, en vous assurant que chaque signature provient d'un propriétaire légitime ou d'une adresse pré-approuvée ;
• Appeler la logique métier de l'adresse cible et enregistrer l'état de réussite ou d'échec par le biais d'événements après l'exécution de la transaction ;
• Prise en charge d'un traitement 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 de comptes EOA, les signatures de contrats ( EIP-1271), ainsi que les hachages pré-approuvés ;
• Assurez-vous que les signatures sont ordonnées selon 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 la prévention des 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é de calcul.
• Combinez la valeur nonce actuelle pour garantir l'unicité de chaque transaction.

La fonction handlePayment gère le paiement de compensation de gas pendant le processus d'exécution des transactions :

• Montant à payer calculé en fonction des frais de gas réels et des frais de base ;
• Support des paiements en ETH et autres tokens, 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 de traiter des logiques personnalisées avant l'exécution de la transaction. Les paramètres reçus comprennent :

• à : adresse cible - l'adresse du contrat ou du compte à appeler pour la transaction
• valeur : valeur de l'Ethereum - quantité d'Ethereum envoyée avec la transaction
• data : charge utile des données - contient le sélecteur de fonction et les données d'appel des paramètres
• operation : Type d'opération - Déterminer s'il s'agit de CALL ou DELEGateCALL
• safeTxGas : limite de gaz de transaction - quantité de gaz 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 de gaz - jeton utilisé pour payer les frais de transaction
• refundReceiver : le destinataire du remboursement - l'adresse qui reçoit la compensation des frais de transaction
• signatures : ensemble des 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 du processus de l'initialisation de la transaction à 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 la signature, et que certains appareils matériels affichent mal les signatures de données structurées, ce qui peut rendre difficile pour les utilisateurs de reconnaître précisément 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 des données, il est également possible d'explorer l'ajout de confirmations multiples, d'alertes intelligentes et d'outils de vérification des signatures renforcés, afin de réduire davantage les risques de sécurité associés à la signature aveugle.

Safe Guard

La fonction 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 de restriction supplémentaires pour le schéma de multi-signature standard n-out-of-m, renforçant ainsi la sécurité des transactions. La valeur fondamentale de Safe Guard réside dans sa capacité à effectuer des contrôles de sécurité à différentes étapes de l'exécution des transactions :

• Vérification 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 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 est conforme aux attentes.

Analyse de l'architecture

Dans Safe, les transactions multi-signatures sont généralement exécutées via la fonction execTransaction. Lorsque la fonction Safe Guard est activée, 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 la transaction multi-signature exécuté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 un précontrôle de transaction multi-signatures via le mécanisme Guard, sa fonction checkTransaction recevra des données complètes sur le contexte 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 le contrôle de la liste blanche des contrats (restriction des adresses interactives), la gestion des autorisations 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. En configurant raisonnablement les stratégies Guard, il est possible de bloquer efficacement les attaquants utilisant des attaques en dehors du niveau du contrat.

Dans le contexte des récents événements de sécurité, les parties prenantes accordent de plus en plus d'attention à la sécurité des contrats de portefeuille multi-signatures. Les fournisseurs de portefeuilles matériels appellent à renforcer les capacités d'analyse et de protection des contrats Safe afin de prévenir la récurrence de risques similaires. Après l'incident sur une plateforme d'échange, de nombreux projets ont commencé à se concentrer sur les contrats Safe et à explorer 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é de couche intermédiaire reposant sur un portefeuille multi-signatures Safe, offrant une protection de sécurité supplémentaire entre les actifs sous-jacents et les actifs des utilisateurs. Son rôle principal est d'effectuer un contrôle très granulaire des transactions en transmettant à la fonction checkTransaction les contrats cibles impliqués dans les transactions multi-signatures Safe, 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, y compris le contrôle d'accès pour les appels de contrats de la liste blanche, les opérations de fonctions de la liste blanche, les cibles de transfert de la liste blanche, et la fréquence des transactions.

Il est à noter que Safe 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 lui-même, sa sécurité dépendant de la qualité de l'implémentation de Guard. Par exemple, une certaine solution de sécurité a élargi cette idée en configurant un Guardian spécialisé pour chaque Vault afin de spécifier les adresses cibles et les autorisations d'opération autorisées, réalisant ainsi trois éléments de contrôle des autorisations : spécifier les contrats autorisés, définir les fonctions autorisées et répondre aux besoins de validation ACL. De plus, un mécanisme de gouvernance séparé est 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 est également appliquée dans un autre module de sécurité, qui intercepte les opérations clés via la fonction preExecute et utilise un mécanisme de liste blanche pour contrôler de manière précise les 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 ainsi une sécurité durable au portefeuille.

Dans une chaîne d'attaque d'événements sur une plateforme d'échange, si le contrat Safe a déployé un mécanisme de Gardien configuré de manière raisonnable, les appels deleGatecall malveillants initiés par l'attaquant via execTransaction seront interceptés à l'étape de pré-vérification par plusieurs stratégies : la fonction checkTransaction du Gardien identifie d'abord le type d'opération deleGatecall et déclenche des règles de désactivation (comme limiter strictement l'opération à des appels normaux), puis analyse le champ data pour détecter des adresses de contrat non conventionnelles et des sélecteurs de fonctions à haut risque. Grâce à des stratégies prédéfinies de liste blanche de contrats et de liste noire de fonctions, la transaction est directement annulée, formant finalement un système de défense de « interception de stratégie → blocage logique » qui bloque complètement les voies de manipulation de stockage et de transfert de fonds.

Dans l'ensemble, Safe n'a proposé la fonctionnalité Guard qu'après la version 1.3.0. Bien que Guard puisse fournir un contrôle de transaction multi-signatures extrêmement granulaire, les utilisateurs rencontrent un seuil d'entrée élevé pour utiliser cette fonctionnalité. Ils doivent mettre en œuvre eux-mêmes la logique de vérification Guard, une mise en œuvre grossière ou défectueuse de Guard peut ne pas aider les utilisateurs à améliorer la sécurité de leur portefeuille Safe, il est donc nécessaire de réaliser 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 de trading met en évidence l'importance de mettre à jour régulièrement les infrastructures de sécurité. Cette plateforme utilise la version v1.1.1(<1.3.0) du contrat Safe, ce qui signifie qu'elle ne peut pas utiliser le mécanisme Guard, une caractéristique de sécurité clé. Si cette plateforme mettait à niveau vers la version 1.3.0 ou une version ultérieure du contrat Safe, et mettait en œuvre un mécanisme Guard approprié, tel que la désignation d'une adresse sur liste blanche unique pour recevoir des fonds, et effectuait une validation stricte des ACL des fonctions du contrat, elle aurait peut-être pu éviter cette perte. Bien que ce 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 fonctionne comme un système de sécurité intelligent installé sur un coffre-fort d'actifs numériques, et son efficacité dépend de la rigueur de la conception des règles et de la qualité de leur mise en œuvre. Face à des méthodes d'attaque de plus en plus sophistiquées, nous avons besoin de :

• 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 combinant divers mécanismes de sécurité
• Audit continu : mise en œuvre de Guard de manière définie