Au-delà des clés privées : des wallets, L2 à la chaîne d'approvisionnement, comment protéger les frontières de la sécurité Web3 ?

Le mois de juin qui vient de s'écouler a été marqué par une série d'incidents de sécurité touchant plusieurs maillons de la chaîne dans le monde de la cryptographie.

Le dernier rapport mensuel de sécurité de PeckShield révèle qu'en juin, 40 attaques majeures de pirates informatiques ont eu lieu, avec des pertes totales s'élevant à 75,87 millions de dollars. Plus inquiétant encore, ces attaques ne se sont pas concentrées sur un seul vecteur d'attaque, mais ont plutôt couvert des défauts d'implémentation de signature de portefeuille, des vulnérabilités de protocole L2 et des attaques sur la chaîne d'approvisionnement de services tiers. Plusieurs lignes de défense sont tombées successivement au cours du même mois.

Lorsque le risque de sécurité du Web3 passe d'un point d'entrée unique à l'ensemble du chemin d'interaction en chaîne, chaque utilisateur est obligé de repenser une question : mes actifs Crypto sont-ils vraiment encore en sécurité ?

I. Au-delà des clés privées : l'importance de l'implémentation de la signature du portefeuille sous-jacent

L'incident de sécurité survenu sur SecondFi, un portefeuille de l'écosystème Cardano en juin, en est l'exemple le plus frappant.

SecondFi est le successeur de Yoroi, un portefeuille de l'écosystème Cardano. Du 21 au 23 juin, des attaquants ont transféré environ 16 millions d'ADA depuis certaines adresses d'utilisateurs de SecondFi, impliquant environ 374 portefeuilles, pour une valeur d'environ 2,4 millions de dollars au prix de l'époque. SecondFi a ensuite indiqué avoir protégé par des mesures d'urgence environ 129 millions d'ADA supplémentaires potentiellement affectés.

La particularité de cet incident est que les utilisateurs concernés n'avaient pas activement divulgué leur phrase mnémonique aux attaquants. Le problème résidait dans l'implémentation de la signature au niveau du portefeuille. Selon l'analyse de la société de sécurité BlockSec, le nonce de signature était dérivé par erreur à partir de messages de transaction publics, en omettant le préfixe secret de nonce requis par l'implémentation standard.

Cela signifie que chaque fois qu'un utilisateur signait une transaction avec la version affectée du portefeuille, les données de signature publiques diffusées sur la chaîne exposaient des informations suffisantes pour déduire la clé privée de l'adresse. Par conséquent, l'attaquant n'avait pas besoin de pirater le téléphone de l'utilisateur ni d'obtenir la phrase mnémonique ; il suffisait d'analyser les données publiques en chaîne pour potentiellement récupérer la clé privée de signature de l'adresse correspondante.

Du point de vue de l'utilisateur, le portefeuille semblait fonctionner normalement – après tout, la phrase mnémonique n'a pas été divulguée via une fenêtre contextuelle, le mot de passe n'a pas été cracké, et la transaction a bien été initiée par l'utilisateur. Mais du point de vue cryptographique, si l'adresse de l'utilisateur a généré des signatures valides via la version affectée, les données publiques de transaction et de signature pouvaient aider l'attaquant à déduire la clé privée de signature de cette adresse.

En fin de compte, la sécurité du portefeuille repose sur la question de savoir si la clé privée est correctement générée, si la signature est effectuée strictement selon les normes cryptographiques, et si ces codes critiques peuvent être examinés et vérifiés de manière externe. C'est également l'importance de maintenir les composants principaux du portefeuille en open source.

Bien sûr, il s'agit d'un défaut d'implémentation propre à une version spécifique d'un portefeuille particulier, et non d'un problème généralisé à tous les portefeuilles en libre garde. Prenons l'exemple de TokenCore d'imToken : son dépôt de code principal est hébergé publiquement sur GitHub, couvrant les fonctions sous-jacentes du portefeuille telles que la gestion des clés, la dérivation d'adresses et la signature de transactions.

