Dans cette affaire de sécurité chez Binance, je trouve qu’un détail mérite davantage réflexion que le transfert de plusieurs milliards de dollars d’actifs.
La compromission des clés privées n’a pas été confirmée, et pourtant les attaquants ont réussi à transférer des actifs. Comment ont-ils fait ?
En clair, cet incident a peut-être mis en lumière un problème que beaucoup ont tendance à négliger : la plus grande faille de sécurité d’une plateforme d’échange ne se trouve pas forcément dans les portefeuilles, mais peut se situer en dehors de ceux-ci.
Selon les premières informations communiquées par Binance, l’attaque aurait pu commencer par la compromission de l’ordinateur portable d’un ingénieur DevOps, avant de toucher des conteneurs de services internes et le processus de retrait.
Par la suite, GCSA a mené une analyse forensique on-chain et réexaminé 18 transactions d’origine, 50 signatures d’autorisation initiales EIP-7702 ainsi qu’une signature de révocation d’autorisation.
Un détail technique mérite ici d’être relevé : une transaction de type 4 peut contenir 50 autorisations, mais cela ne signifie pas que les 50 ont toutes été activées. La validité d’une signature ne prouve pas non plus que la clé privée a été volée.
Le rapport a également retracé trois transactions consécutives liées au MetaMask Gas Station et constaté que le montant d’ETH déposé au préalable correspondait exactement au budget maximal de gas des deux transactions suivantes.
Quant aux affirmations selon lesquelles l’attaquant aurait choisi le mauvais USDT ou que MetaMask aurait eu connaissance de la véritable adresse IP, elles ne sont pour l’instant étayées par aucune preuve suffisante.
TRM Labs a associé l’incident avec un haut degré de confiance au groupe de menace nord-coréen TraderTraitor, mais cela ne signifie pas pour autant que l’identité des attaquants et leur mode opératoire ont été entièrement reconstitués.
J’ai toujours pensé que la sécurité des plateformes d’échange ne devait pas se focaliser uniquement sur les portefeuilles froids, les signatures multiples et les clés privées.
Ordinateurs des employés, autorisations internes, environnement DevOps, services de signature, validation des retraits, voire infrastructures tierces : une défaillance à n’importe quel maillon peut rendre tout le système de sécurité des actifs illusoire.
Autre point : l’estimation de l’impact de l’incident, à environ 6,3 milliards de dollars, ne correspond pas à la perte nette finale, et le gel des fonds ne signifie pas qu’ils ont été récupérés.
Ce que l’ensemble du secteur devrait véritablement retenir de cet incident, c’est ceci : si un attaquant peut mobiliser des actifs sans avoir besoin d’obtenir directement les clés privées, alors la conception que nous avions jusqu’ici du périmètre de sécurité des plateformes d’échange ne suffit peut-être plus.
La compromission des clés privées n’a pas été confirmée, et pourtant les attaquants ont réussi à transférer des actifs. Comment ont-ils fait ?
En clair, cet incident a peut-être mis en lumière un problème que beaucoup ont tendance à négliger : la plus grande faille de sécurité d’une plateforme d’échange ne se trouve pas forcément dans les portefeuilles, mais peut se situer en dehors de ceux-ci.
Selon les premières informations communiquées par Binance, l’attaque aurait pu commencer par la compromission de l’ordinateur portable d’un ingénieur DevOps, avant de toucher des conteneurs de services internes et le processus de retrait.
Par la suite, GCSA a mené une analyse forensique on-chain et réexaminé 18 transactions d’origine, 50 signatures d’autorisation initiales EIP-7702 ainsi qu’une signature de révocation d’autorisation.
Un détail technique mérite ici d’être relevé : une transaction de type 4 peut contenir 50 autorisations, mais cela ne signifie pas que les 50 ont toutes été activées. La validité d’une signature ne prouve pas non plus que la clé privée a été volée.
Le rapport a également retracé trois transactions consécutives liées au MetaMask Gas Station et constaté que le montant d’ETH déposé au préalable correspondait exactement au budget maximal de gas des deux transactions suivantes.
Quant aux affirmations selon lesquelles l’attaquant aurait choisi le mauvais USDT ou que MetaMask aurait eu connaissance de la véritable adresse IP, elles ne sont pour l’instant étayées par aucune preuve suffisante.
TRM Labs a associé l’incident avec un haut degré de confiance au groupe de menace nord-coréen TraderTraitor, mais cela ne signifie pas pour autant que l’identité des attaquants et leur mode opératoire ont été entièrement reconstitués.
J’ai toujours pensé que la sécurité des plateformes d’échange ne devait pas se focaliser uniquement sur les portefeuilles froids, les signatures multiples et les clés privées.
Ordinateurs des employés, autorisations internes, environnement DevOps, services de signature, validation des retraits, voire infrastructures tierces : une défaillance à n’importe quel maillon peut rendre tout le système de sécurité des actifs illusoire.
Autre point : l’estimation de l’impact de l’incident, à environ 6,3 milliards de dollars, ne correspond pas à la perte nette finale, et le gel des fonds ne signifie pas qu’ils ont été récupérés.
Ce que l’ensemble du secteur devrait véritablement retenir de cet incident, c’est ceci : si un attaquant peut mobiliser des actifs sans avoir besoin d’obtenir directement les clés privées, alors la conception que nous avions jusqu’ici du périmètre de sécurité des plateformes d’échange ne suffit peut-être plus.