Pouvez-vous vous protéger contre les piratages ? - Principaux enseignements de l'émission en direct de Certora sur l'évolution des menaces et ce que les protocoles doivent faire à l'avenir

Si vous avez déjà vécu dans la crainte d'être piraté et de voir vos fonds détournés par un acteur malveillant, Certora, l'une des principales sociétés de sécurité de la blockchain, a tenté d'apaiser ces craintes le jeudi 12 février au moyen d'un livestream intitulé "How DeFi Hacks Have Changed in the Last 5 Years and What This Means for Protocols" (Comment les piratages de DeFi ont changé au cours des 5 dernières années et ce que cela signifie pour les protocoles).

Seth Hallem, CEO de Certora, s'est joint à Ofek Ray Orlev, chercheur senior en sécurité et chef d'équipe au sein de l'entreprise, pour analyser en quoi les attaques modernes diffèrent des exploits DeFi antérieurs et ce que les équipes chargées des protocoles devraient faire en réponse à ces attaques.

Seth a rejoint Certora il y a huit mois après avoir fait carrière dans l'analyse statique, la qualité des logiciels et la cybersécurité. Il applique maintenant cette expérience à Web3 et DeFi. Ofek apporte douze ans d'expérience dans la recherche de vulnérabilités dans les domaines offensifs et défensifs. Avant d'entrer dans l'espace DeFi il y a deux ans, il a dirigé les efforts de red teaming et de tests de pénétration chez Intel, où il a développé des outils offensifs et défensifs pour les systèmes embarqués.

Plutôt que de revenir sur des piratages bien connus, la discussion s'est concentrée sur deux attaques récentes et sophistiquées. La première, CPIMP, signifie Clandestine Proxy In The Middle of Proxy (Proxy clandestin au milieu du proxy). La seconde, GlassWorm, est le premier ver crypto-ciblé et autopropagé à s'attaquer à la chaîne d'approvisionnement NPM et OpenVSX. Ensemble, ces attaques illustrent la façon dont la sécurité DeFi est passée de bogues évidents à des campagnes systémiques, patientes et multicouches.

L'attaque Clandestine Proxy In The Middle of Proxy (CPIMP)

L'attaque CPIMP exploite les modèles d'initialisation de proxy dans les contrats intelligents. Au fond, l'attaque détourne la phase d'initialisation d'un contrat proxy. Si un attaquant court-circuite le premier appel d'initialisation, il peut initialiser le proxy avec une implémentation malveillante.

Ce qui rend le CPIMP particulièrement remarquable, ce n'est pas seulement son implantation initiale, mais aussi la persistance et la furtivité qui s'ensuivent. Le proxy malveillant imite l'implémentation prévue, de sorte que tous les tests et toutes les interactions normales continuent de fonctionner. Les développeurs et les utilisateurs ne constatent aucun dysfonctionnement évident. L'attaquant insère un proxy clandestin entre le proxy légitime et la logique prévue, ce qui lui permet d'intercepter et de manipuler les appels sans détection immédiate.

Les acteurs malveillants ont également conçu la persistance à travers les mises à jour. Lorsque les développeurs mettent à jour le proxy pour ajouter des fonctionnalités, la couche malveillante réinjecte son code dans la nouvelle implémentation. Une fois infectée, chaque mise à niveau ultérieure passe par le pipeline de l'attaquant. Cette conception permet un contrôle à long terme plutôt qu'un exploit rapide de type "smash-and-grab".

Les attaquants ont même exploité une vulnérabilité dans Etherscan qui leur a permis d'usurper l'adresse d'implémentation affichée en remplissant un emplacement de stockage obsolète. Les observateurs externes s'appuyant sur les explorateurs de blocs verraient la mauvaise implémentation, ce qui rendrait la détection encore plus difficile.

Seth et Ofek ont comparé cette approche à un "rug pull", mais en mettant l'accent sur un horizon temporel différent. Un "rug pull" traditionnel draine souvent les fonds rapidement. Le CPIMP semble conçu pour attendre qu'un protocole prenne suffisamment d'ampleur pour justifier son activation. L'attaquant peut traiter le système compromis comme un actif dormant qui mûrit avec le temps. Cette patience suggère un état d'esprit de campagne plutôt que d'exploitation opportuniste.

Attaque GlassWorm : Extraction de clés privées à partir de 50 extensions de portefeuilles

GlassWorm déplace le champ de bataille de la logique de la chaîne vers la chaîne d'approvisionnement du développement. Les attaquants ont introduit une extension VS Code malveillante qui a infecté les machines des développeurs. Une fois installée, l'extension a extrait les clés privées d'une cinquantaine d'extensions de portefeuilles. Elle recherchait également les identifiants GitHub et déterminait si le développeur infecté entretenait d'autres extensions VS Code.

Si le développeur publie une extension, le ver y injecte un code malveillant avant sa diffusion. Ce mécanisme de propagation a transformé le logiciel malveillant en un véritable ver. Chaque extension nouvellement infectée propage la charge utile plus loin, amplifiant sa portée dans l'écosystème.

Prenez une seconde pour comprendre cette information. Vous êtes un développeur. Votre machine est infectée. Vous êtes probablement vidé de vos fonds. Toutes les extensions que vous développez sont infectées, et tous ceux qui les téléchargent voient également leur machine infectée, et ainsi de suite.

L'étiquette "glass" fait référence à l'utilisation de caractères non imprimables pour dissimuler le code malveillant. La charge utile apparaissait sous la forme de lignes vides ou d'espaces blancs dans les éditeurs. Les outils traditionnels d'analyse statique n'ont pas réussi à repérer le code avant que les chercheurs n'identifient l'attaque.

