Drainage des approbations Seneca Chamber

Le 28 février 2024, le protocole de stablecoin Seneca a perdu 6,4 millions de dollars drainés à des utilisateurs ayant accordé des approbations de jetons illimitées au contrat Chamber du protocole. Le contrat ne disposait d'aucune fonction Pausable — lorsque l'attaque a été identifiée, l'équipe n'avait aucun moyen de l'arrêter en cours. L'attaquant a rendu 80 % des fonds volés contre une prime de 20 %.

Ce qui s'est passé

Le contrat Chamber de Seneca était un chemin privilégié qui gérait les mouvements de jetons au nom des utilisateurs ayant approuvé Seneca à dépenser leurs jetons. Le contrat manquait une validation critique : il acceptait des paramètres fournis par l'appelant déterminant les jetons à déplacer et leur destination, sans vérifier que l'opération était autorisée par l'utilisateur concerné.

Pour les utilisateurs ayant accordé au contrat Chamber de Seneca des approbations de jetons illimitées — schéma standard pour tout protocole DeFi qui doit déplacer des jetons utilisateurs en routine — la validation manquante signifiait que tout appelant pouvait :

1. Identifier un portefeuille avec une approbation illimitée active envers Seneca.
2. Appeler la fonction vulnérable de Chamber avec l'adresse de la victime comme source et l'adresse de l'attaquant comme destination.
3. Drainer directement les jetons approuvés de la victime.

L'attaque a balayé ~6,4 M$ sur plusieurs portefeuilles victimes dans une courte fenêtre.

Aggravant l'échec : le contrat de Seneca n'avait jamais implémenté le pattern Pausable — une primitive OpenZeppelin standard qui permet à l'admin d'un protocole de mettre en pause des fonctions spécifiques ou l'intégralité du contrat en cas d'urgence. Lorsque l'équipe a pris connaissance de l'exploit en cours, elle n'avait aucun moyen de l'arrêter. Le drainage s'est poursuivi tout le temps que l'attaquant a choisi d'opérer.

Conséquences

• Seneca a publiquement engagé l'attaquant en offrant une prime de 20 % pour la restitution des fonds.
• Le 29 février, l'attaquant a retourné environ 1 537 ETH (~5,3 M$) à une adresse de récupération contrôlée par Seneca, conservant 300 ETH (~1 M$) comme prime.
• Seneca a interrompu les opérations — en recommandant aux utilisateurs de révoquer toutes les approbations au contrat Chamber, puisque le protocole lui-même ne pouvait être mis en pause.
• L'équipe a livré un protocole redessiné avec des contrôles Pausable et validation des paramètres ; la restauration de la confiance plus large a été inégale.

Pourquoi c'est important

L'incident Seneca est l'exemple type illustrant pourquoi les fonctions de pause d'urgence ne sont pas optionnelles pour tout protocole détenant des approbations utilisateurs. Le pattern Pausable est :

• Documenté dans la bibliothèque de contrats standard d'OpenZeppelin.
• Disponible comme modifier d'une seule ligne protégeant n'importe quelle fonction.
• Trivial à implémenter au moment du déploiement.

Pourtant, il avait été omis du contrat de Seneca — très probablement comme choix de conception délibéré, pour maximiser la « décentralisation » en supprimant les points de contrôle administratifs. Le coût de cette décision : l'équipe est devenue spectatrice durant un drainage actif des fonds de ses utilisateurs.

Les leçons structurelles :

1. Justifier l'absence de contrôles de sécurité par la décentralisation est un motif récurrent produisant des pertes récurrentes. Le compromis — « pas de pause admin » vs « les utilisateurs absorbent l'impact total de chaque bug » — est rarement présenté aussi clairement aux utilisateurs au moment du dépôt.

2. Les protocoles basés sur les approbations héritent de la responsabilité d'être mis en pause en sécurité car chaque utilisateur qui les a approuvés est exposé à chaque bug futur. La barre pour ces protocoles devrait être plus haute, pas plus basse, que pour des protocoles à exposition bornée.

3. Le retour de 80 % est l'un de plusieurs cas récents où des attaquants ont choisi de négocier plutôt que blanchir — probablement parce que la forensique on-chain est devenue suffisamment bonne pour rendre risqué et lent l'encaissement complet d'un exploit de 6 M$. La prime effective de 1 M$ sur une opération de 6,4 M$ a pu être le choix rationnel.

Les protocoles modernes livrent de plus en plus avec Pausable + multi-sig d'urgence + disjoncteurs contrôlés par la communauté en standard. La perte de Seneca est l'un des incidents ayant rendu ces patterns obligatoires plutôt qu'optionnels.