Qu’est-ce qu’une attaque de gouvernance dans la crypto et comment les protocoles peuvent-ils se protéger ?

Qu’est-ce qu’une attaque de gouvernance dans la crypto ?

Une attaque de gouvernance est une attaque dans laquelle une personne utilise ou prend le contrôle du processus de décision d’une DAO ou d’un protocole afin de mener une action (généralement) nuisible. Une DAO est une organisation qui prend des décisions au moyen de règles inscrites dans des smart contracts et des votes des participants.

Dans de nombreux protocoles, les tokens déterminent le droit de vote dont vous disposez. Celui qui accumule suffisamment de pouvoir de vote peut, par exemple, proposer de modifier des paramètres, d’ajouter de nouvelles fonctionnalités, de mettre à niveau la logique d’un contrat ou de déplacer des fonds depuis une treasury. Une treasury est, en termes simples, la réserve commune de ressources d’un protocole.

Toutes les attaques de gouvernance ne proviennent pas d’une erreur de programmation. Parfois, un attaquant suit simplement les règles formelles, mais rassemble suffisamment d’influence pour faire adopter une proposition nuisible aux autres utilisateurs. On parle alors de governance capture : dans les faits, le processus de décision passe sous le contrôle d’une seule partie ou d’un petit groupe.

Une technique possible consiste à utiliser un flash loan. Il s’agit d’un prêt qui doit être remboursé au cours de la même transaction sur la blockchain. Si un protocole base le poids de vote sur le nombre actuel de tokens dans un wallet, sans délai d’attente ni instantané historique, un attaquant peut temporairement obtenir un pouvoir de vote très important.

Exemple : supposons qu’un protocole attribue une voix à chaque token. Une personne emprunte temporairement un très grand nombre de tokens, vote en faveur d’une proposition visant à déplacer des fonds depuis la treasury, puis rembourse immédiatement le prêt. Si le système comptabilise ces tokens temporaires, cela peut suffire à influencer le vote.

À retenir

• Une attaque de gouvernance détourne le processus de décision d’une DAO ou d’un protocole à des fins nuisibles.
• Dans une gouvernance pondérée par les tokens, le nombre de tokens détermine souvent le droit de vote d’une personne.
• Une attaque peut exploiter une faille technique, mais elle peut aussi se produire dans le cadre des règles existantes.
• Les flash loans peuvent offrir temporairement un pouvoir de vote élevé si un protocole utilise les soldes actuels.
• Les propositions peuvent notamment modifier des paramètres, mettre à niveau des contrats ou déplacer des actifs de la treasury.

Comment fonctionne une attaque de gouvernance ?

Une attaque de gouvernance fonctionne généralement en trois temps : l’attaquant rassemble d’abord suffisamment de pouvoir de vote effectif, fait ensuite approuver une proposition nuisible, puis l’exécute. La manière exacte dépend des règles du protocole.

Le poids de vote peut par exemple provenir des tokens que vous détenez, des votes que d’autres vous délèguent, des tokens stakés ou de positions LP. Une position LP correspond à votre part dans une liquidity pool. Le point essentiel est le suivant : à quel moment le protocole fige-t-il le niveau de droit de vote dont vous disposez ?

En pratique, une attaque ressemble souvent à ceci :

1. Rassembler le droit de vote L’attaquant achète des tokens, collecte des délégations, utilise un pouvoir de vote déjà important ou emprunte temporairement des tokens via un flash loan.

2. Déposer une proposition La proposition contient une ou plusieurs actions que les smart contracts doivent exécuter. Il peut s’agir, par exemple, de modifications de paramètres, mais aussi d’une mise à niveau ou d’un transfert depuis la treasury.

3. Gagner le vote La proposition doit obtenir suffisamment de voix et atteindre le quorum requis. Un quorum est la quantité minimale de participation nécessaire pour qu’un vote soit valide.

4. Exécuter l’action Après un vote réussi, la gouvernance exécute les transactions prévues. Sans délai, cela peut se produire immédiatement. Avec un timelock, l’action doit d’abord attendre.

Un instantané historique aide à se protéger contre certaines attaques par flash loan. Un tel snapshot est, en réalité, une photo des droits de vote à un moment antérieur et fixe. Un voting delay, c’est-à-dire un délai d’attente avant que les votes soient pris en compte, ne fonctionne correctement que si les tokens empruntés temporairement ne figurent pas déjà sur cet instantané.

Beanstalk montre à quel point l’impact peut être important. Le 17 avril 2022, le protocole a été attaqué via une gouvernance on-chain. L’attaquant a utilisé un flash loan pour compromettre le mécanisme de gouvernance alors en place et retirer des actifs de la DAO.

Un snapshot n’est d’ailleurs pas une solution complète. Si un attaquant a déjà acheté les tokens ou les contrôle avant le moment choisi, ce pouvoir de vote est simplement pris en compte.

Quelles conséquences une attaque de gouvernance peut-elle avoir ?

Une attaque de gouvernance peut permettre à un attaquant de prendre le contrôle de fonds, de droits ou de paramètres importants d’un protocole. La gravité dépend entièrement de ce que la gouvernance a réellement le droit de faire.