Bien que l'open source ne garantisse pas l'absence de vulnérabilités dans le code, ni ne dispense les utilisateurs de toute vigilance, pour les composants cryptographiques et de signature les plus sensibles d'un portefeuille, l'open source offre au moins une condition préalable importante : les chercheurs en sécurité, les développeurs et la communauté peuvent inspecter le code, reproduire les problèmes et effectuer des tests continus, au lieu de devoir se fier à une boîte noire non vérifiable.

Pour les utilisateurs ordinaires, ce type d'incident correspond également à plusieurs principes de sécurité plus pragmatiques.

Tout d'abord, les portefeuilles doivent toujours être téléchargés depuis le site officiel ou les magasins d'applications officiels, et mis à jour vers les versions sécurisées en temps opportun.

Deuxièmement, il ne faut pas placer tous ses actifs dans un seul portefeuille d'interaction quotidienne. Les actifs importants à long terme peuvent être conservés dans un portefeuille matériel ou un portefeuille froid autonome, isolé du portefeuille chaud utilisé pour se connecter fréquemment aux DApps.

Plus important encore, une fois que le portefeuille officiel confirme une vulnérabilité au niveau de la génération de clé ou de l'implémentation de la signature, importer simplement la phrase mnémonique d'origine dans un autre portefeuille ne résout généralement pas le problème.

En effet, importer la même phrase mnémonique dans un autre portefeuille ne modifie pas les adresses et clés privées déjà exposées. Les actifs concernés doivent être transférés vers une nouvelle adresse qui n'a jamais été signée via la version vulnérable. Pour l'utilisateur moyen, l'approche la plus sûre consiste généralement à suivre la procédure d'urgence officielle pour créer un tout nouvel ensemble de portefeuille et de phrase mnémonique, puis à effectuer la migration des actifs, plutôt que d'importer ou de manipuler à plusieurs reprises l'adresse d'origine.

II. Les L2 ne sont pas seulement « un Ethereum moins cher », mais aussi une chaîne de confiance complexe

Outre les portefeuilles, plusieurs incidents en juin ont également mis en évidence les risques des systèmes L2 de plus en plus complexes.

Les 14 et 18 juin, deux anciens déploiements Rollup liés à Aztec ont été attaqués, causant des pertes totales d'environ 4,35 millions de dollars.

Il convient de préciser que les attaques visaient d'anciens déploiements comme Aztec Connect, qui sont obsolètes, et ne signifient pas que le réseau principal actuel d'Aztec Network a été attaqué. Cependant, les problèmes révélés par ces deux incidents sont un avertissement important pour l'ensemble du domaine des ZK Rollups.

Dans l'un des incidents, l'attaquant a exploité une incohérence entre le nombre de transactions et les données réellement traitées, permettant au système d'enregistrer un dépôt dans la preuve tout en contournant le processus de déduction de solde correspondant sur la L1.

L'autre incident provenait d'un manque de contrainte dans le circuit de preuve à connaissance nulle. Le système a validé une preuve formellement valide, mais n'a pas assuré que l'arbre d'état privé utilisé par la preuve corresponde exactement à la racine d'état publique réelle utilisée pour le règlement sur Ethereum. L'attaquant a donc pu générer une preuve autour d'un arbre d'état falsifié et retirer des actifs du contrat L1.

Ce type de problème est difficile à résumer par l'expression « y a-t-il une ligne de code vulnérable dans le contrat ? ». Après tout, une preuve à connaissance nulle peut démontrer qu'un processus de calcul suit des règles établies, mais à condition que les règles elles-mêmes soient correctes et complètes. Si le développeur oublie de contraindre une variable clé, la preuve peut toujours être mathématiquement valide, mais elle prouve un résultat qui ne correspond pas à l'état de règlement réel.

L'incident de sécurité qui a ensuite frappé Taiko a exposé un autre risque de la chaîne de confiance L2.

Le 22 juin, le processus de vérification des preuves basé sur SGX de Taiko a été exploité, causant une perte d'environ 1,7 million de dollars. Selon l'analyse de BlockSec, l'attaquant a utilisé une clé privée de signature d'enclave SGX qui avait été précédemment soumise à un dépôt public GitHub, tout en exploitant le fait que le contrat de vérification en chaîne n'a pas refusé les enclaves en mode DEBUG. L'attaquant a enregistré un prouveur malveillant comme instance légitime.

