Zum Inhalt springen
Financial Context Wiki

Governance-Angriff

Ein Governance-Angriff erlangt genügend Stimm- oder Ausführungsgewalt, um schädliche Änderungen über den autorisierten Governance-Pfad durchzusetzen.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Bei einem Governance-Angriff erlangt ein Akteur genügend Stimm-, Antrags-, Aufhebungs- oder Ausführungsgewalt, damit ein Protokoll über seinen autorisierten Governance-Pfad eine schädliche Aktion ausführt. Die Aufrufe können jede Smart-Contract-Prüfung bestehen. Der Fehler liegt darin, dass Kontrolle im Verhältnis zum beherrschten Wert zu billig, zu schnell oder ohne ausreichende Rechenschaft erworben werden kann.

Stimmgewicht kann aus eigenen Token, delegierten Stimmen, geliehenen Token, bestochenen Wählern, kompromittierten Schlüsseln oder privilegierten Rollen im Governor und in der Zeitsperre stammen. Historische Checkpoints verhindern Mehrfachabstimmungen mit demselben übertragenen Guthaben und Kredite nach dem Snapshot. Sie verhindern keine vor dem Snapshot beschafften Stimmen, konzentrierte Delegation, schwache Quoren oder einen kompromittierten Ausführer.

Nicht jeder unpopuläre Antrag ist ein Angriff; Governance soll Regeln verändern. Sicherheitsrelevant ist, ob ein Akteur unverhältnismäßige oder vorübergehende Kontrolle erlangt, die ausführbare Wirkung verschleiert oder falsch darstellt oder eine öffentlich zugesagte Befugnisgrenze überschreitet. Zu prüfen sind die tatsächlichen Aufrufe, der billigste Weg zur Entscheidungsmacht, die Reaktionszeit und der maximal erreichbare Wert oder Kontrollumfang nach der Ausführung.

Funktionsweise

  1. Verfolgen Sie die Befugnisse vom Stimmrechts-Token über Delegation und Checkpoints zum Governor, zur Zeitsperre, zum Proxy-Administrator, zur Treasury, zu Notfallrollen und Zielverträgen. Die Governance-Oberfläche ist nicht der Berechtigungsgraph.
  2. Fixieren Sie Chain, Adressen, Implementierungsversionen, Taktmodus, Snapshot, Antragsschwelle, Quorumsberechnung, Zählregel, Abstimmungsverzögerung und -dauer, Warteschlangenverzögerung, Ablauf, Aufhebungsrechte und Ausführungsrollen.
  3. Rekonstruieren Sie das Stimmgewicht am exakten Snapshot mit historischen Abfragen wie getPastVotes. Fassen Sie von einem Akteur kontrollierte oder koordinierte Adressen zusammen und trennen Sie Token-Guthaben vom delegierten Stimmgewicht.
  4. Dekodieren Sie jede Aktion: targets, values, calldatas und descriptionHash. Lösen Sie Proxys und Selektoren auf, untersuchen Sie Sammelaufrufe und vergleichen Sie die ausführbare Nutzlast mit der lesbaren Beschreibung.
  5. Spielen Sie Erstellung, Abstimmung, Einreihung und Ausführung auf einem Fork nach. Vergleichen Sie Guthaben, Eigentum, Rollen, Freigaben, Implementierungen, Oracle-Einstellungen, Sicherheitenparameter und neu erreichbare Funktionen vor und nach der Ausführung.
  6. Bewerten Sie den billigsten Kontrollpfad über Spotkäufe, Kreditmärkte, Flash-Liquidität, außerbörsliche Darlehen, Delegation, Stimmanreize, Derivateabsicherung, Schlüsselkompromittierung und Übernahme privilegierter Rollen. Berücksichtigen Sie Gebühren, Slippage, Sicherheiten, Abwicklungskosten und Kapitalbindungsdauer.
  7. Testen Sie den Reaktionspfad. Klären Sie, wer aufheben oder pausieren kann, welche Belege nötig sind, ob die Maßnahme in das Zeitfenster passt, wo Nutzer verbindliche Hinweise finden und wie die Governance ohne unbegrenzten Notschlüssel fortgesetzt wird.

