Le 21 février 2025, le monde des cryptomonnaies a été le témoin de l'un des plus grands vols de l'histoire du secteur. Des hackers ont dérobé 1,5 milliard de dollars à Bybit, une plateforme d'échange de cryptomonnaies majeure. Ils ont eu recours à l'ingénierie sociale, ce qui démontre que la sécurité dans son ensemble va bien au-delà des mots de passe et des pare-feux.
Les enquêtes menées par des cabinets spécialisés en sécurité et une annonce officielle du FBI affirment que ce piratage est lié au Lazarus Group, une organisation cybercriminelle nord-coréenne connue pour dérober des sommes considérables afin de financer les activités de son pays (par exemple, le braquage de la Banque du Bangladesh). Le FBI désigne cette opération nord-coréenne sous le nom de « TraderTraitor ».
Ce qui s'est passé
Bybit utilise un portefeuille multisignature pour protéger ses fonds. Un portefeuille multisig fonctionne comme un coffre-fort qui nécessite plusieurs clés appartenant à différents employés pour être ouvert. Aucune personne seule ne peut déplacer les fonds.
Cependant, les hackers n'ont pas accédé directement au coffre. Ils ont plutôt modifié l'interface utilisateur (le front end) que les employés utilisent pour approuver les transactions, trompant ainsi les détenteurs de clés pour qu'ils signent de fausses transactions sans s'en rendre compte.
Comment c'est arrivé
1) Attaque côté client (front end)
Les attaquants ont injecté du JavaScript malveillant dans l'interface web utilisée par les employés de Bybit pour approuver les transactions. Ce code malveillant était dissimulé de telle sorte que tout semblait normal à l'écran — mais en coulisses, il modifiait des informations cruciales.
La plupart des entreprises se concentrent uniquement sur la sécurité du backend ou sur les portefeuilles matériels. Mais si le front end est compromis, il peut modifier silencieusement les transactions avant même que l'utilisateur clique sur « Approuver ». C'est pour cette raison que nous avons créé cside. Pour permettre aux sites web de surveiller les dépendances dans le navigateur de leurs utilisateurs et d'éviter ce type d'attaques.
Les hackers ont utilisé des e-mails de phishing et de faux messages pour convaincre les employés que les transferts étaient de routine.
2) Le mécanisme delegatecall + proxy
Bien que Bybit ait utilisé un « coffre » multisig, le JavaScript malveillant a modifié le type de transaction, passant d'un simple « call » à ce qu'on appelle un « delegatecall ».
- Le delegatecall a permis aux hackers d'exécuter leur propre code comme s'il faisait partie du contrat du coffre.
- Ils ont utilisé cela pour modifier l'adresse du « master copy » du coffre — un élément clé du fonctionnement de ce type de portefeuille — afin de la faire pointer vers le contrat des attaquants.
- Une fois ce changement en place, les attaquants ont pu exécuter des fonctions spéciales de « sweep » qui ont vidé le coffre de ses 1,5 milliard de dollars.
Analyse technique approfondie
Basée sur l'analyse de @S1r1u5_ sur X.
Voici le déroulement technique étape par étape de la compromission du Safe{Wallet} :
- Injection de JavaScript malveillant
- Les attaquants ont ajouté du code malveillant dans app.safe.global/_next/static/chunks/pages/_app-4f0dcee809cce622.js. Concrètement, l'un des développeurs compromis l'a poussé en production.
- Ciblage de executeTransaction()
- Le JS malveillant ne se déclenchait que s'il reconnaissait une liste prédéfinie de signataires (en l'occurrence, les propriétaires du multisig de Bybit).
- Passage en delegatecall
- Au lieu d'un appel normal, le code malveillant a changé l'opération en 1, ce qui correspond au delegatecall. Cela a délégué l'exécution à un contrat contrôlé par l'attaquant.
- Modification du stockage du Safe
- En utilisant le delegatecall, le contrat du hacker a effectivement réécrit le slot de stockage masterCopy du portefeuille Safe.
- Le nouveau master copy vide les fonds
- Le nouveau contrat malveillant « master copy » contenait les fonctions sweepETH() et sweepERC20(), permettant à l'attaquant de siphonner 1,5 milliard de dollars en cryptomonnaies.
Cette chaîne d'événements a permis à l'attaquant de contourner toutes les protections multisignature habituelles, car la transaction apparaissait comme valide dans l'interface du portefeuille.
En résumé :
- Les attaques côté client sont sous-estimées — Les gens se concentrent souvent sur les serveurs backend, mais une simple modification du code du site peut amener les utilisateurs à signer n'importe quoi.
- L'erreur humaine — L'ingénierie sociale exploite la précipitation ou la confiance des personnes envers le contenu des e-mails. Un faux message soigneusement élaboré peut tromper même un personnel bien formé.
- Delegatecall + patterns proxy — De nombreux portefeuilles crypto et protocoles DeFi utilisent des contrats « proxy » pour plus de flexibilité. Malheureusement, si un attaquant redirige le pointeur vers son propre code, il peut prendre le contrôle total.
- Interfaces trompeuses — L'interface affichait tout comme « légitime », de sorte que les signataires n'avaient aucune idée qu'ils approuvaient des transactions malveillantes.
- Systèmes complexes — Même avec plusieurs couches de sécurité, une seule défaillance dans la vigilance des utilisateurs ou l'intégrité du front end peut tout faire s'effondrer.
Pourquoi les attaques côté client sont difficiles à investiguer
Lorsque des hackers frappent via du code côté client (le JavaScript et le HTML qui s'exécutent dans votre navigateur web), la collecte de preuves forensiques après coup peut s'avérer particulièrement délicate :
- Données éphémères :
- Les sessions de navigation sont de courte durée, et les journaux indiquant précisément quels fichiers JavaScript ont été chargés — et comment ils ont évolué — peuvent être incomplets ou inexistants. Contrairement aux journaux côté serveur, les journaux front end ne sont souvent pas conservés de manière persistante.
- Déploiements et mises à jour fréquents :
- Les applications web modernes mettent à jour ou redéploient leur code régulièrement. Lorsqu'un attaquant injecte des scripts malveillants, il peut les supprimer tout aussi rapidement — ne laissant qu'une fenêtre de temps très courte pour capturer des preuves.
- Journaux serveur limités :
- Même si le côté serveur est sécurisé, l'action réelle se déroule dans le navigateur de l'utilisateur. Les journaux serveur standard peuvent indiquer qu'un fichier a été servi, mais pas nécessairement quelles modifications y ont été apportées ni comment il s'est comporté une fois exécuté.
- Manque de transparence dans le contrôle de version :
- Certaines équipes ne maintiennent pas d'historique public de chaque build front end. Si la modification malveillante a été introduite via un pipeline de build compromis, les équipes forensiques ont besoin d'historiques de versions détaillés — qui peuvent être mal suivis ou facilement manipulés.
- Dépendance aux tiers :
- Le code côté client fait souvent appel à des bibliothèques externes ou des CDN. Si le script malveillant a été injecté via un service tiers, les équipes forensiques doivent coordonner leurs efforts avec des prestataires externes qui ne conservent pas forcément de journaux détaillés ou qui peuvent être lents à coopérer.
Pour les enquêteurs forensiques, tout cela signifie que reconstituer une attaque côté client implique de rassembler des fragments de caches navigateur, des journaux de console développeur, des historiques de déploiement et toutes les données de versioning disponibles dans le pipeline de build. C'est faisable — mais c'est nettement plus complexe qu'investiguer une compromission côté serveur traditionnelle, où l'on dispose généralement de journaux plus clairs et d'un accès direct au système compromis.
Comment cside aurait pu aider
cside est une solution qui analyse les scripts côté client propriétaires et proxifie le JavaScript tiers avant qu'il ne s'exécute sur votre site. Nous conservons même les scripts jusqu'à un an, offrant une capacité forensique complète là où vous avez aujourd'hui un angle mort. Si Bybit avait utilisé cside, toute modification inattendue ou malveillante de l'interface du portefeuille Safe aurait pu être détectée et bloquée, empêchant potentiellement l'intégralité de cette attaque.
Références : https://x.com/lookonchain/status/1892965762186522975 https://x.com/lookonchain/status/1892971811807387877 https://x.com/lookonchain/status/1893223657838633177