L'attaquant a ensuite falsifié une preuve d'état L2, faisant accepter au contrat sur Ethereum un état L2 inexistant, puis a retiré des actifs des fonds pontés. En substance, la clé utilisée pour signer l'environnement d'exécution de confiance a été divulguée, et les règles d'attestation à distance n'ont pas vérifié complètement les attributs de l'environnement d'exécution, ce qui a finalement vidé de son sens la confiance accordée à une preuve « attestée ».

Parallèlement, la production de blocs sur le réseau principal de Base a été interrompue à deux reprises, les 25 et 26 juin. Dans son analyse rétrospective, Base a indiqué que les deux interruptions provenaient du même défaut de logique de construction de bloc : une transaction ayant échoué n'avait pas correctement nettoyé l'état précédemment enregistré, ce qui a conduit à un calcul erroné du gaz pour les transactions suivantes, et à la génération d'un bloc contenant une transition d'état invalide. Comme les autres nœuds ne pouvaient pas accepter ce bloc, le réseau a finalement cessé de progresser. Base a précisé que l'intégrité de la chaîne n'avait pas été compromise pendant l'incident et que les fonds des utilisateurs étaient toujours en sécurité.

Il ne s'agissait pas d'un vol d'actifs ou d'une attaque externe, mais d'un problème technique affectant la disponibilité et la capacité de récupération du réseau. Cependant, d'un point de vue plus large de la sécurité, la disponibilité fait elle-même partie du modèle de sécurité d'une L2.

Car pour l'utilisateur, la sécurité d'une chaîne ne dépend pas seulement de la capacité d'un pirate à falsifier des actifs, mais aussi de la capacité à produire des blocs en continu, au bon fonctionnement du pont inter-chaînes, à la rapidité de récupération des nœuds, et à l'existence d'une voie de sortie viable pour l'utilisateur en cas de défaillance du système.

Par conséquent, lors de l'utilisation d'une L2, les utilisateurs ne devraient pas seulement comparer les frais et les attentes d'airdrop. Pour les L2 de petite taille, nouvellement lancées ou dont les mécanismes de sécurité évoluent rapidement, évitez de stocker à long terme des actifs importants dépassant les besoins réels d'utilisation ; avant un transfert inter-chaînes, assurez-vous d'utiliser le pont officiel et renseignez-vous sur les délais de retrait, les mécanismes de suspension et les procédures de sortie d'urgence ; en cas d'arrêt de la production de blocs, d'anomalie de transfert inter-chaînes ou d'alerte de sécurité officielle, n'effectuez pas de transactions répétées et ne continuez pas à transférer des actifs.

Une approche plus prudente consiste à répartir les actifs en fonction de leurs usages et de leurs niveaux de risque, plutôt que de placer toute sa liquidité sur une seule L2, un seul pont inter-chaînes ou un seul mécanisme de sortie.

III. Même sans violation du contrat, les services tiers peuvent transmettre l'attaque aux utilisateurs

Si les problèmes de portefeuille et de L2 concernent encore des composants techniques relativement bas niveau, l'incident de Polymarket montre que le front-end web, le plus proche de l'utilisateur, peut également devenir une porte d'entrée pour les fonds.

Le 25 juin, Polymarket a indiqué que l'un des fournisseurs tiers qu'il utilisait avait été compromis, permettant à l'attaquant d'injecter un script malveillant dans le front-end de Polymarket auquel certains utilisateurs accédaient.

Selon les statistiques des sociétés de sécurité et des analystes en chaîne, l'incident a causé une perte d'environ 3 millions de dollars d'actifs utilisateur, impliquant environ 11 portefeuilles. Les fonds volés ont ensuite été transférés de Polygon vers Ethereum et convertis en environ 1 893 ETH. Cependant, Polymarket a ensuite indiqué avoir supprimé la dépendance affectée et rembourserait intégralement les utilisateurs concernés.

Le point crucial de cet incident est que les utilisateurs accédaient probablement toujours au bon domaine de Polymarket, et les divulgations actuelles ne pointent pas vers une vulnérabilité du contrat intelligent principal de Polymarket. Le problème vient principalement de la dépendance front-end tierce chargée par la page web.

