Détournement de WalletConnect : vidange après déconnexion

L'illusion de se déconnecter. Découvrez comment le détournement de session WalletConnect permet aux plates-formes malveillantes de maintenir des connexions en arrière-plan et de drainer les actifs après votre déconnexion.
Comprenez comment les dApps malveillantes continuent de s'épuiser après votre déconnexion
- L'architecture financière Web3 fonctionne sur une frontière structurelle fondamentale entre l'identité de l'utilisateur et l'exécution décentralisée. Contrairement aux environnements Internet hérités du passé, les applications décentralisées (dApps) n'hébergent, ne contrôlent ni ne gèrent les données de votre compte personnel, vos soldes financiers ou vos clés cryptographiques privées. Au lieu de cela, les protocoles agissent comme des moteurs de requêtes d'exécution, transmettant des paquets de données structurelles complexes à un cadre de portefeuille indépendant et non dépositaire dans lequel l'utilisateur conserve l'autorité unique et souveraine pour autoriser ou rejeter les changements d'état.
- Cette conception découplée a considérablement transformé la sécurité des utilisateurs, permettant aux participants d'explorer des fermes de rendement, des couches de jalonnement liquide et des échanges d'actifs sans exposer leurs phrases de départ privées directement à des serveurs Web externes.
- À l'interface de cet écosystème multi-chaînes se trouve WalletConnect, un protocole de communication open source largement intégré. WalletConnect établit une messagerie sécurisée et cryptée de bout en bout Pont entre les applications décentralisées et les portefeuilles mobiles ou de bureau, permettant un routage transparent des transactions via des réseaux de relais décentralisés.
- Cependant, cette interface fluide a introduit un angle mort de sécurité important profondément ancré dans la psychologie des utilisateurs et les hypothèses de développement Web front-end.
- Une grande partie des participants au Web3 opèrent selon un dangereux mythe de sécurité : ils croient que cliquer sur le bouton "Déconnecter" sur l'interface utilisateur du site Web d'une dApp coupe complètement les liens cryptographiques entre leur portefeuille et la plateforme. Cette hypothèse est complètement fausse.
Bien que le bouton modifie visuellement l'affichage de la page Web, il laisse souvent l'infrastructure sous-jacente complètement intacte.
- Si une plateforme est malveillante, ou si un attaquant externe détourne vos paramètres de session via des vulnérabilités du navigateur local, le pont de communication sécurisé reste pleinement opérationnel en arrière-plan.
- Ce pipeline persistant permet aux opérations de drainage automatisées de cibler vos actifs longtemps après que vous ayez fermé l'onglet du navigateur, éteint votre moniteur et quitté votre ordinateur.

