Was ist ein Governance-Angriff in Krypto und wie können sich Protokolle schützen?

Was ist ein Governance-Angriff in Krypto?

Ein Governance-Angriff ist ein Angriff, bei dem jemand die Entscheidungsfindung einer DAO oder eines Protokolls nutzt oder übernimmt, um eine (meist) schädliche Aktion auszuführen. Eine DAO ist eine Organisation, die über Regeln in Smart Contracts und Abstimmungen der Teilnehmer Entscheidungen trifft.

Bei vielen Protokollen bestimmen Tokens, wie viel Stimmrecht du hast. Wer genug Stimmmacht sammelt, kann zum Beispiel Vorschläge einbringen, um Einstellungen zu ändern, neue Funktionen hinzuzufügen, die Logik eines Contracts zu aktualisieren oder Geld aus einer Treasury zu verschieben. Eine Treasury ist einfach gesagt der gemeinsame Pool mit Mitteln eines Protokolls.

Nicht jeder Governance-Angriff entsteht durch einen Programmierfehler. Manchmal hält sich ein Angreifer formal einfach an die Regeln, sammelt aber genug Einfluss, um einen Vorschlag durchzusetzen, der für andere Nutzer schädlich ist. Das nennt man Governance Capture: Die Entscheidungsfindung liegt dann in der Praxis in den Händen einer einzelnen Partei oder einer kleinen Gruppe.

Ein möglicher Trick dabei ist ein Flash Loan. Das ist ein Kredit, der innerhalb derselben Blockchain-Transaktion zurückgezahlt werden muss. Wenn ein Protokoll das Stimmgewicht auf Basis des aktuellen Tokenbestands in einem Wallet berechnet, ohne Wartezeit oder historischen Snapshot, kann ein Angreifer vorübergehend sehr viel Stimmmacht erhalten.

Beispiel: Stell dir vor, ein Protokoll setzt einen Token mit einer Stimme gleich. Jemand leiht sich vorübergehend sehr viele Tokens, stimmt für einen Vorschlag, Geld aus der Treasury zu verschieben, und zahlt den Kredit sofort zurück. Wenn das System diese temporären Tokens mitzählt, kann das ausreichen, um die Abstimmung zu beeinflussen.

Wichtigste Erkenntnisse

• Ein Governance-Angriff missbraucht die Entscheidungsfindung einer DAO oder eines Protokolls für eine schädliche Aktion.
• Bei tokengewichteter Governance bestimmt die Anzahl der Tokens oft, wie viel Stimmrecht jemand hat.
• Ein Angriff kann eine technische Schwachstelle ausnutzen, aber auch innerhalb der bestehenden Regeln stattfinden.
• Flash Loans können vorübergehend viel Stimmmacht verschaffen, wenn ein Protokoll aktuelle Salden verwendet.
• Vorschläge können unter anderem Einstellungen anpassen, Contracts aktualisieren oder Treasury-Assets verschieben.

Wie funktioniert ein Governance-Angriff?

Ein Governance-Angriff funktioniert meist so, dass ein Angreifer zuerst genug effektive Stimmmacht sammelt, dann einen schädlichen Vorschlag genehmigen lässt und ihn anschließend ausführt. Wie genau das abläuft, hängt von den Regeln des Protokolls ab.

Stimmgewicht kann zum Beispiel aus Tokens kommen, die du besitzt, aus Stimmen, die andere an dich delegieren, aus gestakten Tokens oder aus LP-Positionen. Eine LP-Position ist dein Anteil an einem Liquidity Pool. Der entscheidende Punkt ist: Zu welchem Zeitpunkt legt das Protokoll fest, wie viel Stimmrecht du hast?

Oft sieht ein Angriff ungefähr so aus:

1. Stimmrecht sammeln Der Angreifer kauft Tokens, sammelt Delegationen, nutzt bereits vorhandene große Stimmmacht oder leiht sich vorübergehend Tokens über einen Flash Loan.

2. Einen Vorschlag einreichen Der Vorschlag enthält eine oder mehrere Aktionen, die Smart Contracts ausführen sollen. Das können zum Beispiel Änderungen an Einstellungen sein, aber auch ein Upgrade oder eine Überweisung aus der Treasury.

3. Die Abstimmung gewinnen Der Vorschlag muss genug Stimmen und das erforderliche Quorum erreichen. Ein Quorum ist die minimale Beteiligung, die nötig ist, damit eine Abstimmung gültig ist.

