
Analyse approfondie de l'attaque contre Bybit & Safe{Wallet} : comment les entreprises peuvent-elles construire une « forteresse de sécurité cryptographique » ?
TechFlow SélectionTechFlow Sélection

Analyse approfondie de l'attaque contre Bybit & Safe{Wallet} : comment les entreprises peuvent-elles construire une « forteresse de sécurité cryptographique » ?
Vulnérabilité fondamentale : « Ce que l'on voit ≠ ce que l'on signe ».
Auteur : Kane Wang, CTO de Safeheron
Aperçu de l'incident Bybit
Le 21 février 2025 à 22h13 (heure de Singapour), l'équipe de Bybit a initié via le processus multisignature de Safe{Wallet} un transfert d'un portefeuille froid vers un portefeuille tiède. Le PDG Ben a vérifié l'adresse cible via Safe{Wallet}, mais au moment final de confirmation sur Ledger, ce dernier n'affichant que les paramètres d'interaction avec le contrat et non les informations complètes de la transaction, les attaquants en ont profité pour voler près de 1,5 milliard de dollars d'actifs.
Le 26 février 2025, Sygnia a publié ses résultats d'enquête, confirmant que le conteneur AWS S3 de Safe{Wallet} avait été compromis par des hackers ayant déployé un code JavaScript malveillant ciblant Bybit, dont le but principal était de modifier efficacement le contenu de la transaction durant la phase de signature. Par ailleurs, Safe{Wallet} a déclaré que les contrats intelligents Safe n'avaient pas été affectés.
Cet incident présente des similitudes avec l'attaque récente ayant coûté 4,5 millions de dollars à Radiant Capital, sonnant l'alarme pour tout le secteur de la sécurité des actifs numériques.
Kane Wang, CTO de Safeheron (le seul fournisseur en Asie de service de custody auto-géré open source MPC pour actifs numériques), a également réalisé une analyse approfondie de cet événement :
Vulnérabilité fondamentale : « Ce que vous voyez ≠ Ce que vous signez »
L'incident Bybit a mis au jour une faille fatale dans l'architecture des portefeuilles : un fossé énorme existe entre l'intention de transaction affichée et l'opération réellement exécutée, un problème courant dans de nombreux systèmes de portefeuilles :
A. Infrastructure compromise
Les attaquants ont détourné l'interface utilisateur du portefeuille (comme ce fut le cas pour Safe{Wallet}) ou le backend, permettant aux utilisateurs d'approuver sans le savoir des opérations malveillantes déguisées en transactions légitimes. Bien que les solutions de portefeuilles basées sur des contrats intelligents (telles que Safe{Wallet}) excellent dans la fragmentation des clés, elles ne résolvent pas entièrement le problème de vérification de l'intégrité des transactions.
B. Problèmes de compatibilité écosystémique
L'incident Bybit a révélé un défaut critique de compatibilité écosystémique : même en utilisant des dispositifs sécurisés comme Ledger, l'absence d'intégration fluide entre différents systèmes peut encore compromettre la sécurité. Dans cette attaque :
· L'interface utilisateur de Safe a été altérée : les attaquants ont manipulé l'affichage de l'adresse cible, la faisant apparaître légitime.
· Échec de la vérification hors ligne de Ledger : dernière ligne de défense, Ledger n'a pas pu appliquer efficacement le mécanisme de vérification « Ce que vous voyez est ce que vous signez ». En raison d'une faible compatibilité avec l'interface de Safe, Ledger n'affiche que les paramètres d'interaction avec le contrat, sans présenter clairement les informations de transaction, empêchant ainsi la vérification des détails critiques.
L'utilisation combinée de Ledger et de Safe avait pour objectif initial d'assurer une sécurité accrue grâce à une combinaison « froid + tiède », mais nous avons constaté qu'il manquait une conception intégrée de défense en profondeur, exposant plusieurs points aveugles inattendus en matière de sécurité.
Cet événement souligne la nécessité pour les portefeuilles institutionnels de mettre en œuvre des mesures de sécurité plus avancées afin de garantir l'authenticité des transactions et de résister à des attaques complexes dans des environnements à haut risque. L'adoption de solutions de sécurité multicouches devient essentielle face à des méthodes d'attaque de plus en plus sophistiquées.
Comment construire une « forteresse de sécurité cryptographique » ?
1. Signature via plusieurs appareils :
Lors de la signature d'une transaction, chaque signataire doit utiliser un matériel différent, évitant ainsi qu'un seul appareil effectue toutes les signatures, réduisant ainsi le risque de point de défaillance unique.
2. Concentration des risques et protection systématique :
Les fournisseurs d'infrastructures de sécurité et les exchanges doivent analyser systématiquement leurs points d'exposition aux risques et limiter les surfaces vulnérables. Dans la combinaison Ledger + Safe, si l'interface officielle de Safe est falsifiée ou victime d'un détournement réseau, cela agrandit davantage la surface d'exposition. Les exchanges doivent identifier précisément les étapes sensibles lors du choix d'une solution, et renforcer la protection autour de ces points critiques. Par exemple :
· Un fournisseur d'infrastructure de sécurité peut concentrer son exposition au risque sur l'application, en s'assurant qu'elle dispose d'une capacité autonome de « Ce que vous voyez est ce que vous signez » et d'une vérification via TEE (environnement d'exécution fiable). Même en cas de piratage du serveur, les actifs clients restent sécurisés. Ainsi, même si un employé interne agit malicieusement ou si le système est infiltré, tant que l'application du portefeuille fonctionne normalement, le fournisseur ne peut ni voler les clés des utilisateurs ni transférer les actifs clients.
En outre, les fournisseurs devraient appliquer strictement les principes DevSecOps, en assurant un environnement de construction sécurisé de l'application, ainsi que des processus rigoureux d'approbation et de vérification, renforçant ainsi davantage la sécurité du système. Réduire les surfaces d'exposition et appliquer DevSecOps sont des principes que Safeheron respecte fermement.
· Pour une solution de portefeuille froid, celui-ci peut constituer un point d'exposition limité doté d'une fonctionnalité conviviale de « Ce que vous voyez est ce que vous signez », de listes blanches et de mises à jour fiables du firmware, assurant ainsi une utilisation sécurisée du portefeuille.
3. Gestion fractionnée des fonds :
Concentrer de gros montants dans un seul portefeuille comporte un risque élevé ; en cas de brèche de sécurité, la perte totale est possible. Il est donc recommandé de classer les fonds selon leur fréquence d'utilisation en « portefeuille chaud », « portefeuille tiède » et « portefeuille froid ». Même lors de l'utilisation d'un portefeuille froid, il est possible de subdiviser davantage l'allocation des fonds, instaurant ainsi une stratification rationnelle pour une isolation efficace des capitaux.
Si Bybit avait réparti ses 1,5 milliard de dollars en ETH dans des portefeuilles aux fréquences d'utilisation différentes, les hackers n'auraient au moins pas pu remporter une victoire décisive, causant autant de pertes, voire l'attaque aurait pu être évitée, car les hackers auraient pu viser d'autres cibles plus lucratives.
Sécurité des portefeuilles institutionnels : l'architecture détermine la survie
La sécurisation de la gestion des actifs institutionnels requiert des investissements continus. Nous prévoyons que la tendance future de la gestion des actifs numériques consistera à gérer les portefeuilles chauds via des solutions multisignatures MPC-TSS, les portefeuilles tièdes combinant multisignature et politiques de contrôle des risques pour une exploitation fine, et les portefeuilles froids adoptant des solutions institutionnelles offrant une véritable vérification « Ce que vous voyez est ce que vous signez » hors ligne, construisant ainsi continuellement un système de protection multicouche pour la sécurité des actifs des utilisateurs et des institutions.
À propos de Safeheron
Safeheron est un fournisseur de solutions de custody sécurisé d'actifs numériques basé sur MPC+TEE, et est la première entreprise au monde et le seul fournisseur en Asie à proposer une bibliothèque open source en C++ pour le protocole de signature seuil MPC.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News














