Skip to content

exploit

Base : 1 783 wstETH (6 M$) vidés d'un vault après deux signatures du multisig Safe

Un vault sur Base perd 1 783 wstETH via Aave V3 : la multisig 3/7 whitelist un contrat attaquant, le retire, le réintègre en moins de deux minutes. 31,7 M$ encore exposés.

par 3 min de lecture

Un vault de rendement non identifié sur Base a perdu 1 783 wstETH, soit environ 6 millions de dollars, le 4 octobre, après que sa multisig Safe 3/7 a validé l'accès d'un contrat attaquant — deux fois en moins de deux minutes. Les trois mêmes signatures ont approuvé le retrait du contrat de la whitelist, puis sa réintégration quatre-vingt-dix secondes plus tard. Environ 31,7 millions de dollars d'actifs restent détenus sous la même multisig.

Ce qui s'est passé

Un contrat fraîchement déployé a été inscrit sur la whitelist de permissions du vault, puis a emprunté 1 783 aBaswstETH sur le déploiement Aave V3 de Base, transféré les jetons vers une adresse contrôlée par l'attaquant, et racheté le wstETH sous-jacent, d'après le reconstitutif on-chain de Journal du Coin. Chaque transaction Safe portait les trois signatures requises des mêmes signataires.

Les contrats cœur d'Aave V3 ne sont pas compromis, et Base non plus. La perte repose entièrement sur la conception de permissionnement du vault et sur son signer set.

Les chiffres

  • Volé : 1 783 wstETH (~6,0 M$ au cours wstETH/USD du moment)
  • Encore exposés sous la même multisig : ~31,7 M$
  • Seuil multisig : 3 sur 7
  • Délai entre retrait et réintégration du contrat attaquant : ~90 secondes
  • Dernière transaction du Safe sur le contrat de trésorerie avant l'exploit : ~25 jours plus tôt

Mécanisme

Les vaults qui filtrent l'accès par whitelist délèguent la totalité du risque au signer set. Si le Safe approuve un contrat malveillant, aucune seconde barrière ne se déclenche — pas de timelock, pas d'oracle, pas de comité de risque. Dans cet incident, les trois signataires qui ont approuvé le contrat attaquant sont les mêmes qui ont ensuite voté sa réintégration quelques minutes plus tard. L'enchaînement exclut une erreur opérationnelle isolée et pointe vers une compromission de signataire, une opération de social engineering, ou une action coordonnée en interne.

L'analyse on-chain relève vingt-cinq jours d'inactivité sur le Safe avant l'attaque — fenêtre suffisante pour mener une campagne de phishing ciblant un ou plusieurs signataires.

Que surveiller

  1. Les 31,7 M$ restants. La même multisig les contrôle. Tout mouvement sortant du Safe est désormais un signal direct de l'état du signer set.
  2. Une revendication d'équipe. Aucun protocole n'a publiquement reconnu la propriété du vault ni publié de post-mortem. Si une équipe détient cette trésorerie, le silence est en soi une information.
  3. L'identification des signataires. Les trois signataires qui ont approuvé les transactions attaquantes sont visibles on-chain. L'attribution à des identités réelles dépend du public reconnaissant les clés.
  4. La suite côté DeFi Base. C'est le quatrième incident lié à l'outillage Aave sur Base en une semaine. La gouvernance Aave pourrait réévaluer les garde-fous imposés aux intégrateurs permissionnés du déploiement Base.

Contexte

Les vaults filtrés par whitelist ont été la surface d'attaque de plusieurs incidents à plusieurs millions de dollars cette année. Le dénominateur commun : la multisig Safe fait office d'unique ligne de défense, et une fois compromise, rien ne retarde l'exécution. Le motif a poussé certains protocoles à insérer un Timelock entre un Safe et les appels privilégiés d'un contrat. Ce vault n'en avait pas. Pour les lecteurs qui suivent la trajectoire Base, c'est quatre incidents en sept jours sur la seule surface d'exposition à l'outillage Aave.

Articles liés