4. Die Aktion ausführen Nach einer erfolgreichen Abstimmung führt die Governance die geplanten Transaktionen aus. Ohne Verzögerung kann das sofort passieren. Mit einem Timelock muss die Aktion zuerst warten.

Ein historischer Snapshot hilft gegen bestimmte Flash-Loan-Angriffe. So ein Snapshot ist im Grunde ein Bild der Stimmrechte zu einem früheren, festen Zeitpunkt. Eine Voting Delay, also eine Wartezeit, bevor Stimmen zählen, funktioniert nur dann gut, wenn vorübergehend geliehene Tokens nicht bereits in diesem Snapshot enthalten sind.

Beanstalk zeigt, wie groß die Auswirkungen sein können. Am 17. April 2022 wurde das Protokoll über On-Chain-Governance angegriffen. Der Angreifer nutzte einen Flash Loan, um den damaligen Governance-Mechanismus zu kompromittieren und Assets aus der DAO zu entnehmen.

Ein Snapshot ist übrigens keine vollständige Lösung. Hat ein Angreifer die Tokens bereits vor dem gewählten Zeitpunkt gekauft oder unter Kontrolle, zählt diese Stimmmacht ganz normal mit.

Welche Folgen kann ein Governance-Angriff haben?

Ein Governance-Angriff kann dazu führen, dass ein Angreifer Geld, Rechte oder wichtige Einstellungen eines Protokolls in die Hand bekommt. Wie schwer das wiegt, hängt ganz davon ab, was Governance tatsächlich tun darf.

Governance kann bei manchen Protokollen unter anderem Systemeinstellungen anpassen, neue Märkte oder Funktionen hinzufügen und Teile des Protokolls aktualisieren. Wenn Governance auch wichtige Proxies, Konfigurationskomponenten oder Treasury-Contracts kontrolliert, kann ein bösartiger Vorschlag großen Schaden anrichten.

Mögliche Folgen sind unter anderem:

• Verlust von Treasury- oder Nutzer-Assets;
• unerwünschtes Minting neuer Tokens;
• geänderte Einstellungen, die Nutzer benachteiligen;
• angepasste Administratorrechte;
• ein Upgrade auf schädliche Contract-Logik;
• das vorübergehende oder vollständige Stilllegen von Funktionen.

Bei dem Angriff auf Beanstalk wurden am 17. April 2022 alle Nicht-BEAN-Nutzer-Assets gestohlen, im Wert von rund 77 Millionen Dollar. Danach wurde das Protokoll pausiert, die On-Chain-Governance entfernt und die Governance-Struktur verändert.

Der Schaden ist oft größer als nur der direkte Verlust. Ein Protokoll muss möglicherweise auf neue Contracts migrieren, Audits und Wiederherstellungsarbeiten bezahlen und vorübergehend mehr Notfallkontrolle bei einer kleinen Gruppe bündeln. Das kann das Vertrauen der Nutzer deutlich beeinträchtigen.

Wie kann ein Protokoll die Kontrolle verlieren?

Ein Protokoll verliert faktisch die Kontrolle, sobald ein Angreifer genug Rechte über die Contracts hat, die kritische Aktionen ausführen. Denk an den Owner eines Proxys, ein Konto, das Upgrades durchführen darf, eine Rolle, die Vorschläge bei einem Timelock einplanen darf, oder den Controller der Treasury.

Ein Proxy ist hier einfach gesagt eine feste Contract-Adresse, die auf eine bestimmte Version der Contract-Logik verweist. Bei einem upgradefähigen Protokoll kann Governance diese Adresse auf neue Logik zeigen lassen. So kann ein einziger genehmigter Vorschlag die Funktionsweise des Protokolls erheblich verändern.

Dafür muss ein Angreifer nicht immer die Mehrheit aller Tokenhalter haben. Bei geringer Beteiligung, einem niedrigen Quorum oder stark konzentrierten Delegationen kann schon eine relativ kleine Gruppe genug effektive Stimmmacht haben.

Nach einer schädlichen Ausführung kann die Wiederherstellung besonders schwierig werden. Der Angreifer kann Berechtigungen ändern, Assets wegschicken oder sogar die zukünftigen Governance-Regeln anpassen. Dann ist es möglich, dass die Community nicht mehr über denselben Weg eingreifen kann oder erst viel später.