1. L'architecture sous-jacente de la communication WalletConnect
Pour comprendre comment un canal de connexion peut être compromis et maintenu contre les intentions explicites d'un utilisateur, nous devons d'abord examiner la couche de communication structurelle du protocole. WalletConnect n'est pas un blockchain grand livre, une couche de consensus ou un dépositaire de fonds ; il fonctionne uniquement comme un canal de messagerie crypté. Il coordonne les communications entre deux points de terminaison distincts : le client demandant une action (la dApp) et le signataire exécutant l'action (votre application de portefeuille).
L'initialisation de ce pont sécurisé repose sur une poignée de main cryptographique en plusieurs étapes :
Création de proposition : Le dApp génère une proposition de session unique contenant une chaîne alphanumérique d'identificateur de ressource uniforme (URI). Cette chaîne code plusieurs paramètres critiques, notamment un identifiant de sujet de couplage unique, l'adresse Web d'un serveur relais central et une clé de chiffrement symétrique de bout en bout.
La présentation de la poignée de main : La dApp présente cette chaîne URI à l'utilisateur, en la formatant généralement sous la forme d'un code QR visuel sur un écran de bureau ou en la configurant sous la forme d'un bouton de lien profond automatisé sur les interfaces mobiles.
L'analyse du portefeuille : L'utilisateur ouvre son application de portefeuille non dépositaire et scanne le code QR ou appuie sur le lien mobile, permettant au logiciel de portefeuille d'analyser les paramètres de configuration.
Mise en place du tunnel : L'application de portefeuille utilise la clé symétrique analysée pour établir une connexion WebSocket cryptée directement au pont réseau relais désigné, renvoyant une réponse d'approbation de session signée cryptographiquement.
Une fois cette négociation terminée, les deux points de terminaison sont connectés de manière sécurisée via un canal de relais actif. Le serveur relais fonctionne essentiellement comme une boîte aux lettres aveugle. Il reçoit les demandes de charge utile de la dApp, les déplace sur le réseau en fonction de l'identifiant du sujet de couplage et les dépose sur l'application de portefeuille de l'utilisateur.
- Le serveur relais ne peut pas lire ou modifier le contenu de ces charges utiles car chaque message est entièrement crypté localement à l'aide de la clé symétrique partagée lors de la prise de contact initiale.
- Avec la sortie de la version deux du protocole, ces connexions sont devenues hautement persistantes pour éliminer les frictions des utilisateurs. Pour empêcher les utilisateurs d'avoir à scanner à plusieurs reprises les codes QR à chaque fois qu'ils rechargent une page ou subissent une panne mineure du réseau, l'architecture moderne maintient des couplages de longue durée. Ces paires peuvent stocker simultanément les états de connexion sur plusieurs réseaux blockchain distincts.
- Bien que cette persistance structurelle ait créé une expérience utilisateur nettement plus fluide pour les chaînes multi-chaînes DéFi opérations, il a également élargi la surface d'attaque persistante. Cela a laissé un tunnel de communication ouvert et à long terme fonctionnant en continu entre les portefeuilles des utilisateurs et les applications Web externes.
2. La tromperie de la déconnexion : élagage superficiel ou révocation complète
La vulnérabilité qui permet un drainage persistant après déconnexion n'est pas causée par une défaillance cryptographique au sein du protocole de communication lui-même. Il s’agit plutôt d’un écart structurel entre la manière dont les interfaces des navigateurs gèrent les données d’affichage locales et la manière dont les applications de portefeuille gèrent les états de connexion en arrière-plan.
Lorsqu'un développeur Web crée une interface frontale pour une plate-forme financière décentralisée, il écrit du code pour gérer les événements du cycle de vie de la connexion au portefeuille. Lorsqu'un utilisateur accède au coin supérieur de la page Web et clique sur le bouton « Déconnecter le portefeuille », l'application exécute un script localisé. Ce script effectue une série de tâches de nettoyage de base côté client :
Il supprime les clés de session de connexion actives enregistrées dans les cookies du navigateur, le stockage de session ou le cache local.
Il efface la machine d'état localisée de l'application, supprimant l'adresse du portefeuille et le solde de l'utilisateur de l'écran actif.
Il met à jour l'interface utilisateur pour afficher un bouton neutre et non connecté indiquant « Connecter le portefeuille ».
Pour l'utilisateur occasionnel, cette transformation visuelle ressemble à une terminaison absolue du lien. Le site Web n'affiche plus leurs données financières et la connexion semble rompue en toute sécurité.
- Cependant, ce nettoyage est entièrement superficiel. Vider le cache du navigateur local ne modifie que le Interface côté client. Il n'envoie pas d'instruction de terminaison explicite et structurelle à travers le réseau de relais pour démanteler le tunnel WebSocket en arrière-plan, et ne modifie pas non plus les journaux de connexion internes conservés dans l'application de portefeuille mobile de l'utilisateur.
- À moins que le développeur de la dApp n'ait explicitement codé une commande de terminaison au niveau du protocole, ou à moins que l'utilisateur n'ouvre les paramètres de son portefeuille pour purger manuellement le couplage, le canal de messagerie en arrière-plan reste grand ouvert sur le réseau de relais. L'application de portefeuille continue de reconnaître le sujet de couplage comme un canal de communication actif et autorisé.
- Si la dApp a été construite de manière malveillante par un escroc, ou si son code frontal a ensuite été compromis par une injection tierce, la plate-forme peut continuer à envoyer des charges utiles de requêtes de transaction brutes directement au téléphone de l'utilisateur, indépendamment du fait que l'onglet du navigateur soit ouvert, fermé ou effacé.

