Le « déroulé complet de l’attaque » à 6,3 milliards vient enfin d’être révélé : ni trahison d’un employé de l’intérieur, ni erreur sur un ordinateur — mais une infiltration minutieusement préparée pendant cinq mois.
Binance a publié hier son rapport d’analyse de l’incident, qui reconstitue toute la chaîne d’attaque du plus grand vol de cryptomonnaies de l’histoire, survenu le 29 octobre :
Première étape, juin. Un ingénieur DevOps de l’équipe portefeuille cherchait un outil de programmation IA sur un moteur de recherche. Il a téléchargé un paquet d’installation Homebrew contaminé par une publicité Google malveillante : son ordinateur a été infecté. L’équipe de sécurité de Binance l’a détecté à l’époque et a remplacé l’appareil, mais elle a manqué la deuxième vague : les pirates ont supprimé l’exécutable pyenv légitime et l’ont remplacé par une version malveillante, installant une porte dérobée sans déclencher d’alerte du logiciel de protection des terminaux.
Deuxième étape, septembre. Un deuxième ingénieur s’est fait piéger par un « faux entretien » sur une plateforme de recrutement : d’abord, un entretien vidéo avec une vraie personne ; les RH lui ont même envoyé un compte de réseau social personnel avec des photos pour gagner sa confiance. Au deuxième tour, il a eu affaire au « PDG d’une entreprise qui n’existait pas ». Enfin, on lui a envoyé un « exercice de programmation » qui, une fois lancé, était en réalité un cheval de Troie zero-day. En quelques mois, les pirates avaient ainsi accumulé les accès de plusieurs ingénieurs.
Troisième étape, le 20 octobre. À l’aide de l’ordinateur du deuxième ingénieur et en passant par un outil d’IA interne à Binance, les pirates ont progressé latéralement jusqu’aux machines du premier ingénieur et d’un troisième ingénieur de l’équipe portefeuille. Le 29 octobre, entre 17:15 et 19:56, ils se sont connectés à l’ordinateur du troisième ingénieur, ont déployé des conteneurs et exécuté des scripts malveillants : les actifs d’une valeur de 6,34 milliards de dollars ont commencé à être transférés.
La phrase du rapport qui mérite le plus d’être examinée est son explication : pourquoi a-t-il été impossible de bloquer les fonds pendant près de deux heures après le premier transfert suspect ? Parce que les portefeuilles chauds utilisent le calcul multipartite MPC : il n’existe pas de clé privée unique permettant d’« annuler en un clic » une autorisation EIP-7702 malveillante. Une conception de sécurité qui élimine les points de défaillance uniques est précisément devenue le maillon le plus lent lors de la réponse à l’incident. Pour la première fois, le compromis entre sécurité et rapidité d’endiguement a coûté aussi cher.
Côté chiffres : environ 2,85 milliards de dollars ont été gelés ou bloqués ; 98 % des actifs touchés ont été reconstitués à partir des réserves de l’entreprise, et les utilisateurs ne subiront aucune perte. He Yi a démenti la théorie de la « taupe » et Teng a reconnu sur CNBC : « Cela n’aurait pas dû arriver. Nous en assumons l’entière responsabilité. »
Mais ne vous laissez pas induire en erreur par les « 98 % reconstitués ». Si Binance a pu le faire, c’est parce que c’est Binance. Une attaque de la même ampleur contre une plateforme d’échange de taille moyenne ou petite se solderait par une faillite pure et simple : il n’y aurait pas de 98 % à reconstituer. La véritable leçon de cette affaire n’est pas que « Binance est très sûre », mais que « seule Binance peut se permettre de payer cette leçon ».
À noter au passage : Binance affirme avoir bloqué cette année 57 cybermenaces présumées liées à la Corée du Nord. Le FBI attribue le vol des 6,3 milliards au groupe TraderTraitor, mais les méthodes d’attaque — faux entretiens, outils de développement infectés, outils d’IA compromis — reposent toutes sur des choses que chaque développeur utilise au quotidien. La surface d’attaque a déjà changé ; les mesures de défense, elles, n’ont pas suivi.
Recherche personnelle, ceci ne constitue pas un conseil en investissement.
$BNB $BTC
#币安 #黑客攻击 #网络安全 #SécuritéDesPlateformesD’échange
Binance a publié hier son rapport d’analyse de l’incident, qui reconstitue toute la chaîne d’attaque du plus grand vol de cryptomonnaies de l’histoire, survenu le 29 octobre :
Première étape, juin. Un ingénieur DevOps de l’équipe portefeuille cherchait un outil de programmation IA sur un moteur de recherche. Il a téléchargé un paquet d’installation Homebrew contaminé par une publicité Google malveillante : son ordinateur a été infecté. L’équipe de sécurité de Binance l’a détecté à l’époque et a remplacé l’appareil, mais elle a manqué la deuxième vague : les pirates ont supprimé l’exécutable pyenv légitime et l’ont remplacé par une version malveillante, installant une porte dérobée sans déclencher d’alerte du logiciel de protection des terminaux.
Deuxième étape, septembre. Un deuxième ingénieur s’est fait piéger par un « faux entretien » sur une plateforme de recrutement : d’abord, un entretien vidéo avec une vraie personne ; les RH lui ont même envoyé un compte de réseau social personnel avec des photos pour gagner sa confiance. Au deuxième tour, il a eu affaire au « PDG d’une entreprise qui n’existait pas ». Enfin, on lui a envoyé un « exercice de programmation » qui, une fois lancé, était en réalité un cheval de Troie zero-day. En quelques mois, les pirates avaient ainsi accumulé les accès de plusieurs ingénieurs.
Troisième étape, le 20 octobre. À l’aide de l’ordinateur du deuxième ingénieur et en passant par un outil d’IA interne à Binance, les pirates ont progressé latéralement jusqu’aux machines du premier ingénieur et d’un troisième ingénieur de l’équipe portefeuille. Le 29 octobre, entre 17:15 et 19:56, ils se sont connectés à l’ordinateur du troisième ingénieur, ont déployé des conteneurs et exécuté des scripts malveillants : les actifs d’une valeur de 6,34 milliards de dollars ont commencé à être transférés.
La phrase du rapport qui mérite le plus d’être examinée est son explication : pourquoi a-t-il été impossible de bloquer les fonds pendant près de deux heures après le premier transfert suspect ? Parce que les portefeuilles chauds utilisent le calcul multipartite MPC : il n’existe pas de clé privée unique permettant d’« annuler en un clic » une autorisation EIP-7702 malveillante. Une conception de sécurité qui élimine les points de défaillance uniques est précisément devenue le maillon le plus lent lors de la réponse à l’incident. Pour la première fois, le compromis entre sécurité et rapidité d’endiguement a coûté aussi cher.
Côté chiffres : environ 2,85 milliards de dollars ont été gelés ou bloqués ; 98 % des actifs touchés ont été reconstitués à partir des réserves de l’entreprise, et les utilisateurs ne subiront aucune perte. He Yi a démenti la théorie de la « taupe » et Teng a reconnu sur CNBC : « Cela n’aurait pas dû arriver. Nous en assumons l’entière responsabilité. »
Mais ne vous laissez pas induire en erreur par les « 98 % reconstitués ». Si Binance a pu le faire, c’est parce que c’est Binance. Une attaque de la même ampleur contre une plateforme d’échange de taille moyenne ou petite se solderait par une faillite pure et simple : il n’y aurait pas de 98 % à reconstituer. La véritable leçon de cette affaire n’est pas que « Binance est très sûre », mais que « seule Binance peut se permettre de payer cette leçon ».
À noter au passage : Binance affirme avoir bloqué cette année 57 cybermenaces présumées liées à la Corée du Nord. Le FBI attribue le vol des 6,3 milliards au groupe TraderTraitor, mais les méthodes d’attaque — faux entretiens, outils de développement infectés, outils d’IA compromis — reposent toutes sur des choses que chaque développeur utilise au quotidien. La surface d’attaque a déjà changé ; les mesures de défense, elles, n’ont pas suivi.
Recherche personnelle, ceci ne constitue pas un conseil en investissement.
$BNB $BTC
#币安 #黑客攻击 #网络安全 #SécuritéDesPlateformesD’échange