C'est également un miroir : aujourd'hui, la plupart des applications Web3 ne fonctionnent pas entièrement en chaîne. Les pages web que les utilisateurs voient, comme les interfaces de trading, dépendent encore largement de l'infrastructure internet traditionnelle et de logiciels tiers. Si l'une de ces dépendances est compromise, un site web légitime peut afficher des informations erronées aux utilisateurs, remplacer l'adresse de réception, ou inciter le portefeuille à signer une transaction malveillante.

Par conséquent, « l'URL est vraie » ne signifie pas nécessairement que « tout le code chargé à ce moment est sûr », et « le contrat a été audité » ne signifie pas que l'ensemble du chemin d'interaction entre l'utilisateur et le contrat est exempt de risques. Face à ce type d'attaques front-end et de chaîne d'approvisionnement, il est difficile pour un utilisateur ordinaire de vérifier indépendamment chaque ligne de code chargée par la page web. Cependant, il peut toujours limiter les pertes potentielles en réduisant les autorisations d'interaction unique :

• Utiliser un portefeuille d'interaction DApp distinct : évitez de connecter directement le portefeuille d'épargne à long terme à divers sites DeFi, NFT, de prédiction de marché et d'airdrop. Le portefeuille d'interaction quotidien ne doit contenir que les fonds destinés à une utilisation récente. Même si le front-end ou l'autorisation est compromise, l'impact reste relativement limité.
• Prêter attention à l'opération réelle avant de signer, et non seulement au bouton sur la page : le fait que la page web affiche « Connexion », « Réclamer » ou « Confirmer la commande » ne signifie pas que la signature apparaissant dans le portefeuille est la même chose.
• En cas d'anomalie sur la page, ne pas continuer à opérer par habitude : si la page demande soudainement de réimporter la phrase mnémonique, de télécharger un plugin supplémentaire, ou si le contenu de la transaction affiché ne correspond pas à la description de la page, interrompre l'interaction, vérifier via plusieurs canaux officiels du projet, et révoquer les autorisations historiques qui ne sont plus utilisées.
• Du point de vue des produits de portefeuille, cela signifie également que le rôle joué par le portefeuille évolue.

Il ne doit pas être seulement un outil pour stocker des clés privées et afficher une fenêtre de signature. Il doit également aider l'utilisateur à comprendre l'intention de la transaction, à identifier les autorisations anormales, à afficher les changements d'actifs, et à fournir des avertissements suffisamment clairs avant qu'une interaction à haut risque ne se produise.

Mais le portefeuille ne peut pas non plus éliminer tous les risques pour l'utilisateur. Un modèle de sécurité plus réaliste consiste en ce que les portefeuilles, les protocoles, les L2, les fournisseurs de services tiers et les utilisateurs réduisent ensemble la surface d'attaque, plutôt que de rejeter toute la responsabilité sur une seule partie.

En guise de conclusion

Autrefois, on disait souvent : qui détient la clé privée détient les actifs en chaîne.

Cette affirmation reste vraie, mais ne couvre pas l'ensemble du processus allant de « l'intention de transaction de l'utilisateur » à « le règlement en chaîne » pour ses actifs. La sécurité du Web3 aujourd'hui ne se limite plus à protéger une phrase mnémonique, mais à protéger l'ensemble du chemin : de la génération de la clé par le portefeuille, à l'affichage de la transaction, à la signature, jusqu'à la vérification par le réseau et le règlement final.

Bien sûr, cela ne signifie pas que les utilisateurs doivent se tenir à l'écart de toutes les interactions en chaîne. Pour l'utilisateur, des habitudes de sécurité réellement efficaces signifient qu'il doit gérer séparément l'utilisation des actifs, leur niveau de risque et le contexte d'interaction : les actifs à long terme exigent un isolement strict, les interactions quotidiennes doivent être de faible montant, les DApps inconnues doivent avoir des autorisations faibles, et les opérations à haut risque doivent être vérifiées à plusieurs reprises.

Après tout, lorsque le risque de sécurité passe d'un point à une chaîne, la défense de l'utilisateur doit également évoluer, passant de la simple protection de sa clé privée à un ensemble complet d'habitudes.

À tous, bonne continuation.