La multi-signature n’a pas été piratée, et les 7,8 millions de dollars sont quand même sortis du portefeuille
Le 15 septembre, un portefeuille Ethereum Safe a subi une perte d’environ 2900 unités de rsETH, soit une valeur d’environ 7,8 millions de dollars. Le problème ne vient ni du contrat central de Safe, ni d’une fuite des clés privées de la multi-signature, mais d’un module auxiliaire que le portefeuille avait autorisé auparavant.
Ce module était à l’origine destiné à exécuter automatiquement des opérations de liquidité. Son contrôle des autorisations a cependant pris à tort le fait que la « cible de l’appel est le module lui-même » pour une autorisation légitime. L’attaquant a pu ainsi injecter n’importe quelle instruction, et Safe a ensuite transféré les fonds, comme s’il exécutait une opération normale du module.
Cela met en lumière un point souvent mal compris à propos des multi-signatures : le schéma M-of-N ne contraint que le nombre de clés nécessaires pour approuver les transactions ordinaires. Les modules activés peuvent disposer de capacités leur permettant de contourner le processus de signature classique et d’appeler directement le portefeuille. Même avec une porte-forte (multi-signature) verrouillée, des modules d’automatisation autorisés à long terme peuvent devenir une porte dérobée.
Le plus dramatique, c’est que, une fois la transaction d’attaque entrée dans le mempool public, un robot MEV l’a exécutée en premier. Le robot a payé environ 46 000 dollars pour obtenir le bon ordre d’exécution, et a finalement intercepté environ 2882 unités de rsETH. La transparence on-chain rend l’attaque observable, et permet aussi à des tiers de la dupliquer et de se la faire « devancer ».
Les coffres d’entreprise et les utilisateurs DeFi ne doivent pas seulement auditer les signataires : ils doivent aussi, régulièrement, lister les modules activés, les plafonds de dépenses et les contrats autorisés. Désactiver les modules non nécessaires et limiter les permissions d’automatisation à des actifs, des objectifs et des montants précis.
La sécurité d’un portefeuille ne dépend pas seulement de qui détient les clés : elle dépend aussi de quels contrats sont déjà autorisés à entrer sans frapper.
#SécuritéDePortefeuille #MultiSignature #DeFi
Le 15 septembre, un portefeuille Ethereum Safe a subi une perte d’environ 2900 unités de rsETH, soit une valeur d’environ 7,8 millions de dollars. Le problème ne vient ni du contrat central de Safe, ni d’une fuite des clés privées de la multi-signature, mais d’un module auxiliaire que le portefeuille avait autorisé auparavant.
Ce module était à l’origine destiné à exécuter automatiquement des opérations de liquidité. Son contrôle des autorisations a cependant pris à tort le fait que la « cible de l’appel est le module lui-même » pour une autorisation légitime. L’attaquant a pu ainsi injecter n’importe quelle instruction, et Safe a ensuite transféré les fonds, comme s’il exécutait une opération normale du module.
Cela met en lumière un point souvent mal compris à propos des multi-signatures : le schéma M-of-N ne contraint que le nombre de clés nécessaires pour approuver les transactions ordinaires. Les modules activés peuvent disposer de capacités leur permettant de contourner le processus de signature classique et d’appeler directement le portefeuille. Même avec une porte-forte (multi-signature) verrouillée, des modules d’automatisation autorisés à long terme peuvent devenir une porte dérobée.
Le plus dramatique, c’est que, une fois la transaction d’attaque entrée dans le mempool public, un robot MEV l’a exécutée en premier. Le robot a payé environ 46 000 dollars pour obtenir le bon ordre d’exécution, et a finalement intercepté environ 2882 unités de rsETH. La transparence on-chain rend l’attaque observable, et permet aussi à des tiers de la dupliquer et de se la faire « devancer ».
Les coffres d’entreprise et les utilisateurs DeFi ne doivent pas seulement auditer les signataires : ils doivent aussi, régulièrement, lister les modules activés, les plafonds de dépenses et les contrats autorisés. Désactiver les modules non nécessaires et limiter les permissions d’automatisation à des actifs, des objectifs et des montants précis.
La sécurité d’un portefeuille ne dépend pas seulement de qui détient les clés : elle dépend aussi de quels contrats sont déjà autorisés à entrer sans frapper.
#SécuritéDePortefeuille #MultiSignature #DeFi