Dans certains protocoles, la gouvernance peut notamment modifier les paramètres du système, ajouter de nouveaux marchés ou de nouvelles fonctionnalités et mettre à niveau des parties du protocole. Si la gouvernance contrôle aussi des proxies importants, des composants de configuration ou des contrats de treasury, une proposition malveillante peut causer des dégâts considérables.

Les conséquences possibles sont notamment :

• perte d’actifs de la treasury ou d’actifs d’utilisateurs ;
• minting non souhaité de nouveaux tokens ;
• modification de paramètres qui désavantage les utilisateurs ;
• changement des droits d’administration ;
• mise à niveau vers une logique de contrat nuisible ;
• arrêt temporaire ou total de certaines fonctionnalités.

Lors de l’attaque contre Beanstalk, tous les actifs des utilisateurs non-BEAN ont été volés le 17 avril 2022, pour une valeur d’environ 77 millions de dollars. Le protocole a ensuite été mis en pause, la gouvernance on-chain a été supprimée et le dispositif de gouvernance a été modifié.

Les dégâts dépassent souvent la seule perte directe. Un protocole peut devoir migrer vers de nouveaux contrats, payer des audits et des travaux de correction, et confier temporairement davantage de contrôle d’urgence à un petit groupe. Cela peut fortement ébranler la confiance des utilisateurs.

Comment un protocole peut-il perdre le contrôle ?

Un protocole perd concrètement le contrôle dès qu’un attaquant dispose de suffisamment de droits sur les contrats qui exécutent les actions critiques. Pensez au propriétaire d’un proxy, à un compte autorisé à effectuer des mises à niveau, à un rôle qui peut planifier des propositions dans un timelock ou au contrôleur de la treasury.

Un proxy est ici, en termes simples, une adresse de contrat fixe qui renvoie vers une certaine version de la logique du contrat. Dans un protocole évolutif, la gouvernance peut faire pointer cette adresse vers une nouvelle logique. Ainsi, une seule proposition approuvée peut modifier en profondeur le fonctionnement du protocole.

Pour cela, un attaquant n’a pas toujours besoin de la majorité de tous les détenteurs de tokens. En cas de faible participation, de quorum bas ou de délégations très concentrées, un groupe relativement restreint peut déjà disposer d’un pouvoir de vote effectif suffisant.

Après une exécution malveillante, la reprise peut devenir encore plus difficile. L’attaquant peut modifier des autorisations, transférer des actifs ou même changer les règles futures de gouvernance. Il est alors possible que la communauté ne puisse plus intervenir par la même voie, ou seulement beaucoup plus tard.

Une perte de contrôle peut aussi survenir sans attaque. Si les comptes autorisés d’un timelock autogéré ne sont plus disponibles, un contrat géré par ce timelock peut rester bloqué indéfiniment.

Comment les protocoles crypto et DeFi peuvent-ils se protéger ?

Les protocoles crypto et DeFi peuvent réduire le risque en évitant que le pouvoir de vote, les autorisations et l’exécution ne se retrouvent trop facilement réunis à un seul moment. Il n’existe pas de réglage magique qui bloque toutes les attaques, mais plusieurs couches de protection rendent l’abus plus difficile.

Les mesures importantes sont les suivantes :

1. Utiliser des snapshots et un voting delay Figer le poids de vote à un moment antérieur et prévoir un délai d’attente. Il devient alors plus difficile d’organiser temporairement des tokens juste avant un vote et de les utiliser immédiatement.

2. Choisir des seuils de vote adaptés Un seuil minimal pour déposer une proposition rend les propositions de spam bon marché plus difficiles. Un quorum empêche qu’une très faible participation décide seule. L’arbitrage reste délicat : des seuils trop bas facilitent la capture, tandis que des seuils trop élevés peuvent rendre la gouvernance impraticable.

3. Placer les actions sensibles derrière un timelock Les mises à niveau, les changements importants de paramètres et les actions de treasury n’ont pas besoin d’être exécutés immédiatement après un vote. Un timelock laisse aux utilisateurs le temps d’examiner une action planifiée et, si nécessaire, de fermer leur position.

4. Limiter les droits par rôle Ne donnez pas automatiquement à la gouvernance un pouvoir illimité. Les droits liés aux mises à niveau, au minting et aux appels externes illimités méritent des restrictions supplémentaires. Les droits d’urgence doivent être clairement délimités.

5. Tester les actions réelles des propositions Il ne suffit pas de vérifier uniquement le module de vote. Les équipes doivent aussi tester et simuler les transactions exactes derrière une proposition. Une proposition peut sembler inoffensive dans ses grandes lignes, alors que les appels concrets racontent une tout autre histoire.

6. Surveiller les propositions et le pouvoir de vote La surveillance n’empêche pas automatiquement une attaque, mais elle peut permettre de repérer à temps une proposition suspecte ou un déplacement important des délégations. Un plan d’incident défini à l’avance aide alors à réagir plus vite.