Kontrollverlust kann auch ohne Angriff entstehen. Wenn die berechtigten Konten eines selbstverwalteten Timelocks nicht mehr verfügbar sind, kann ein Contract, der von diesem Timelock verwaltet wird, auf unbestimmte Zeit blockiert sein.

Wie können sich Krypto- und DeFi-Protokolle schützen?

Krypto- und DeFi-Protokolle können das Risiko senken, indem sie Stimmmacht, Berechtigungen und Ausführung nicht zu leicht auf einen einzigen Zeitpunkt zusammenfallen lassen. Es gibt keine magische Einstellung, die jeden Angriff stoppt, aber mehrere Ebenen zusammen machen Missbrauch deutlich schwieriger.

Wichtige Maßnahmen sind:

1. Snapshots und eine Voting Delay nutzen Lege das Stimmgewicht zu einem früheren Zeitpunkt fest und baue eine Wartezeit ein. Dadurch wird es schwieriger, kurz vor einer Abstimmung vorübergehend Tokens zu organisieren und direkt zu nutzen.

2. Passende Stimmhürden wählen Ein Mindestwert für Vorschläge macht billige Spam-Vorschläge schwieriger. Ein Quorum verhindert, dass eine sehr kleine Beteiligung allein entscheidet. Die Abwägung bleibt schwierig: Zu niedrige Hürden machen Capture einfacher, zu hohe Hürden können Governance unpraktisch machen.

3. Sensible Aktionen hinter einen Timelock setzen Upgrades, große Parameteränderungen und Treasury-Aktionen müssen nicht direkt nach einer Abstimmung stattfinden. Ein Timelock gibt Nutzern Zeit, eine geplante Aktion zu prüfen und gegebenenfalls ihre Position zu schließen.

4. Rechte pro Rolle begrenzen Gib Governance nicht automatisch unbegrenzte Macht. Vor allem Rechte für Upgrades, Minting und unbegrenzte externe Calls verdienen zusätzliche Einschränkungen. Notfallrechte sollten klar abgegrenzt sein.

5. Die tatsächlichen Vorschlagsaktionen testen Es reicht nicht, nur das Abstimmungsmodul zu prüfen. Teams sollten auch die genauen Transaktionen hinter einem Vorschlag testen und simulieren. Ein Vorschlag kann auf hoher Ebene harmlos wirken, während die konkreten Calls etwas ganz anderes tun.

6. Vorschläge und Stimmmacht überwachen Monitoring verhindert einen Angriff nicht automatisch, kann aber dafür sorgen, dass ein verdächtiger Vorschlag oder eine große Verschiebung bei Delegationen rechtzeitig auffällt. Ein vorher abgestimmter Incident-Plan hilft dann, schneller zu reagieren.

Audits bleiben nützlich, sind aber keine Garantie. Nicht jeder Governance-Angriff steckt in einem Fehler im Code. Auch irreführende Vorschläge, geringe Beteiligung und schlecht bewertete Transaktionen können zu Problemen führen.

Wie können Timelocks und Multisig-Governance helfen?

Timelocks und Multisigs können eine zusätzliche Sicherheitsebene bilden, weil sie verhindern, dass ein einzelnes genehmigtes oder kompromittiertes Konto sofort alles ausführen kann.

Ein Timelock-Controller erzwingt eine minimale Wartezeit zwischen dem Einplanen und dem Ausführen einer wichtigen Aktion. Ist der Timelock der Verwalter eines Contracts, gilt diese Verzögerung auch für Aktionen, die sonst direkt mit Administratorrechten ausgeführt werden könnten.

Dieses Reaktionsfenster ist wichtig. Nutzer und Sicherheitsforscher können die genauen Transaktionsdaten prüfen, bevor die Änderung live geht. Bei einem gefährlichen Vorschlag können Nutzer zum Beispiel ihre Position schließen, bevor die Aktion ausgeführt wird. Der Timelock macht eine schädliche Aktion nicht automatisch ungültig, nimmt einem sichtbaren Angriff aber das Tempo.

Compound v2 nutzt zum Beispiel mehrere Phasen: zwei Tage Review, drei Tage Abstimmung und danach zwei Tage Timelock. Dadurch dauert eine Protokolländerung dort mindestens eine Woche.

