Le mois de juin qui vient de s'écouler a été marqué par une série d'incidents de sécurité dans le monde de la cryptographie, touchant de multiples maillons de la chaîne.
Selon le dernier rapport mensuel de sécurité publié par PeckShield, 40 attaques majeures de pirates ont eu lieu en juin, entraînant des pertes totales s'élevant à 75,87 millions de dollars. Plus inquiétant encore, ces attaques ne se sont pas concentrées sur un chemin d'attaque spécifique, mais ont plutôt touché 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 ont cédé les unes après les autres au cours du même mois.
Face à l'expansion des risques de sécurité Web3, qui ne se limitent plus à une seule porte d'entrée mais concernent désormais l'ensemble du chemin d'interaction sur la chaîne, chaque utilisateur est contraint de se poser à nouveau la question : mes actifs cryptographiques sont-ils encore en sécurité ?
I. Au-delà de la clé privée : l'importance cruciale de l'implémentation sous-jacente de la signature dans les portefeuilles
L'incident de sécurité survenu en juin sur le portefeuille SecondFi de l'écosystème Cardano en est l'exemple le plus direct.
SecondFi est l'ancien portefeuille Yoroi de l'écosystème Cardano. Entre le 21 et le 23 juin, des attaquants ont drainé environ 16 millions d'ADA depuis les adresses de certains utilisateurs de SecondFi, touchant environ 374 portefeuilles, pour une valeur d'environ 2,4 millions de dollars au prix de l'époque. SecondFi a par la suite indiqué avoir protégé en urgence environ 129 millions d'ADA supplémentaires qui auraient pu être affectés.
Ce qui rend cet incident particulièrement singulier, c'est que les utilisateurs touchés n'ont pas donné activement leur phrase de récupération aux attaquants. Le problème provenait de l'implémentation sous-jacente de la signature du portefeuille. Selon l'analyse de l'agence de sécurité BlockSec, l'erreur résidait dans la dérivation du nonce de signature à partir d'un message de transaction public, omettant le préfixe nonce secret requis par l'implémentation standard.
Cela signifie que chaque fois qu'un utilisateur signait une transaction avec la version vulnérable du portefeuille, les données de signature publiques diffusées sur la chaîne révélaient des informations suffisantes pour déduire la clé privée de l'adresse. Par conséquent, les attaquants n'avaient pas besoin d'infiltrer le téléphone de l'utilisateur ni d'obtenir sa phrase de récupération. L'analyse des données publiques sur la chaîne pouvait suffire à récupérer la clé privée de signature correspondant à l'adresse.
Du point de vue de l'utilisateur, le portefeuille fonctionnait toujours normalement. Après tout, la phrase de récupération ne s'affichait pas dans une pop-up, le mot de passe n'était pas cassé et la transaction était bien initiée par l'utilisateur. Mais du point de vue cryptographique, dès lors qu'une adresse d'utilisateur avait généré quelques signatures valides avec la version vulnérable, les données de transaction et de signature publiques pouvaient aider un attaquant à déduire la clé privée de signature de cette adresse.
En définitive, la sécurité d'un portefeuille dépend de la génération correcte de la clé privée, du respect strict des standards cryptographiques lors de la signature, ainsi que de la possibilité pour ces codes critiques d'être examinés et vérifiés de l'extérieur. C'est aussi pourquoi il est crucial que les composants centraux d'un portefeuille restent open source.
Bien sûr, il s'agit d'un défaut d'implémentation propre à une version spécifique d'un portefeuille spécifique, et non d'un problème général pour tous les portefeuilles auto-hébergés. Prenons l'exemple de TokenCore d'imToken : son dépôt de code central est hébergé publiquement sur GitHub, couvrant des fonctionnalités de base comme la gestion des clés, la dérivation des adresses et la signature des transactions.
Si l'open source ne garantit pas l'absence de vulnérabilités dans le code, et encore moins que l'utilisateur peut abandonner toute vigilance, il offre au moins une condition préalable importante : pour les composants cryptographiques et de signature les plus sensibles d'un portefeuille, l'open source permet aux chercheurs en sécurité, aux développeurs et à la communauté d'examiner le code, de reproduire les problèmes et d'effectuer des tests continus, plutôt que de devoir faire confiance à une boîte noire impossible à vérifier.
Pour l'utilisateur moyen, ce type d'incident met en lumière quelques principes de sécurité plus concrets :
- D'abord, les portefeuilles doivent toujours être téléchargés depuis le site web officiel ou les boutiques d'applications officielles, et mis à jour vers des versions sécurisées en temps opportun ;
- Ensuite, il est déconseillé de conserver tous ses actifs dans un même portefeuille utilisé pour les interactions quotidiennes. Les actifs importants à long terme peuvent être conservés dans un portefeuille matériel (hardware wallet) ou un portefeuille froid indépendant, isolé du portefeuille chaud connecté fréquemment aux DApps.
- Plus important encore, si le développeur d'un portefeuille confirme une vulnérabilité au niveau de la génération de clés ou de l'implémentation de la signature, simplement importer la même phrase de récupération dans un autre portefeuille ne résout généralement pas le problème.
En effet, après avoir importé le même jeu de mots de récupération dans un autre portefeuille, les adresses et clés privées déjà exposées ne changent pas. Les actifs affectés doivent être transférés vers une nouvelle adresse qui n'a jamais signé avec la version vulnérable. Pour l'utilisateur moyen, l'approche la plus prudente est généralement de suivre la procédure d'urgence officielle pour créer un tout nouveau portefeuille et une nouvelle phrase de récupération, puis de procéder à la migration des actifs, plutôt que d'importer ou de manipuler sans cesse les anciennes adresses de sa propre initiative.
II. Les L2 ne sont pas seulement « un Ethereum moins cher », mais aussi une chaîne de confiance complexe
Outre les portefeuilles, plusieurs incidents survenus en juin ont également pointé du doigt les risques associés aux systèmes L2 de plus en plus complexes.
Les 14 et 18 juin, deux anciens déploiements de Rollup liés à Aztec ont été attaqués successivement, entraînant des pertes combinées d'environ 4,35 millions de dollars.
Il est important de préciser que les attaques ont ciblé des déploiements hérités comme Aztec Connect, désormais obsolètes, et ne signifient pas que le réseau principal actuel d'Aztec Network a été attaqué. Cependant, les problèmes exposés par ces deux incidents sont instructifs pour l'ensemble du domaine des ZK Rollup.
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, faisant en sorte que le système enregistre un dépôt dans la preuve interne, tout en contournant le processus correspondant de déduction du solde sur la L1.
L'autre incident résultait d'une contrainte manquante dans le circuit de preuve à connaissance zéro. Le système a validé une preuve formellement correcte, mais n'a pas vérifié que l'arbre d'état privé utilisé par cette preuve correspondait exactement à la racine d'état publique effectivement utilisée pour le règlement sur Ethereum. L'attaquant a ainsi 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 la question traditionnelle : « le contrat contient-il une ligne de code vulnérable ? » Après tout, une preuve à connaissance zéro peut prouver qu'un processus de calcul respecte des règles établies, à condition que ces règles soient elles-mêmes correctes et complètes. Si un développeur oublie de contraindre une variable clé, la preuve peut toujours être mathématiquement valide, mais elle prouvera un résultat qui ne correspond pas à l'état réel du règlement.
L'incident de sécurité survenu peu après sur Taiko a quant à lui exposé un autre type de risque lié à la chaîne de confiance des L2.
Le 22 juin, le processus de vérification des preuves de Taiko basé sur SGX a été exploité, causant des pertes d'environ 1,7 million de dollars. Selon l'analyse de BlockSec, l'attaquant a utilisé une clé privée de signature SGX enclave qui avait été précédemment soumise à un dépôt GitHub public. Il a simultanément exploité une faille du contrat de vérification sur la chaîne, qui n'a pas rejeté les enclaves en mode DEBUG, pour enregistrer un prouveur malveillant en tant qu'instance légitime.
L'attaquant a ensuite falsifié une preuve d'état L2, amenant le contrat sur Ethereum à accepter un état L2 inexistant, et a finalement extrait des actifs des fonds du pont. En fin de compte, cela est dû au fait que la clé utilisée pour signer l'environnement d'exécution de confiance (TEE) a été rendue publique, et que les règles d'authentification à distance n'ont pas complètement vérifié les propriétés de l'environnement d'exécution, privant ainsi une preuve « certifiée » de la signification de confiance qu'elle aurait dû avoir.
Parallèlement, Base a connu des interruptions successives de la production de blocs sur son réseau principal les 25 et 26 juin. Dans son analyse post-incident, Base a indiqué que les deux interruptions étaient dues au même défaut de logique de construction de blocs : une transaction dont l'exécution avait échoué n'avait pas correctement nettoyé l'état enregistré précédemment, ce qui a entraîné un calcul erroné du Gas pour les transactions suivantes et la génération d'un bloc contenant une transition d'état invalide. Les autres nœuds n'ayant pu accepter ce bloc, le réseau a finalement cessé de progresser. Base a précisé que l'intégrité de la chaîne n'a pas été compromise pendant l'incident et que les fonds des utilisateurs sont toujours restés en sécurité.
Il ne s'agissait pas d'un vol d'actifs ou d'une attaque externe, mais d'une panne technique affectant la disponibilité et la capacité de récupération du réseau. Cependant, d'un point de vue de sécurité plus large, la disponibilité fait elle-même partie du modèle de sécurité d'une L2.
Car pour un 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 production continue de blocs, du fonctionnement normal des ponts inter-chaînes, de la récupération rapide des nœuds et de la possibilité pour l'utilisateur de disposer d'une voie de sortie praticable en cas de défaillance du système.
C'est pourquoi, lorsqu'ils utilisent une L2, les utilisateurs ne devraient pas se contenter de comparer les frais et les attentes d'airdrop. Pour les L2 de petite taille, récemment lancées ou dont les mécanismes de sécurité évoluent encore rapidement, il est conseillé d'éviter d'y conserver à long terme des actifs importants dépassant les besoins réels d'utilisation. Avant un transfert inter-chaînes, il faut vérifier qu'on utilise le pont officiel et se renseigner sur les délais de retrait, les mécanismes de suspension et les modes de sortie d'urgence. En cas d'arrêt de la production de blocs, d'anomalie de pontage ou d'alerte de sécurité officielle, il ne faut pas soumettre de transactions de manière répétée ou continuer à transférer des actifs.
Une approche plus prudente consiste à répartir la gestion des actifs selon leur usage et leur niveau de risque, plutôt que de concentrer toute sa liquidité sur une seule L2, un seul pont inter-chaînes ou un seul mécanisme de sortie.
III. Le contrat n'a pas été piraté, mais un service tiers peut quand même apporter l'attaque à l'utilisateur
Si les problèmes des portefeuilles et des L2 se situent encore au niveau des composants techniques relativement bas niveau, l'incident de Polymarket montre que l'interface frontale (frontend) web, la plus proche de l'utilisateur, peut elle aussi devenir une porte d'entrée pour les fonds.
Le 25 juin, Polymarket a annoncé qu'un de ses fournisseurs tiers avait été compromis, permettant à des attaquants d'injecter des scripts malveillants dans l'interface frontale de Polymarket consultée par certains utilisateurs.
Selon les statistiques d'agences de sécurité et d'analystes sur la chaîne, l'incident a entraîné des pertes d'environ 3 millions de dollars d'actifs utilisateurs, concernant environ 11 portefeuilles. Les fonds volés ont ensuite été transférés de Polygon vers Ethereum via un pont et échangés contre environ 1893 ETH. Toutefois, Polymarket a par la suite indiqué avoir supprimé la dépendance affectée et procéderait au remboursement intégral des utilisateurs touchés.
Le point clé de cet incident réside dans le fait que les utilisateurs accédaient probablement toujours au nom de domaine correct de Polymarket, et les informations disponibles à ce jour ne pointent pas vers une vulnérabilité du contrat intelligent central de Polymarket. Le problème provenait principalement d'une dépendance frontale tierce chargée par la page web.
Cet incident fait également office de miroir : aujourd'hui, la plupart des applications Web3 ne fonctionnent pas entièrement sur la chaîne. Les pages web vues par les utilisateurs, comme les interfaces de transaction, dépendent encore largement des infrastructures internet traditionnelles et de paquets logiciels tiers. Chacune de ces dépendances, si elle est attaquée, peut amener un site web légitime à afficher de fausses informations aux utilisateurs, à remplacer l'adresse de réception ou à inciter le portefeuille à signer une transaction malveillante.
Par conséquent, « l'URL est correcte » n'équivaut pas nécessairement à « tout le code chargé à cet instant est sûr », et « le contrat a été audité » ne signifie pas que l'intégralité du chemin d'interaction entre l'utilisateur et le contrat est exempt de risques. Face à ce type d'attaques frontales ou sur la chaîne d'approvisionnement, l'utilisateur moyen a du mal à vérifier indépendamment chaque ligne de code chargée par une page web. Cependant, il peut réduire les pertes potentielles en limitant les autorisations par interaction :
- Utiliser un portefeuille dédié aux interactions DApp : Éviter de connecter directement son portefeuille d'épargne à long terme à divers sites DeFi, NFT, de marchés prédictifs ou d'airdrop. Le portefeuille utilisé pour les interactions quotidiennes ne devrait contenir que les fonds destinés à une utilisation proche, limitant ainsi la portée d'un éventuel problème d'interface frontale ou d'autorisation.
- Prêter attention à l'opération réelle avant de signer, et non seulement au bouton sur la page web : Le fait qu'une page web affiche « Connexion », « Récupérer » ou « Confirmer la commande » ne garantit pas que la signature demandée par le portefeuille corresponde à cette même action.
- En cas d'anomalie sur la page web, ne pas poursuivre les opérations par habitude : Si la page demande soudainement de réimporter la phrase de récupération, de télécharger une extension supplémentaire, ou si le contenu de la transaction affiché ne correspond pas à la description sur la page, il faut interrompre l'interaction, vérifier la situation via les multiples canaux officiels du projet, et examiner ou révoquer les autorisations historiques qui ne sont plus utilisées.
Du point de vue des produits portefeuille, cela signifie aussi que le rôle du portefeuille est en train d'évoluer.
Il ne devrait pas se contenter d'être un outil pour conserver une clé privée et afficher une fenêtre de signature. Il doit aussi, autant que possible, aider l'utilisateur à comprendre l'intention de la transaction, à identifier les autorisations anormales, à visualiser les changements d'actifs, et à fournir des avertissements suffisamment clairs avant qu'une interaction à haut risque ne se produise.
Cependant, un portefeuille ne peut pas non plus éliminer tous les risques à la place de l'utilisateur. Un modèle de sécurité plus réaliste implique que le portefeuille, le protocole, la L2, les fournisseurs de services tiers et l'utilisateur lui-même collaborent pour réduire la surface d'attaque, plutôt que de rejeter la responsabilité sur une seule partie.
Pour conclure
Par le passé, on disait souvent : « Qui détient la clé privée détient les actifs sur la chaîne. »
Cette affirmation reste vraie, mais elle ne couvre pas l'intégralité du processus, de la « formation de l'intention de transaction » jusqu'à la « finalisation du règlement sur la chaîne ». La sécurité du Web3 aujourd'hui ne se limite plus à la protection d'une phrase de récupération. Elle englobe la protection de l'ensemble du chemin, depuis la génération des clés par le portefeuille, l'affichage de la transaction, l'exécution de la signature, jusqu'à la validation par le réseau et le règlement final.
Bien sûr, cela ne signifie pas que les utilisateurs doivent fuir toute interaction sur la chaîne. Pour eux, des habitudes de sécurité réellement efficaces impliquent de séparer la gestion des actifs selon leur usage, leur niveau de risque et leur contexte d'interaction : isolement pour les actifs à long terme, petits montants pour les interactions quotidiennes, autorisations limitées pour les DApps inconnues, vérifications multiples pour les opérations à haut risque.
Après tout, lorsque le risque de sécurité s'étend d'un point à toute une chaîne, la défense de l'utilisateur doit également évoluer, passant de la simple protection d'une clé privée à l'adoption d'un ensemble complet de bonnes pratiques.
À méditer ensemble.
