Risques liés au propriétaire et à la récupération d'un compte intelligent

Auditez qui peut contrôler un compte intelligent, comment la récupération remplace le propriétaire, quels délais et droits d'annulation s'appliquent, et si des modules ou mises à niveau créent des voies de prise de contrôle cachées.

À des fins éducatives uniquement ; ne constitue pas un conseil en investissement, juridique ou de sécurité. Une erreur de récupération ou de configuration peut transférer le contrôle d’un compte intelligent ou le verrouiller définitivement.

Réponse directe

Un compte intelligent est contrôlé par la logique d’autorisation qui lui est déployée, pas nécessairement par une seule clé privée. Un propriétaire ou validateur peut approuver les opérations ordinaires, tandis qu’un gardien, module de récupération, exécuteur ou administrateur de mise à niveau peut disposer d’une autre voie pour remplacer le propriétaire ou exécuter des transactions.

La récupération réduit le risque qu’une clé perdue rende le compte inutilisable, mais ajoute une surface de prise de contrôle. Auditez toute voie capable d’autoriser une exécution, de changer validateurs ou propriétaires, d’installer des modules, de mettre le code à niveau, ou d’annuler et finaliser une récupération. Les libellés « propriétaire » et « gardien » de l’interface ne prouvent pas les pouvoirs réels du contrat.

Consignez le résultat dans une table d’autorisations : adresse exacte sur la chaîne, rôle, action appelable, seuil, délai, autorité d’annulation, expiration, périmètre de dépense, autorité de mise à niveau et domaine de contrôle indépendant. Revérifiez-la après chaque changement et sur chaque chaîne où le compte existe.

Fonctionnement

Identifier le compte et le code. Vérifiez l’ID de chaîne et l’adresse, puis l’implémentation, le proxy ou beacon, la fabrique et la version. Pour un proxy ERC-1967, lisez les slots d’implémentation, de beacon et d’administrateur plutôt que de croire un badge d’interface.
Recenser les voies d’autorisation. Lisez propriétaires et seuils, validateurs ERC-4337, validateurs, exécuteurs, hooks et gestionnaires fallback ERC-7579, modules et guards de type Safe, clés de session, contrats de récupération et administrateurs d’urgence ou de mise à niveau. Un exécuteur ou module Safe peut agir sans le seuil normal.
Décoder la machine d’états de récupération. Établissez qui propose un propriétaire remplaçant, comment les approbations sont comptées et expirent, quand commence le délai, qui annule, qui finalise et ce qui arrive si la récupération est remplacée ou répétée. Tous les contrats de « récupération sociale » ne suivent pas la même séquence.
Tester indépendance et disponibilité. Des adresses ne sont pas indépendantes si un même appareil, individu, compte cloud, coffre de mots de passe, dépositaire ou administrateur les contrôle. Vérifiez que le seuil reste atteignable après une panne prévue sans qu’un domaine puisse prendre le contrôle.
Examiner l’autorité de configuration. Déterminez qui ajoute ou retire gardien, validateur, exécuteur, hook, module ou gestionnaire fallback, modifie seuil ou délai, suspend l’annulation ou met à niveau le compte et la récupération. Un timelock n’est utile que si aucun autre rôle ne contourne son délai et son annulation.
Surveiller et vérifier. Abonnez-vous ou interrogez indépendamment les changements de récupération, propriétaire, module, seuil, implémentation et administrateur. Après toute opération, décodez la transaction et vérifiez reçus, événements, stockage et propriétaires finaux sur la bonne chaîne ; le succès affiché ne suffit pas.

Exemple pratique

Supposons un compte avec le propriétaire O et trois gardiens G1, G2 et G3. N’importe quels 2-of-3 gardiens peuvent proposer le nouveau propriétaire N ; un délai de 24-hour commence ; O peut annuler pendant ce délai ; puis chacun peut finaliser. Le module peut appeler le changement de propriétaire sans approbation de O sur la transaction finale.

Les libellés suggèrent une récupération distribuée, mais G1 et G2 sont des applications sauvegardées dans le même compte cloud. Sa compromission donne à un attaquant le seuil effectif 2-of-3. Il propose N ; si surveillance ou annulation échoue pendant 24 hours, la finalisation transfère le contrôle même sans vol de la clé privée de O.

L’audit classe donc G1 et G2 dans un seul domaine, vérifie l’adresse et le code du module, teste l’annulation depuis un appareil sain, confirme l’événement qui lance le délai et contrôle si un administrateur peut remplacer immédiatement le module. Il n’effectue pas de récupération réelle sur le compte d’actifs sans procédure de test documentée et réversible en sécurité.

Risques et contrôles

Gardiens corrélés : utilisez appareils, identifiants, personnes ou dépositaires réellement indépendants ; testez les procédures sans regrouper les phrases de récupération.
Module ou exécuteur surpuissant : inspectez le code installé et son périmètre exact. Retirez les modules inutiles par la voie documentée et vérifiez sur la chaîne.
Seuil faible : évaluez résistance à la prise de contrôle et disponibilité. Un seuil nominal élevé n’aide pas si les signataires partagent un domaine ; un seuil inaccessible bloque le compte.
Délai absent ou contournable : vérifiez sur la chaîne le délai, son événement initial, qui peut le raccourcir et toute voie de remplacement immédiat.
Annulation inefficace : répétez détection et annulation, gardez le gas natif et une voie d’envoi indépendante si nécessaire, et vérifiez si l’ancien propriétaire, un quorum ou un autre rôle doit annuler.
Prise de contrôle par mise à niveau : surveillez implémentation, beacon et administrateur. Un administrateur sans délai peut modifier toutes les règles documentées.
Interface malveillante ou périmée : vérifiez indépendamment chaîne, compte, module, propriétaire proposé, seuil, délai et calldata. Ne révélez jamais phrase de récupération ou clé privée à un service de « récupération ».
Fausse finalisation : après annulation ou finalisation, confirmez reçu et stockage final. Vérifiez que propriétaire et modules voulus sont actifs et que la proposition indésirable est inexécutable.

Si une récupération non autorisée apparaît, cessez de signer les demandes sans rapport et conservez ID de proposition, hash, calldata, bloc, adresse du module et état actuel. Depuis un appareil sain, vérifiez l’alerte via un RPC indépendant, utilisez l’annulation documentée si elle reste disponible et surveillez finalisation, mises à niveau, modules et transferts. Si le contrôle est peut-être perdu, suivez un plan d’incident préécrit et uniquement des contacts authentifiés ; un transfert improvisé peut être devancé ou révéler la destination.

Idées reçues

« Seul le propriétaire peut déplacer les actifs. » Validateurs, exécuteurs, modules, contrats de récupération ou code mis à niveau peuvent offrir d’autres voies.
« Trois gardiens sont trois parties indépendantes. » Le contrat compte les approbations d’adresses ; il ne détecte pas appareils, sauvegardes ou administrateurs partagés.
« Un délai de 24-hour garantit le temps de réagir. » Surveillance, droit d’annulation utilisable, gas et inclusion sont nécessaires, et une autre voie privilégiée peut contourner le délai.
« Retirer un gardien met fin à son accès. » Confirmez la configuration finale et vérifiez ses autres rôles, modules, clés de session et récupérations en attente.
« Le support peut restaurer tout compte intelligent. » Seuls les pouvoirs encodés ou préconfigurés sur la chaîne peuvent modifier un compte auto-détenu. Sans propriétaire ni récupération valides, l’accès peut être perdu définitivement.