Des milliards dérobés à Binance : pourquoi la suspension des retraits n’a-t-elle pas immédiatement stoppé les pertes ?
Dans la soirée du 29 octobre, Binance, la plus grande plateforme d’échange de cryptomonnaies au monde, a été victime d’un incident de sécurité sans précédent. Il ne s’agissait pas d’une simple intrusion informatique, mais d’une attaque complexe, menée sur plusieurs mois et impliquant la chaîne d’approvisionnement interne ainsi que la gestion des autorisations. Grâce à des techniques d’ingénierie sociale savamment orchestrées, les attaquants se sont progressivement infiltrés dans les systèmes internes de Binance, jusqu’à accéder au service de signature des portefeuilles chauds. L’incident a non seulement entraîné la perte d’actifs d’une valeur de plusieurs milliards de dollars, mais a aussi mis en lumière un principe fondamental souvent négligé des infrastructures blockchain modernes : dans un univers on-chain décentralisé, une instruction de « suspension » émise par une plateforme n’équivaut pas à une révocation immédiate des autorisations on-chain.
Selon le rapport d’enquête préliminaire publié par Binance le 3 novembre, la chronologie de l’attaque est bien plus longue que ne le laissaient d’abord penser les observateurs. Dès juin, un ingénieur chargé de l’exploitation des portefeuilles a téléchargé un programme d’installation de Homebrew falsifié alors qu’il installait un outil de programmation fondé sur l’IA. Son appareil a ainsi été infecté par un code malveillant. Bien que l’équipe de sécurité ait ensuite remplacé l’appareil et renouvelé les identifiants, les attaquants avaient déjà obtenu des informations sur le poste de cet employé et de ses collègues. En septembre, l’ordinateur professionnel d’un autre ingénieur logiciel a été pris à distance après une attaque par hameçonnage déguisée en offre de recrutement. En octobre, les attaquants se sont appuyés sur des ordinateurs compromis et des outils d’IA internes pour étendre leur contrôle et voler les identifiants de déploiement de conteneurs du personnel chargé de l’exploitation des portefeuilles. Enfin, vers 20 h 05 UTC le 29 octobre, ils ont utilisé ces identifiants pour déployer des conteneurs, accéder sans autorisation au service interne de signature des portefeuilles et lancer une série de transferts importants. Le suivi on-chain réalisé par l’organisme indépendant de sécurité TRM Labs montre que des actifs ont été transférés depuis des portefeuilles Binance répartis sur dix blockchains en une vingtaine de minutes. La valeur des actifs concernés est estimée à environ 6,34 milliards de dollars. À ce jour, Binance a gelé ou intercepté environ 2,85 milliards de dollars et s’est engagée à assumer elle-même les pertes financières, en réservant des fonds pour protéger les intérêts des utilisateurs.
L’enseignement technique le plus important de cet incident tient à cette question : pourquoi les actifs ont-ils continué à sortir après la suspension du service de retrait par la plateforme ? Selon l’idée reçue, fermer les canaux de retrait d’une plateforme d’échange suffit à interrompre les sorties de fonds. Mais cette attaque a exploité une particularité du mécanisme EIP-7702 d’Ethereum. Celui-ci permet à un compte ordinaire de désigner du code de contrat intelligent chargé d’exécuter des opérations, au moyen d’une autorisation signée. En exploitant le service de signature compromis, les attaquants ont mis en place une délégation malveillante on-chain, qui a conféré à leurs contrats intelligents un droit d’exécution partiel sur les portefeuilles chauds. Dès qu’une telle autorisation est inscrite sur la blockchain, elle existe indépendamment des services centralisés de la plateforme. Même après la fermeture par Binance de l’interface de retrait sur son site web, ces autorisations on-chain déjà actives sont restées valides. Les attaquants ont donc pu déclencher directement des transactions en utilisant les droits accordés, sans avoir à obtenir l’approbation de la plateforme. En outre, comme les portefeuilles chauds concernés reposaient sur la technologie du calcul multipartite (MPC), la signature nécessitait la coopération de plusieurs parties et aucune clé privée unique ne pouvait être désactivée d’urgence. L’équipe a donc dû mettre au point une procédure de révocation spécifique, ce qui lui a fait perdre un temps précieux. Ce n’est qu’à 00 h 10 UTC le 30 octobre que Binance a émis une nouvelle autorisation depuis le portefeuille chaud afin de supprimer le code de délégation malveillant. Le dernier transfert non autorisé, lui, avait été inscrit sur la blockchain à 23 h 56 UTC le 29 octobre. Ce décalage montre que « bloquer les nouvelles requêtes » et « révoquer les autorisations existantes » sont deux opérations techniques complètement différentes : la première consiste à désactiver un service, la seconde à modifier l’état de la blockchain.
Du point de vue de la gestion des risques, cet incident remet en cause l’idée reçue selon laquelle « tant que la clé privée n’a pas été divulguée, les fonds sont en sécurité ». Les attaquants n’ont pas volé directement la clé privée complète : ils ont utilisé la capacité de signature du système, en faisant signer par un service interne des transactions non approuvées. Cela montre que le périmètre de sécurité des actifs numériques ne se limite plus à la conservation des clés, mais s’étend au contrôle dynamique des autorisations. Dans son communiqué du 31 octobre, le FBI a attribué ce vol aux activités de TraderTraitor liées à la Corée du Nord, soulignant ainsi la capacité des attaques soutenues par des États à pénétrer les défenses de sécurité traditionnelles. Pour le secteur, le cas de Binance constitue une leçon sévère, mais nécessaire : tout en adoptant de nouvelles technologies comme le MPC et les outils d’IA pour gagner en efficacité, il faut réexaminer les principes fondamentaux de la réponse aux urgences. Les équipes d’ingénierie ne peuvent pas s’en remettre à la seule mesure consistant à « fermer le service ». Elles doivent mettre en place une voie d’urgence indépendante des processus opérationnels habituels et dont l’efficacité a été vérifiée à l’avance par des exercices. Par ailleurs, les systèmes de signature doivent distinguer rigoureusement les demandes de transfert ordinaires des demandes d’autorisation qui modifient les droits d’exécution d’un compte : une fois activées, ces dernières produisent des effets durables, difficiles à inverser immédiatement. L’incident a été en grande partie contenu, mais le défi technique qu’il laisse derrière lui — comment mettre en place un arrêt d’urgence de type centralisé sur une blockchain décentralisée — reste une question à laquelle tous les fournisseurs d’infrastructures crypto doivent faire face et apporter une réponse.
Suivez-moi pour ne pas manquer le prochain décryptage rapide des marchés.
Dans la soirée du 29 octobre, Binance, la plus grande plateforme d’échange de cryptomonnaies au monde, a été victime d’un incident de sécurité sans précédent. Il ne s’agissait pas d’une simple intrusion informatique, mais d’une attaque complexe, menée sur plusieurs mois et impliquant la chaîne d’approvisionnement interne ainsi que la gestion des autorisations. Grâce à des techniques d’ingénierie sociale savamment orchestrées, les attaquants se sont progressivement infiltrés dans les systèmes internes de Binance, jusqu’à accéder au service de signature des portefeuilles chauds. L’incident a non seulement entraîné la perte d’actifs d’une valeur de plusieurs milliards de dollars, mais a aussi mis en lumière un principe fondamental souvent négligé des infrastructures blockchain modernes : dans un univers on-chain décentralisé, une instruction de « suspension » émise par une plateforme n’équivaut pas à une révocation immédiate des autorisations on-chain.
Selon le rapport d’enquête préliminaire publié par Binance le 3 novembre, la chronologie de l’attaque est bien plus longue que ne le laissaient d’abord penser les observateurs. Dès juin, un ingénieur chargé de l’exploitation des portefeuilles a téléchargé un programme d’installation de Homebrew falsifié alors qu’il installait un outil de programmation fondé sur l’IA. Son appareil a ainsi été infecté par un code malveillant. Bien que l’équipe de sécurité ait ensuite remplacé l’appareil et renouvelé les identifiants, les attaquants avaient déjà obtenu des informations sur le poste de cet employé et de ses collègues. En septembre, l’ordinateur professionnel d’un autre ingénieur logiciel a été pris à distance après une attaque par hameçonnage déguisée en offre de recrutement. En octobre, les attaquants se sont appuyés sur des ordinateurs compromis et des outils d’IA internes pour étendre leur contrôle et voler les identifiants de déploiement de conteneurs du personnel chargé de l’exploitation des portefeuilles. Enfin, vers 20 h 05 UTC le 29 octobre, ils ont utilisé ces identifiants pour déployer des conteneurs, accéder sans autorisation au service interne de signature des portefeuilles et lancer une série de transferts importants. Le suivi on-chain réalisé par l’organisme indépendant de sécurité TRM Labs montre que des actifs ont été transférés depuis des portefeuilles Binance répartis sur dix blockchains en une vingtaine de minutes. La valeur des actifs concernés est estimée à environ 6,34 milliards de dollars. À ce jour, Binance a gelé ou intercepté environ 2,85 milliards de dollars et s’est engagée à assumer elle-même les pertes financières, en réservant des fonds pour protéger les intérêts des utilisateurs.
L’enseignement technique le plus important de cet incident tient à cette question : pourquoi les actifs ont-ils continué à sortir après la suspension du service de retrait par la plateforme ? Selon l’idée reçue, fermer les canaux de retrait d’une plateforme d’échange suffit à interrompre les sorties de fonds. Mais cette attaque a exploité une particularité du mécanisme EIP-7702 d’Ethereum. Celui-ci permet à un compte ordinaire de désigner du code de contrat intelligent chargé d’exécuter des opérations, au moyen d’une autorisation signée. En exploitant le service de signature compromis, les attaquants ont mis en place une délégation malveillante on-chain, qui a conféré à leurs contrats intelligents un droit d’exécution partiel sur les portefeuilles chauds. Dès qu’une telle autorisation est inscrite sur la blockchain, elle existe indépendamment des services centralisés de la plateforme. Même après la fermeture par Binance de l’interface de retrait sur son site web, ces autorisations on-chain déjà actives sont restées valides. Les attaquants ont donc pu déclencher directement des transactions en utilisant les droits accordés, sans avoir à obtenir l’approbation de la plateforme. En outre, comme les portefeuilles chauds concernés reposaient sur la technologie du calcul multipartite (MPC), la signature nécessitait la coopération de plusieurs parties et aucune clé privée unique ne pouvait être désactivée d’urgence. L’équipe a donc dû mettre au point une procédure de révocation spécifique, ce qui lui a fait perdre un temps précieux. Ce n’est qu’à 00 h 10 UTC le 30 octobre que Binance a émis une nouvelle autorisation depuis le portefeuille chaud afin de supprimer le code de délégation malveillant. Le dernier transfert non autorisé, lui, avait été inscrit sur la blockchain à 23 h 56 UTC le 29 octobre. Ce décalage montre que « bloquer les nouvelles requêtes » et « révoquer les autorisations existantes » sont deux opérations techniques complètement différentes : la première consiste à désactiver un service, la seconde à modifier l’état de la blockchain.
Du point de vue de la gestion des risques, cet incident remet en cause l’idée reçue selon laquelle « tant que la clé privée n’a pas été divulguée, les fonds sont en sécurité ». Les attaquants n’ont pas volé directement la clé privée complète : ils ont utilisé la capacité de signature du système, en faisant signer par un service interne des transactions non approuvées. Cela montre que le périmètre de sécurité des actifs numériques ne se limite plus à la conservation des clés, mais s’étend au contrôle dynamique des autorisations. Dans son communiqué du 31 octobre, le FBI a attribué ce vol aux activités de TraderTraitor liées à la Corée du Nord, soulignant ainsi la capacité des attaques soutenues par des États à pénétrer les défenses de sécurité traditionnelles. Pour le secteur, le cas de Binance constitue une leçon sévère, mais nécessaire : tout en adoptant de nouvelles technologies comme le MPC et les outils d’IA pour gagner en efficacité, il faut réexaminer les principes fondamentaux de la réponse aux urgences. Les équipes d’ingénierie ne peuvent pas s’en remettre à la seule mesure consistant à « fermer le service ». Elles doivent mettre en place une voie d’urgence indépendante des processus opérationnels habituels et dont l’efficacité a été vérifiée à l’avance par des exercices. Par ailleurs, les systèmes de signature doivent distinguer rigoureusement les demandes de transfert ordinaires des demandes d’autorisation qui modifient les droits d’exécution d’un compte : une fois activées, ces dernières produisent des effets durables, difficiles à inverser immédiatement. L’incident a été en grande partie contenu, mais le défi technique qu’il laisse derrière lui — comment mettre en place un arrêt d’urgence de type centralisé sur une blockchain décentralisée — reste une question à laquelle tous les fournisseurs d’infrastructures crypto doivent faire face et apporter une réponse.
Suivez-moi pour ne pas manquer le prochain décryptage rapide des marchés.