Eine Multisig funktioniert anders. Dabei müssen mehrere Eigentümer eine Transaktion bestätigen. Bei einer 3-aus-5-Multisig sind drei gültige Signaturen nötig. Ein einzelner gestohlener oder kompromittierter Schlüssel reicht dann nicht aus, um selbstständig Geld zu verschieben oder Einstellungen zu ändern.

Eine Multisig kann zum Beispiel die einzige Partei sein, die Aktionen bei einem Timelock einplanen darf. So muss zuerst eine Gruppe von Unterzeichnern zustimmen, danach beginnt die festgelegte Wartezeit.

Wichtig ist aber: Eine Multisig verlagert Vertrauen auf die Unterzeichner. Wenn sich genug Signer absprechen, wenn zu viele Schlüssel gestohlen werden oder wenn Signer nicht erreichbar sind, entstehen trotzdem Probleme. Auch zusätzliche Module oder Erweiterungen verdienen Aufmerksamkeit, weil sie unter Umständen Transaktionen außerhalb der normalen Signaturprüfung ausführen können.

Was sind die Grenzen von Governance in Krypto?

Governance in Krypto kann Entscheidungen transparent und automatisch umsetzen, aber das System weiß nicht von selbst, ob ein Vorschlag auch sinnvoll oder fair ist. Eine gültige On-Chain-Abstimmung beweist nur, dass die Regeln eingehalten wurden.

Bei tokengewichteter Governance hängt Einfluss mit wirtschaftlichem Gewicht zusammen. Große Halter, Fonds und bekannte Delegates können dadurch deutlich mehr Einfluss haben als kleine Teilnehmer, auch ohne Angriff oder Fehler im Code. Delegation macht Abstimmungen einfacher, kann Macht aber gerade bei einer kleinen Gruppe konzentrieren.

Auch Geschwindigkeit und Sicherheit stehen manchmal im Konflikt. Längere Abstimmungsphasen und Timelocks geben mehr Zeit, Vorschläge sorgfältig zu prüfen und zu reagieren. Gleichzeitig verlangsamen sie sinnvolle Upgrades, Anpassungen und manchmal auch die Reaktion auf einen Vorfall.

Quorums und Mindestwerte für Vorschläge haben denselben Zielkonflikt. Sind sie zu niedrig, kann eine kleine, aber gut organisierte Gruppe Entscheidungen treffen. Sind sie zu hoch, können normale Vorschläge scheitern, weil zu wenige Menschen abstimmen.

Ein weiteres Problem ist die Komplexität. Die genaue Calldata eines Vorschlags, ein Upgrade der Contract-Logik oder das Zusammenspiel mehrerer Smart Contracts sind für viele Abstimmende schwer zu beurteilen. Dadurch kann ein Vorschlag formal korrekt sein, während nur wenige wirklich verstehen, was passiert.

Eine Multisig oder ein Guardian kann das Risiko eines schnellen Angriffs senken, bringt aber auch Zentralisierungs- und Verfügbarkeitsrisiken mit sich. Ein Guardian ist ein Konto oder eine Gruppe mit besonderen Notfallrechten. Wenn so eine Partei böswillig handelt, nicht erreichbar ist oder Transaktionen blockiert, kann diese Sicherheitsebene selbst zu einer Schwachstelle werden.

Governance ist also keine Einstellung, die du einmal sauber setzt und dann vergisst. Die Verteilung von Tokens, Delegationen, Rechten, Anreizen, Vorschlagskontrolle und Notfallverfahren sollte regelmäßig neu geprüft werden.

Fazit

Ein Governance-Angriff dreht sich nicht nur um Hacker, die eine technische Schwachstelle finden. Auch eine Partei, die sich nach den Regeln genug Stimmmacht verschafft, kann ein Protokoll in Schwierigkeiten bringen, wenn Governance zu viele Rechte hat oder Vorschläge zu schnell ausgeführt werden.

Guter Schutz besteht aus mehreren Ebenen: Snapshots, einer Voting Delay, passenden Hürden, begrenzten Berechtigungen, der Prüfung von Vorschlagsaktionen und Monitoring. Timelocks und Multisigs können dabei zusätzliche Zeit und Kontrolle hinzufügen. Am Ende bleibt die wichtigste Frage einfach: Wer kann was ändern, und wie viel Zeit hat der Rest, das zu sehen und zu reagieren?