Attaque Bybit : 1,5 milliard de dollars volés via du JavaScript malveillant

TL;DR : chronologie de l'injection dans l'interface Safe Wallet de Bybit

• L'interface de signature a échoué : Le multisig n'a pas fait défaut à Bybit : c'est l'interface de signature qui a été compromise. Les attaquants ont réécrit ce que voyait le signataire dans le navigateur, si bien que cinq approbateurs ont validé sans le savoir un delegatecall pointant vers le code des attaquants.
• Un an d'historique de scripts : Le script malveillant ne se déclenchait que pour une liste prédéfinie de signataires, et a déplacé 1,5 milliard de dollars après que le delegatecall a remplacé le master copy. cside conserve chaque script tiers pendant un an maximum, afin de pouvoir retrouver a posteriori la version exacte du build injecté.
• Surveillez le JavaScript de trésorerie : Si votre interface de trésorerie charge du JavaScript tiers, surveillez-le en temps réel dès aujourd'hui. Si ce n'est pas le cas, partez tout de même du principe que le fournisseur de l'interface de portefeuille, lui, en charge, comme c'était le cas pour Safe.

Peu de temps ? Découvrez le blocage in-browser des Magecart et skimmers de cside. Elle couvre tout ce qui suit en un seul déploiement.

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 qu'un utilisateur ne clique sur « Approuver ». C'est pourquoi nous avons créé cside, afin de 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 changé le type de transaction, passant d'un simple « call » à ce qu'on appelle un « delegatecall ».

• Le delegatecall a permis aux attaquants d'exécuter leur propre code comme s'il faisait partie du contrat du coffre.
• Ils s'en sont servis pour modifier l'adresse du « master copy » du coffre, un élément clé du fonctionnement de ce portefeuille en particulier, afin qu'elle pointe vers le contrat des attaquants.
• Une fois ce changement effectué, 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

D'après l'analyse de @S1r1u5_ sur X, voici le déroulement étape par étape de la compromission du Safe{Wallet} :

1. Injection de JavaScript malveillant : les attaquants ont ajouté du code malveillant dans app.safe.global/_next/static/chunks/pages/_app-4f0dcee809cce622.js, après qu'un des développeurs compromis l'a déployé en production.
2. 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).
3. Passage en delegatecall : au lieu d'un appel normal, le code malveillant a changé l'opération pour la valeur 1, correspondant au delegatecall, déléguant ainsi l'exécution à un contrat de l'attaquant.
4. Modification du stockage du Safe : en utilisant le delegatecall, le contrat du hacker a réécrit le slot de stockage masterCopy du portefeuille Safe.
5. 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.

Cet enchaînement d'événements a permis à l'attaquant de contourner toutes les protections multisignature habituelles, la transaction apparaissant comme valide dans l'interface du portefeuille.

Pourquoi les attaques côté client sont difficiles à investiguer

Lorsque des hackers frappent via du code côté client (le JavaScript et le HTML exécutés dans votre navigateur web), la collecte de preuves forensiques après coup peut s'avérer particulièrement délicate :

1. 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.
2. Déploiements et mises à jour rapides : les applications web modernes mettent à jour ou redéploient leur code fréquemment. Lorsqu'un attaquant injecte des scripts malveillants, il peut les annuler tout aussi rapidement, ne laissant qu'une brève fenêtre de temps pour recueillir des preuves.
3. 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é.
4. Manque de transparence dans le contrôle de version : certaines équipes ne conservent 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.
5. 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 analyse les scripts propriétaires côté client et fait transiter le JavaScript tiers par proxy avant qu'il ne s'exécute sur votre site. Nous conservons même les scripts pendant un an maximum, 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, ce qui aurait potentiellement empêché 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