Ein typischer Token-Governor durchläuft Antrag, Verzögerung, Snapshot, Abstimmung, Erfolg oder Ablehnung, Warteschlange, Zeitsperre und Ausführung. Die genauen Regeln hängen von der Implementierung ab. Mit ERC-5805-artigen Checkpoints lässt sich delegiertes Stimmgewicht zu einem früheren Zeitpunkt abfragen; der Takt kann Blocknummern oder Zeitstempel verwenden. Maßgeblich sind der bereitgestellte Takt und die Konfiguration, nicht eine angezeigte Dauer oder ein Token-Guthaben.

Eine Zeitsperre schafft ein Mindestankündigungsfenster, beurteilt aber weder Absichten noch Sicherheit der Nutzlast. Auch ihre Rollen für Antrag, Ausführung, Aufhebung und Verwaltung sind kritisch. Kann ein externer Administrator die Verzögerung umgehen, ist die Zeitsperre nicht die letzte Instanz. Kann niemand eine eingereihte schädliche Aktion aufheben, verhindert Erkennung allein die Ausführung nicht.

Rechenbeispiele

  • Übernahme bei geringer Beteiligung. Ein Protokoll hat insgesamt 100 million Token, davon 40 million im Umlauf. Ein Antrag benötigt 2 million teilnehmende Stimmen, mehr Ja- als Nein-Stimmen und eine 6-hour Zeitsperre. Ein Akteur kauft 1.2 million Stimmen und erhält 1 million delegierte Stimmen. 0.8 million stimmen dagegen; mit 2.2 million Ja-Stimmen wird ein Aufruf angenommen, der 15 million USDC aus der Treasury überweisen kann. Der Akteur kontrolliert 2.2 / 100 = 2.2% des Gesamtangebots und 2.2 / 40 = 5.5% des Umlaufs, aber 2.2 / 3.0 = 73.3% der abgegebenen Stimmen. Entscheidend sind Beteiligung, Delegation, Quorum, Nutzlastbefugnis und Verzögerung, nicht das Schlagwort 51%.
  • Snapshot-Grenze. Wird das Stimmgewicht aus dem aktuellen Guthaben gelesen und sofort ausgeführt, kann eine Transaktion Token leihen, abstimmen, ausführen und zurückzahlen. Unveränderliches historisches Stimmgewicht von vor der Abstimmung blockiert diesen Ein-Transaktions-Pfad. Vor dem Snapshot geliehenes oder delegiertes Kapital bleibt nutzbar; daher gehören Antragsverzögerung und beobachtbares Beschaffungsfenster zur Abwehr.
  • Beanstalk am 17. April 2022. Beanstalk Farms berichtete, dass ein Angreifer mit einem Flash-Darlehen den Governance-Mechanismus ausnutzte und ungefähr $77 million an Vermögenswerten außerhalb von Beanstalk stahl. Der Fall zeigt: Flash-Liquidität finanziert den Angriff; entscheidend ist, dass vorübergehende Wirtschaftsmacht wertvolle Ausführungsrechte erreichen konnte.

