Gouvernance malveillante d'Atlantis Loans

Le 23 juin 2023, le protocole de prêt sur BNB Chain Atlantis Loans a subi une attaque de gouvernance qui a drainé environ 2,5 millions de dollars depuis les utilisateurs. Une proposition de gouvernance malveillante — soumise et adoptée avec une attention minimale de la communauté — a mis à jour les contrats de tokens du protocole pour accorder à l'attaquant une autorisation de dépense sur chaque wallet ayant déjà interagi avec Atlantis.

Ce qui s'est passé

Atlantis Loans était gouverné par un DAO on-chain dont les propositions pouvaient modifier les contrats du protocole. L'attaque a abusé directement de ce pouvoir de gouvernance :

1. L'attaquant a acquis suffisamment de tokens de gouvernance pour soumettre et faire adopter une proposition (la participation à la gouvernance du protocole était faible, abaissant le seuil).
2. La proposition — déguisée ou simplement non remarquée par la petite communauté active — a modifié les contrats du protocole pour ajouter un approve accordant à l'adresse de l'attaquant une allowance sur les tokens de chaque utilisateur ayant interagi avec Atlantis.
3. La proposition a été adoptée et exécutée via le flux de gouvernance normal.
4. Une fois les approbations malveillantes vivantes on-chain, l'attaquant a appelé transferFrom sur le solde de chaque utilisateur affecté, drainant ~2,5 M$ en tokens.

Le drainage a frappé les wallets propres des utilisateurs, pas seulement les réserves du protocole — quiconque avait déjà accordé des approbations de tokens à Atlantis (le schéma standard pour tout protocole de prêt DeFi) était exposé.

Conséquences

• Atlantis Loans a diffusé en urgence à tous les utilisateurs de révoquer les approbations aux contrats du protocole.
• Beaucoup d'utilisateurs ayant agi rapidement ont évité la perte ; ceux qui n'ont pas vu l'avertissement à temps ont été drainés.
• Le protocole a effectivement cessé ; aucune récupération significative.

Pourquoi c'est important

Atlantis Loans est une étude de cas claire pour la gouvernance comme vecteur d'attaque contre les utilisateurs, pas seulement contre le trésor. La plupart des discussions sur les attaques de gouvernance se concentrent sur le vol des fonds du protocole (Beanstalk, Audius). Atlantis est plus insidieux : la proposition malveillante n'a pas drainé un trésor — elle a militarisé les approbations de tokens existantes du protocole contre ses propres utilisateurs.

Leçons structurelles :

1. La gouvernance à faible participation est une vulnérabilité permanente. Quand la gouvernance d'un protocole peut être adoptée par une petite position en tokens et que la communauté active est suffisamment petite pour que les propositions passent sans examen, la gouvernance est effectivement une clé admin non gardée. La défense — exigences de quorum, timelocks suffisamment longs pour la revue communautaire, monitoring du contenu des propositions — est bien documentée mais inégalement appliquée, surtout sur les plus petits protocoles.

2. La gouvernance peut modifier les contrats que les utilisateurs ont approuvés. Les utilisateurs accordant une « approbation illimitée » à un protocole de prêt font implicitement confiance non seulement au code actuel mais à tout ce que le système de gouvernance peut transformer le code en. C'est la même généralisation que l'attaque de gouvernance de Tornado Cash a faite un mois plus tôt : le code que vous avez approuvé n'est pas nécessairement le code qui s'exécutera.

3. La révocation des approbations est la seule défense côté utilisateur, et elle est réactive. Au moment où la proposition malveillante s'exécute, la seule chose qu'un utilisateur peut faire est de révoquer plus vite que l'attaquant ne peut faire transferFrom. Le correctif structurel — approbations bornées/expirantes — limite ce rayon d'impact, ce qui est l'une des principales raisons pour lesquelles les wallets modernes les ont par défaut.

Atlantis Loans, gouvernance Tornado Cash et Beanstalk forment ensemble l'illustration centrale du catalogue que la gouvernance on-chain est un mécanisme privilégié de modification de code, et tout mécanisme privilégié de modification de code est une surface d'attaque proportionnelle à la facilité avec laquelle il peut être capturé.