Les audits restent utiles, mais ils ne constituent pas une garantie. Toutes les attaques de gouvernance ne reposent pas sur une erreur de code. Des propositions trompeuses, une faible participation et des transactions mal évaluées peuvent aussi provoquer des problèmes.

Comment les timelocks et la gouvernance multisig peuvent-ils aider ?

Les timelocks et les multisigs peuvent constituer une couche de sécurité supplémentaire, car ils empêchent qu’un seul compte approuvé ou compromis puisse tout exécuter immédiatement.

Un timelockcontroller impose un délai minimal entre la planification et l’exécution d’une action importante. Si le timelock est l’administrateur d’un contrat, ce délai s’applique aussi aux actions qui pourraient autrement être exécutées immédiatement avec des droits d’administration.

Cette fenêtre de réaction est importante. Les utilisateurs et les chercheurs en cybersécurité peuvent examiner les données exactes de la transaction avant la mise en ligne du changement. En cas de proposition dangereuse, les utilisateurs peuvent par exemple fermer leur position avant l’exécution de l’action. Le timelock n’annule pas automatiquement une action nuisible, mais il ralentit une attaque visible.

Compound v2 utilise par exemple plusieurs phases : deux jours de revue, trois jours de vote, puis deux jours de timelock. Une modification du protocole y prend donc au minimum une semaine.

Un multisig fonctionne différemment. Plusieurs propriétaires doivent y confirmer une transaction. Dans un multisig 3 sur 5, trois signatures valides sont nécessaires. Une seule clé volée ou compromise ne suffit donc pas pour déplacer des fonds ou modifier des paramètres de manière autonome.

Un multisig peut par exemple être la seule partie autorisée à planifier des actions dans un timelock. Un groupe de signataires doit alors d’abord donner son accord, puis le délai défini commence.

Il faut toutefois garder un point important à l’esprit : un multisig déplace la confiance vers les signataires. Si suffisamment de signataires s’entendent, si trop de clés sont volées ou si les signataires ne sont pas joignables, des problèmes apparaissent malgré tout. Les modules ou extensions supplémentaires méritent aussi une attention particulière, car ils peuvent, dans certaines circonstances, exécuter des transactions en dehors du contrôle normal des signatures.

Quelles sont les limites de la gouvernance dans la crypto ?

La gouvernance dans la crypto peut exécuter des décisions de manière transparente et automatique, mais le système ne sait pas, à lui seul, si une proposition est aussi judicieuse ou équitable. Un vote on-chain valide prouve seulement que les règles ont été respectées.

Dans une gouvernance pondérée par les tokens, l’influence est liée au poids économique. Les gros détenteurs, les fonds et les delegates connus peuvent donc avoir beaucoup plus d’influence que les petits participants, même sans attaque ni erreur de code. La délégation facilite le vote, mais elle peut aussi concentrer le pouvoir entre les mains d’un petit groupe.

La vitesse et la sécurité s’opposent aussi parfois. Des périodes de vote plus longues et des timelocks donnent davantage de temps pour examiner correctement les propositions et réagir. En contrepartie, ils ralentissent les mises à niveau utiles, les ajustements et parfois aussi la réponse à un incident.

Les quorums et les seuils de proposition impliquent le même arbitrage. S’ils sont trop bas, un petit groupe bien organisé peut prendre des décisions. S’ils sont trop élevés, les propositions ordinaires peuvent rester bloquées faute de votes suffisants.

Un autre problème est la complexité. Les données calldata exactes d’une proposition, une mise à niveau de la logique d’un contrat ou l’interaction entre plusieurs smart contracts sont difficiles à évaluer pour de nombreux votants. Une proposition peut donc être correcte sur le plan procédural, alors que peu de personnes comprennent réellement ce qui se passe.

Un multisig ou un guardian peut réduire le risque d’une attaque rapide, mais il ajoute aussi des risques de centralisation et de disponibilité. Un guardian est un compte ou un groupe doté de droits d’urgence particuliers. Si une telle partie agit de mauvaise foi, n’est pas joignable ou bloque des transactions, cette couche de sécurité peut elle-même devenir un point faible.

La gouvernance n’est donc pas un réglage que l’on configure une fois pour toutes avant de l’oublier. La répartition des tokens, les délégations, les droits, les incitations, le contrôle des propositions et les procédures d’urgence doivent être réévalués régulièrement.

En résumé

Une attaque de gouvernance ne consiste pas seulement en des hackers qui trouvent une faille technique. Une partie qui rassemble suffisamment de pouvoir de vote dans le respect des règles peut aussi mettre un protocole en difficulté si la gouvernance dispose de trop de droits ou exécute les propositions trop rapidement.

Une bonne protection repose sur plusieurs couches : snapshots, voting delay, seuils adaptés, pouvoirs limités, contrôle des actions proposées et surveillance. Les timelocks et les multisigs peuvent y ajouter du temps et du contrôle supplémentaires. Au final, la question la plus importante reste simple : qui peut changer quoi, et combien de temps le reste du réseau a-t-il pour le voir et réagir ?