Risiken und Kontrollen

  • Konzentrierte tatsächliche Macht. Messen Sie Delegierte und koordinierte Einheiten, nicht nur Adressen. Veröffentlichen Sie Anteil der größten Delegierten, Beteiligungsverteilung und Abhängigkeiten von Stiftungen, Verwahrern, Market Makern und Vertretern.
  • Schwache Antrags- und Quorumsregeln. Vergleichen Sie Schwellen mit aktivem Stimmgewicht, verleihbarem Angebot und Treasury-Risiko. Verwenden Sie getrennte Anforderungen für Routineparameter und folgenreiche Upgrades oder Überweisungen.
  • Unsichere Snapshots. Nutzen Sie unveränderliche historische Checkpoints und einen gemeinsamen Takt von Token und Governor. Lassen Sie vor dem Snapshot genug Zeit, damit ungewöhnliche Akkumulation oder Delegation sichtbar wird.
  • Späte oder überraschende Abstimmung. Erwägen Sie eine Mindestverlängerung, wenn das Quorum kurz vor Schluss erreicht wird, und überwachen Sie große Delegationsänderungen während des gesamten Zyklus.
  • Undurchsichtige Nutzlast. Veröffentlichen Sie dekodierte Aufrufe und unabhängige Simulationen. Trennen Sie unverbundene riskante Aktionen, damit ein harmloser Punkt keine Administratoränderung oder Überweisung verdeckt.
  • Zu kurze Ausführungsverzögerung. Skalieren Sie die Zeitsperre nach Wirkung und veröffentlichen Sie eingereihte Operationen. Das Fenster muss Prüfung, Warnung, Aufhebung oder Pause und einen glaubwürdigen Nutzerausstieg ermöglichen.
  • Übermächtige Notfallrollen. Begrenzen Sie Wächter nach Funktion, Wert, Dauer und Prüfstandard. Legen Sie Mitglieder, Schwellen, Rotation, Belegpflichten sowie Abberufung und Wiederaufnahme offen.
  • Ungeprüfte Upgrade-Pfade. Verfolgen Sie Proxy-Administratoren, Beacons, Initialisierer, metamorphe Bereitstellungen und Verträge, die nach Befugniserhalt aktualisierbar sind.
  • Kettenübergreifendes Ausführungsrisiko. Authentifizieren Sie Quell-Governor und Nachricht, verhindern Sie Replay, beschränken Sie Zielfunktionen, ergänzen Sie lokale Verzögerungen und definieren Sie das Verhalten bei Brückenausfall oder -pause.
  • Unzureichende Überwachung. Warnen Sie bei Antragserstellung, Stimmkonzentration, Quorumsänderung, Einreihung und Aufhebung, dekodierten Zustandsänderungen, Upgrades, Rollenzuweisungen, Freigaben und Treasury-Abflüssen.
  • Fehlerhafte Reaktion. Üben Sie schädliche Anträge, Verlust von Unterzeichnern, Frontend-Kompromittierung, Brückenausfall und Fehlpausen. Dokumentieren Sie Entscheidung, Kommunikation, Signatur, Prüfung und sichere Wiederherstellung.
  • Unbegrenzter Risikowert. Begrenzen Sie einzelne und rollierende Treasury-Überweisungen, Upgrade-Umfang, Prägung, Sicherheitenänderungen und Freigaben. Eine angenommene Abstimmung darf nicht automatisch unbegrenzte Befugnisse erteilen.

Das Ergebnis sollte ein reproduzierbares Kontrollregister sein: jede privilegierte Aktion, ihr Kontrolleur, nötige Stimmen oder Schlüssel, frühester Ausführungszeitpunkt, Aufhebungspfad, Überwachungsquelle und maximal erreichbarer Wert. Berechnen Sie es nach Upgrades, Token-Verteilungen, Delegationsänderungen, Brückenmigrationen oder erheblichen Änderungen von Liquidität und Beteiligung neu.

Häufige Irrtümer

  • „Ein Angreifer benötigt 51% des Gesamtangebots.“ Die meisten Systeme hängen von delegierten oder teilnehmenden Stimmen, Quorum und Annahmeregel ab. Entscheidungsmacht kann weit weniger als die Hälfte kosten.
  • „Snapshots beseitigen Governance-Angriffe.“ Sie verhindern bestimmte Wiederverwendungen und Kredite in letzter Minute, nicht frühere Kredite, Käufe, Delegationskonzentration, Bestechung oder kompromittierte privilegierte Schlüssel.
  • „Eine angenommene On-Chain-Abstimmung beweist Legitimität.“ Sie beweist nur die Erfüllung der Codebedingungen, nicht die Übereinstimmung von Beschreibung und Nutzlast oder ein sicheres, faires, zugesagtes Ergebnis.
  • „Eine längere Zeitsperre ist immer sicherer.“ Sie hilft nur, wenn Überwachung, Analyse, Aufhebung oder Pause, Kommunikation und Ausstieg in ihr möglich sind. Übermäßige Verzögerung kann dringende Wartung behindern.
  • „Ein Sicherheitsrat löst das Governance-Risiko.“ Er kann schneller reagieren, schafft aber einen weiteren Kontrollpfad. Befugnis, Rechenschaft, Abberufung und Ausfälle gehören in dasselbe Bedrohungsmodell.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...