La bot Yoink détourne 7,8 millions de dollars d’un wallet Gnosis Safe
Des sociétés de sécurité pointent une erreur dans un helper contract de confiance, et non dans le cœur de Safe. Kelp DAO affirme que le rsETH reste couvert ; l’attaque a en outre été devancée par une bot de frontrunning.
À retenir
- Un attaquant a retiré environ 2 900 rsETH, d’une valeur de 7,8 millions de dollars, d’un wallet Gnosis Safe sur Ethereum.
- La transaction a été frontrunnée par la bot Yoink, qui a payé environ 47 000 dollars et a envoyé 2 882 rsETH vers une autre adresse.
- L’erreur se trouvait dans une vérification d’autorisation d’un helper contract et d’un contrat Multicall de confiance, et non dans les contrats cœur de Safe.
Un attaquant a retiré sur Ethereum environ 2 900 rsETH, pour une valeur d’environ 7,8 millions de dollars (6,8 millions d'euros), d’un wallet Gnosis Safe. Selon les sociétés de sécurité BlockSec, Blockaid et SlowMist, l’attaque a ensuite été devancée par la bot Yoink, qui a frontrunné la transaction et a envoyé les tokens vers une autre adresse.
Comment l’attaque a fonctionné
Le wallet était configuré de manière à ce qu’un helper contract puisse déplacer des fonds, une configuration fréquente chez les personnes qui automatisent leurs opérations. Selon SlowMist et BlockSec, ce helper devait vérifier si l’appelant avait l’autorisation, mais cette vérification s’est révélée valider toute personne que le helper lui-même désignait comme cible.
L’attaquant a ensuite converti environ 2 900 rsETH dans un pool de trading mis en place quelques minutes plus tôt autour d’un token sans valeur appelé Permissionless Attacker Token. Il ne restait donc au wallet qu’un reçu sans valeur. Selon les sociétés de sécurité, Yoink a payé environ 47 000 dollars (40 700 euros) pour passer en priorité et a finalement emporté 2 882 rsETH vers une adresse distincte.
L’erreur se trouvait dans un composant de confiance
AstraSec a écrit sur X que le cœur du problème venait d’une vérification d’autorisation erronée dans le contrat Multicall. D’autres sociétés de sécurité sont arrivées à la même conclusion : l’erreur se trouvait dans un composant auquel le propriétaire du wallet avait lui-même accordé sa confiance, et non dans les contrats cœur de Safe.
Cette distinction est importante, car de nombreux utilisateurs de crypto activent des fonctions supplémentaires via des wallets et des helper contracts pour le trading ou l’automatisation. Une précédente enquête portant sur des dizaines de grandes attaques de smart contracts avait déjà montré que les hacks réussis ne reposent souvent pas seulement sur un bug technique, mais aussi sur des choix humains et des hypothèses fragiles concernant l’usage et l’autorisation. Le glissement vers des attaques sur les clés et la gouvernance montre aussi que les attaquants visent de plus en plus le maillon le plus faible autour de l’accès et de la gestion, et pas seulement le code lui-même.
Pourquoi cela compte pour les utilisateurs
Kelp DAO, l’émetteur du rsETH, a indiqué que ses contracts sont sûrs et que le rsETH est entièrement couvert. L’entreprise a également précisé qu’elle avait temporairement suspendu pendant 24 heures une adresse ayant reçu du rsETH quelques heures plus tôt, afin que le token ne puisse ni entrer ni sortir de cette adresse.
Pour les utilisateurs européens de crypto, cet incident montre que les risques ne se situent pas seulement dans un protocole lui-même, mais aussi dans les couches supplémentaires autour, comme les helper contracts et le trading automatisé. En particulier, pour les wallets qui combinent plusieurs fonctions, une petite erreur dans le contrôle d’accès peut suffire à provoquer une perte importante.