GlassWorm combine des techniques connues et de nouvelles innovations. Il a réutilisé des stratégies de compromission de la chaîne d'approvisionnement et des méthodes d'extraction de clés privées. Cependant, il a introduit un nouveau mécanisme de commande et de contrôle en exploitant la blockchain Solana. Le ver lit les instructions cryptées intégrées dans les champs mémo des transactions. Les attaquants ayant signé ces transactions avec leur propre portefeuille, les machines infectées pouvaient vérifier et exécuter de nouvelles instructions sans dépendre d'un serveur traditionnel.

Cette conception de commande et de contrôle sur la chaîne a rendu les efforts de démantèlement beaucoup plus difficiles. Les forces de l'ordre ou les équipes de sécurité ne pouvaient pas simplement s'emparer d'un serveur centralisé. Les attaquants ont également utilisé les sujets d'événements de Google Calendar comme canal de communication de secours. Ces couches ont créé une résilience et une flexibilité que les chercheurs en sécurité ont rarement observées dans les vers Web2 antérieurs.

Le ver a également installé un client VNC caché et configuré un proxy SOCKS sur les machines infectées. Ces capacités indiquent que les attaquants ne cherchaient pas seulement à vider les portefeuilles. Leur objectif était d'obtenir un large accès aux systèmes des victimes. L'attaque a brouillé la frontière entre Web2 et Web3 et a démontré que la sécurité DeFi ne s'arrête plus aux contrats intelligents.

Que pouvez-vous faire pour vous protéger ?

Les deux intervenants ont souligné que les développeurs ne devaient pas adopter un état d'esprit nihiliste. La sécurité parfaite n'existe pas, mais les améliorations pratiques réduisent considérablement les risques.

Ofek a conseillé aux équipes d'examiner minutieusement leurs chaînes d'outils, de limiter les extensions inutiles et de maintenir les dépendances à jour. Il a exhorté les développeurs à comprendre réellement comment leurs processus de déploiement s'exécutent.

Il a également recommandé une vérification post-déploiement. Les équipes devraient inspecter directement les emplacements de stockage de la chaîne plutôt que de s'appuyer uniquement sur les explorateurs de blocs. Elles devraient confirmer qu'aucun appel de délégué ou étape d'initialisation inattendus n'ont eu lieu.

Seth a mis l'accent sur la pensée architecturale. Il a déclaré que "l'idée qu'une extension de navigateur est un endroit sûr pour déchiffrer une clé privée et signer des transactions qui déplacent de l'argent est un concept erroné construit à partir du mauvais modèle de menace" Il a fait valoir que les extensions de navigateur fonctionnent dans des environnements très dynamiques et ne devraient pas gérer des opérations cryptographiques de grande valeur. Les modules de sécurité matériels et les environnements de signature isolés offrent des garanties plus solides.

Mert Mumtaz, PDG de Helius Labs, s'est fait l'écho de ce sentiment dans un message public, écrivant que l'idée selon laquelle les portefeuilles sont des extensions Chrome représente l'une des décisions les plus discutables de l'industrie en matière d'ergonomie.

Ces deux points de vue soulignent la nécessité de repenser les hypothèses relatives à la sécurité des portefeuilles à mesure que les flux de capitaux augmentent.

À quoi faut-il faire attention en 2026 ?

À l'horizon 2026, les deux intervenants s'attendent à une participation accrue des institutions au Web3. Alors que les gouvernements et les grandes institutions financières envisagent de s'impliquer davantage, les protocoles seront soumis à des exigences plus strictes en matière de diligence raisonnable et de conformité. La documentation, la vérification formelle, les procédures normalisées et les partenariats continus en matière de sécurité deviendront probablement des attentes de base.

Sur le plan offensif, les attaquants continueront à mélanger les techniques Web2 et Web3. À mesure que la qualité des contrats intelligents s'améliorera et que les audits deviendront plus courants, les attaquants cibleront l'ingénierie sociale, l'exfiltration de clés privées, les frontends, les processus de gouvernance et les chaînes d'approvisionnement. Seth compare ce changement à la montée des ransomwares dans le Web2 après que les organisations aient renforcé les services exposés.

Les protocoles doivent s'attendre à ce que les attaquants se comportent comme des entreprises. Certaines campagnes viseront des gains transactionnels tels que l'hameçonnage et le pillage de portefeuilles. D'autres rechercheront des opportunités stratégiques en ciblant les faiblesses systémiques d'infrastructures valant des milliards de dollars.

Dernières réflexions

Le livestream a mis en évidence un changement clair dans la sécurité des DeFi. Les premiers exploits reposaient souvent sur des erreurs de codage évidentes. Les attaques modernes font appel à la patience, à la persistance et à la sophistication entre domaines. Le CPIMP a montré comment les attaquants peuvent se cacher dans les architectures de proxy et attendre que la valeur s'accumule. GlassWorm a montré comment les compromissions de la chaîne d'approvisionnement et la commande et le contrôle de la chaîne peuvent s'étendre au-delà des contrats intelligents dans les environnements des développeurs.

Les protocoles ne peuvent pas prédire toutes les techniques futures. Ils peuvent cependant augmenter le coût des attaques grâce à une architecture disciplinée, un déploiement minutieux, des surfaces de menace minimisées et une vérification continue. À mesure que les capitaux et la surveillance réglementaire augmentent, la sécurité passera d'un audit ponctuel à une exigence opérationnelle permanente.

En savoir plus sur SolanaFloor

Les développeurs sur Solana ont presque décuplé depuis 2020, le réseau accueillant un record de 3830 nouveaux développeurs en 2025
Solana Perps Scene Snubbed Once Again As Trojan Terminal Integrates Elsewhere (La scène des perpettes de Solana est encore une fois snobée alors que le terminal troyen s'intègre ailleurs)

Les actifs numériques peuvent-ils survivre au krach ?