3. Mécaniques de piratage de session : XSS, voleurs d'informations et vol de couplage
- Étant donné que les couplages de communication modernes sont conçus pour survivre aux actualisations du navigateur et aux redémarrages du système, les données cryptographiques critiques requises pour maintenir le tunnel WebSocket sécurisé doivent être enregistrées de manière persistante sur le matériel local de l'utilisateur. Dans les environnements de navigateur de bureau standard, ces métadonnées de session sont écrites directement dans le fichier Stockage local ou DB indexée fichiers de configuration. Cela inclut les clés de chiffrement symétriques non chiffrées, les URL du serveur relais actif et les chaînes de rubrique de couplage correspondantes.
- Cette dépendance aux référentiels de stockage locaux du navigateur ouvre une grave vulnérabilité à Scripts intersites (XSS) injections et dédiées malware voleur d'informations Campagnes . Si un attaquant identifie une vulnérabilité dans le serveur Web principal d'une plate-forme DeFi ou injecte avec succès du code malveillant dans une bibliothèque de dépendances open source utilisée par le projet (comme un réseau de diffusion de contenu compromis ou un script d'analyse de données tiers), un exploit XSS peut s'exécuter silencieusement dans l'onglet du navigateur de l'utilisateur.
- Au moment où le script malveillant s'exécute dans le contexte de votre navigateur actif, il lit les répertoires de stockage locaux. Il extrait les clés symétriques brutes et non chiffrées et les sujets d'appariement utilisés pour communiquer avec votre application de portefeuille.
- Alternativement, si un utilisateur est amené à télécharger un fichier malveillant déguisé en modification de jeu vidéo, en robot de trading automatisé ou en correctif logiciel frauduleux, un logiciel malveillant voleur d'informations balaie l'ordinateur local, copiant l'intégralité du dossier de base de données IndexedDB de tous les navigateurs installés.
- Grâce à ces clés de connexion cryptographiques capturées, l'attaquant n'a pas besoin de compromettre votre téléphone mobile physique, de pirater votre système d'exploitation ou de deviner le mot de passe de votre portefeuille matériel. Ils importent simplement la clé symétrique volée et les paramètres d'appariement dans leur propre terminal de script personnalisé.
Ils connectent leur nœud malveillant directement au réseau de relais public WalletConnect en utilisant votre identifiant de sujet de couplage piraté.
- L'attaquant présentant la bonne configuration de clé cryptographique, le réseau relais valide immédiatement le lien. L'attaquant dispose désormais d'un pont de communication direct et actif directement sur l'écran de l'appareil mobile de la victime, lui permettant d'envoyer des demandes de signature arbitraires à toute heure de la journée, contournant complètement le site Web légitime de la dApp.
4. La boucle de drainage continu : exploitation de la fatigue et signature aveugle
- Une fois qu'un attaquant ou un opérateur dApp malveillant a sécurisé un tunnel de connexion piraté ou persistant, il déploie des outils automatisés à haute fréquence pour exploiter l'utilisateur. Étant donné que le pont de communication reste autorisé dans l'application de portefeuille de la victime, l'attaquant peut déclencher des demandes de transaction en temps réel qui ciblent instantanément l'écran du téléphone de l'utilisateur.
- La principale méthodologie d'exécution utilisée par ces syndicats est la Boucle de requête infinie. Le script de l'attaquant est configuré pour envoyer des demandes de transactions hautement prioritaires vers l'appareil de la victime à une fréquence extrême.
- Au moment où la victime déverrouille son smartphone pour consulter un e-mail, ouvrir un message ou consulter une application de navigation, son application de portefeuille force instantanément une fenêtre contextuelle modale de haute priorité à l'écran, exigeant une approbation immédiate de la signature.
- Si l'utilisateur clique sur "Rejeter" ou tente de rejeter l'alerte, le script de l'attaquant détecte le rejet sur le réseau relais et affiche automatiquement une nouvelle invite de signature identique à l'écran en une fraction de seconde.
- Cette livraison automatisée incessante crée une intense Déni de service (DoS) et fatigue cognitive Effet . Le bombardement continu d'alertes entraîne un ralentissement de l'application de portefeuille, ce qui rend incroyablement difficile pour l'utilisateur de naviguer dans son menu de paramètres internes pour localiser et supprimer la connexion de connexion sous-jacente.
- En cas de frustration intense, ou si l'utilisateur est pris au dépourvu alors qu'il clique rapidement sur son écran pour fermer les fenêtres contextuelles, il peut accidentellement cliquer sur le bouton « Confirmer » ou « Signer » dans une invite malveillante.
- De plus, ces requêtes détournées sont soigneusement structurées pour dissimuler leur véritable charge utile de transaction. Les attaquants envoient rarement une demande de transfert de jeton simple et claire qui montre explicitement que les actifs quittent le portefeuille.
- Au lieu de cela, ils formatent la requête à l'aide de fonctions cryptographiques complexes de bas niveau telles que
personal_signou crueth_signFormats de signature aveugle.
- Ces invites n'affichent aucune information lisible par l'homme, présentant à l'utilisateur un bloc massif et non analysable de nombres et de caractères hexadécimaux.
- La description textuelle accompagnant la demande est souvent usurpée pour lire « Synchroniser le portefeuille réseau » ou « Vérifier l'identité de connexion ».
- En réalité, cachée à l'intérieur de ce paquet de données cryptographiques brutes se trouve une instruction qui autorise une allocation d'actifs illimitée, déclenche une autorisation de dépense de jeton Permit2 sans gaz ou signe un appel de déplacement d'actifs qui draine la totalité du solde du portefeuille au moment où il est confirmé.
5. Déconnexion au niveau du frontend ou du portefeuille
Pour déterminer exactement où se situent les limites de la sécurité des communications, consultez cette comparaison des types de terminaison :
| Type de déconnexion | Réalité de sécurité en chaîne |
| Effacement du front-end | Efface uniquement le stockage de l'interface du navigateur local. |
| Révocation du portefeuille | Coupe définitivement le canal cryptographique d'arrière-plan. |
6. La surface d'attaque à long terme : sessions de communication par rapport aux allocations en chaîne
- Pour construire un cadre de sécurité totalement résilient, vous devez séparer votre compréhension du Couche de communication du Couche d'état en chaîne. Une vulnérabilité majeure dans la gestion des actifs des utilisateurs provient de la confusion entre un pont de communication ouvert et un pont de communication actif. Contrat intelligent allocation de dépenses.
- Une session WalletConnect appartient strictement au couche de communication. Il s'agit du canal numérique qui transmet les notifications de requête entre une interface Web et votre matériel local.
- Si une session est active, la dApp peut envoyer des invites de signature à votre écran, mais elle n'a aucun pouvoir pour modifier vos soldes blockchain sans votre signature.
- Si la session est correctement terminée, le canal est complètement démoli, ce qui signifie que la dApp perd toute capacité à communiquer avec votre appareil ou à faire apparaître des fenêtres contextuelles sur votre écran.
A l’inverse, une approbation symbolique appartient au couche d'état blockchain.
- Lorsque vous autorisez un ERC-20
approve()transaction ou exécutez une autorisation de dépense EIP-712 Permit2 pendant une session de connexion active, vous écrivez une instruction permanente directement dans les données du contrat intelligent de ce jeton spécifique.
- Cette instruction enregistre qu'une adresse de contrat intelligent externe désignée a le droit légal de retirer des jetons de votre compte en utilisant le
Fonction
transferFrom().
- Cette séparation structurelle signifie que même si vous ouvrez votre portefeuille et supprimez complètement une session active, toutes les allocations de jetons que vous avez autorisées pendant que cette session était active restent entièrement écrites dans le grand livre de la blockchain.
Le contrat intelligent malveillant n'a pas besoin d'un pont de session ouvert pour vider votre portefeuille.
- Étant donné que l'autorisation d'approbation en chaîne est déjà confirmée, l'attaquant peut interagir avec le contrat de jeton directement à partir de sa propre console de script, en retirant systématiquement les actifs de votre portefeuille sans jamais envoyer d'autre alerte sur votre téléphone.
- Pour parvenir à une véritable sécurité des actifs, il faut aborder ces deux éléments : supprimer manuellement les tuyaux de connexion persistants et révoquer systématiquement les autorisations de jetons ouverts.

7. Couches de sécurité architecturales
Comprendre les mécanismes spécifiques de chaque couche de sécurité permet d'éviter les exploits de fuite d'actifs après interaction :
| Profil de calque | Périmètre du risque opérationnel |
| Canal de session | Dicte une communication active et la génération de demandes. |
| Allocation de jetons | Dicte l'accès au déplacement d'actifs en chaîne non signés. |
8. Manuel d'atténuation : sécuriser vos pipelines cryptographiques
Étant donné que les implémentations d'interface par défaut sont souvent conçues autour d'un effacement superficiel du cache, vous devez prendre un contrôle proactif sur les états de votre session. Utilisez ce manuel de sécurité opérationnelle pour vous assurer que votre portefeuille reste complètement isolé des menaces de connexion persistantes :
Appliquer la purge de session côté portefeuille
- Ne supposez jamais que la fermeture d'un onglet de navigateur ou la déconnexion d'un site Web coupe votre connexion. Chaque fois que vous terminez une session de trading ou quittez une application DeFi, ouvrez physiquement votre application de portefeuille.
Accédez au Paramètres ou Applications connectées Dans le menu , sélectionnez le Sessions WalletConnect Connectez-vous et examinez les appariements actifs.
Localisez le protocole spécifique avec lequel vous avez fini d'interagir et sélectionnez manuellement Déconnecter.
- Cette action force votre portefeuille à diffuser un message explicite
session_deletemessage au réseau relais, invalidant définitivement le sujet d'appairage et bloquant toute demande future de routage vers votre appareil.
Tirez parti de la simulation de transactions avancée
- Évitez d'utiliser des portefeuilles existants qui agissent comme de simples écrans de signature pass-through. Migrez votre capital actif vers des portefeuilles axés sur la sécurité et dotés de fonctionnalités intégrées Modèles de vérification de domaine et Moteurs de simulation de transactions de pré-signature.
- Les portefeuilles sécurisés modernes utilisent des API avancées de validation de domaine pour vérifier l'authenticité d'une demande de session entrante. Si un domaine de phishing tente de détourner une session en imitant une marque populaire, le moteur de validation signale la non-concordance d'origine et alerte l'utilisateur.
De plus, assurez-vous que votre choix de portefeuille relit les données de transaction entrantes sur un fork de blockchain local avant d'afficher l'écran de signature.
- Un moteur de simulation robuste décomposera les données d'appel complexes et illisibles en une déclaration visuelle claire : vous montrant exactement quels jetons quitteront votre adresse et quelles autorisations seront accordées au contrat externe si vous exécutez la signature.
- Si une dApp prétend être une confirmation de connexion inoffensive, mais que le moteur de simulation avertit que la signature autorise une allocation d'actifs ouverts, rejetez la demande instantanément.
Mettre en œuvre une segmentation stricte du portefeuille
Appliquer une approche globale Stratégie de confinement du rayon de souffle sur l'ensemble de votre profil d'actifs numériques.
Ne connectez jamais un portefeuille d'entrepôt principal contenant vos économies à long terme ou vos actifs de grande valeur à des applications Web basées sur un navigateur.
- Gardez votre patrimoine principal en sécurité dans des périphériques matériels de stockage à froid isolés qui sont complètement propres des sessions d'interaction Web quotidiennes.
- Déployez des portefeuilles chauds distincts à faible solde ou des adresses de brûleur jetables spécifiquement pour vous connecter aux réseaux DeFi actifs, interagir avec des protocoles expérimentaux ou revendiquer des distributions de jetons promotionnels.
- Si un couplage de session sur un compte graveur est piraté via un script malveillant, la perte potentielle reste strictement confinée à ce bac à sable spécifique, gardant ainsi votre richesse principale complètement sécurisée.
9. Télémétrie en temps réel et intégration de DEXTools
- Dans l'environnement multichaîne moderne et hautement automatisé, maintenir une clarté absolue sur vos autorisations de contrats intelligents et vos pools de liquidités actifs est une exigence de survie essentielle. Lorsque vous rééquilibrez d'importantes allocations de capital ou interagissez avec des paires de jetons nouvellement déployées sur des couches d'échange décentralisées, le fait de vous fier à des liens non vérifiés ou à des connexions de navigateur persistantes expose vos actifs à des vulnérabilités d'exécution immédiates et à des risques majeurs.
- DEXTools fournit la télémétrie analytique critique en temps réel nécessaire pour vérifier l'intégrité du programme et les paramètres de sécurité de tout pool de jetons avant d'autoriser une connexion de portefeuille ou d'exécuter une signature de transaction. En saisissant l'adresse du contrat de n'importe quel actif directement dans l'explorateur de paires DEXTools avancé, vous pouvez évaluer instantanément les volumes de transactions en direct, contre-interroger les audits automatisés de sécurité des contrats intelligents, vérifier les durées de verrouillage du pool de liquidité et auditer les distributions des détenteurs de portefeuille. Cette visibilité précise et en temps réel vous permet de naviguer dans l'écosystème décentralisé en toute sécurité, en gardant votre richesse numérique à l'abri des réseaux persistants. Vous pouvez accéder
DEXOutils ici et commencez à trader dès aujourd'hui !
Avertissement : Cet article est à titre informatif uniquement et ne constitue pas un conseil en investissement, un conseil financier, un conseil commercial ou tout autre type de conseil. DEXTools ne recommande pas d'acheter, de vendre ou de détenir une crypto-monnaie ou un jeton. Les utilisateurs doivent effectuer leurs propres recherches et consulter un conseiller financier qualifié avant de prendre toute décision d'investissement. Les investissements en crypto-monnaie sont volatils et à haut risque. DEXTools n'est pas responsable des pertes subies.