Zum Inhalt springen
Financial Context Wiki

Oracle-Angriffe

Ein Oracle-Angriff nutzt manipulierbare, veraltete, falsch skalierte oder fehlerhaft konfigurierte externe Daten aus, sodass ein Protokoll zu einem unsicheren Wert Kredite vergibt, Token prägt, Rücknahmen abwickelt, abrechnet oder Positionen liquidiert.

Aktualisiert

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

Direkte Antwort

Ein Oracle-Angriff nutzt die Vertrauensgrenze für Daten eines Protokolls aus, sodass ein Preis, Wechselkurs, Index, Nettoinventarwert oder Statussignal eine wirtschaftlich unsichere Aktion auslöst. Angreifer können einen marktengen Handelsplatz manipulieren, Melder oder Schlüssel kompromittieren, Aggregations- oder Aktualisierungsregeln ausnutzen oder fehlende Prüfungen des Verbrauchers auf Aktualität, Einheiten, Wertebereiche und Rückfallquellen mit Fremdkapital kombinieren. Ein veralteter oder falsch konfigurierter Feed kann denselben Verlust verursachen, ohne dass ein Oracle-Betreiber böswillig handelt. Die Vorfallanalyse muss daher Angriffspfad und Fehlermodus trennen.

Entscheidend ist nicht, ob sich ein angezeigter Preis stark bewegt hat. Entscheidend ist, ob Kosten und Risiko der Einflussnahme auf genau den vom Vertrag verwendeten Wert geringer sind als der ausführbare Wert, der durch Kreditaufnahme, Prägung, Rücknahme, Abrechnung oder Liquidation verfügbar wird. Flash-Liquidität kann einen atomaren Ablauf finanzieren, erzeugt aber weder die fehlerhafte Vertrauensgrenze noch ist sie für deren Ausnutzung erforderlich.

Ein Oracle-Wert ist zudem nicht zwangsläufig ein ausführbarer Marktpreis. Jede Prüfung muss den Wert einer Chain, einem Block, einer Feed- oder Pool-Adresse, der Ausrichtung von Basis- und Quotierungswert, den Dezimalstellen, dem Zeitstempel, der Aggregationsmethode, der Marktgröße und der verbrauchenden Funktion zuordnen. Eine gültige Signatur belegt, wer Daten gemäß einem Verfahren gemeldet hat; sie belegt allein weder Aktualität noch Quellenunabhängigkeit, Markttiefe oder wirtschaftliche Richtigkeit.

Funktionsweise

  1. Deployment festlegen: Chain, Block, verbrauchender Vertrag und Funktion, Asset-Verträge, Feed-Proxy oder Pool, Aggregator, Basis- und Quotierungswerte, Dezimalstellen, Administratoren und Upgrade-Stand.
  2. Den vollständigen Vertrauenspfad von Börsen, Pools oder Meldern über Aggregation, Signaturen, Proxy oder Adapter und Rückfallquelle bis zur Verbraucherlogik abbilden; gemeinsame Handelsplätze, Betreiber, Schlüssel und Governance erfassen, statt unterschiedliche Bezeichnungen als unabhängige Quellen zu zählen.
  3. Den Onchain-Lesevorgang exakt reproduzieren: Antwort, Rundendaten, Zeitstempel, gegebenenfalls Konfidenz oder Status, Dezimalnormalisierung, Quotierungsumkehr, Sequencer-Status und Karenzfrist, Höchstalter, Abweichungsgrenzen sowie Behandlung von Null- und Negativwerten.
  4. Das Expositionsbuch des Verbrauchers aufstellen: Beleihungsfaktor, Liquidationsschwelle, Kredit- und Angebotsobergrenzen, verfügbare Liquidität, Schulden, Präge- oder Rücknahmelimits, Close Factor, Liquidationsbonus und jede durch den Wert freigeschaltete Aktion.
  5. Manipulation in ausführbarer Größe modellieren: Reserven, aktive Liquidität, Beobachtungen, Fenster und Gewichtung, Gebühren, Arbitrage, Blockreihenfolge, Flash- oder Eigenkapital, Verluste beim Rückabwickeln, Gas, MEV und konkurrierende Liquidatoren.
  6. Kontrollen und Fehlerzustände testen: unabhängige Quellen, TWAP-Kardinalität, Limits, Circuit Breaker, Pausenbefugnis, Timelocks, veraltete oder abweichende Rückfallquelle, Ausfall von Meldern oder Schlüsseln, L2-Sequencer-Ausfall, legitime Preissprünge sowie Fail-open- und Fail-closed-Verhalten.
  7. Kanonische Feed-Runden, Proxy- und Konfigurationsänderungen, Quellenabweichungen, Protokollaktionen, Liquidationen, uneinbringliche Schulden sowie Pausen- und Wiederanlaufentscheidungen überwachen und abstimmen; die Analyse nach Änderungen an Liquidität, Listing, Upgrade oder Marktregime wiederholen.

Ein Spotwert aus einem AMM lässt sich häufig innerhalb einer Transaktion verändern. Ein zeitgewichteter Durchschnitt kann die Kosten erhöhen, weil der Einfluss über mehrere Beobachtungen bestehen muss. Seine Sicherheit hängt jedoch von der arithmetischen oder tickbasierten Konvention, dem Fenster, der Beobachtungskardinalität, der Liquiditätsverteilung und der Blockkontrolle ab. Ein Median kann einzelne Ausreißer abweisen, doch korrelierte Quellmärkte oder ein Quorumsausfall können Sicherheit oder Verfügbarkeit weiterhin beeinträchtigen. Heartbeat- und Abweichungsparameter steuern, wann bestimmte Feeds veröffentlichen; Verbraucher benötigen dennoch eigene Regeln für Aktualität und Gültigkeit.

Durchgerechnete Beispiele

  • Spotpreis im Constant-Product-Pool. Gebühren werden in einem Pool mit 1,000,000 ABC und 1,000,000 USDC ignoriert, somit gilt k = 10^12. Ein marginaler Zielpreis von 9 USDC/ABC erfordert Reserven von 3,000,000 USDC und 333,333.333333 ABC: Der Händler zahlt 2,000,000 USDC ein und erhält 666,666.666667 ABC. Der marginale Endpreis beträgt 3,000,000 / 333,333.333333 = 9, der durchschnittliche Ausführungspreis dagegen 2,000,000 / 666,666.666667 = 3 USDC/ABC. Eine Einzahlung von 5,000,000 USDC hinterlässt hingegen Reserven von 6,000,000 und 166,666.666667 und erzeugt einen marginalen Preis von 36, nicht 9. Tatsächliche Gebühren, Arbitrage, konzentrierte Liquidität und Rückabwicklung verändern das Buch.
  • TWAP-Konvention. Bei zehn gleich gewichteten Ein-Minuten-Beobachtungen lauten neun Preise 100 und einer 160. Der didaktische arithmetische TWAP ist (9 * 100 + 160) / 10 = 106, also nur 6% über 100, obwohl der letzte Spotpreis 60% höher liegt. Soll dieser arithmetische Mittelwert bei neun unveränderten Beobachtungen von 100 auf 130 steigen, muss die manipulierte Beobachtung 400 betragen. Der Tick-Mittelwert von Uniswap v3 ist im Gegensatz zu diesem arithmetischen Beispiel geometrisch; der Verbraucher muss deshalb die tatsächlich eingesetzte Konvention reproduzieren.
  • Median und Quorum. Sieben normalisierte Beobachtungen sind [99, 100, 100, 101, 101, 500, 600]; ihr Median ist 101, sodass zwei extreme Meldungen das Ergebnis nicht aus dem ehrlichen Cluster verschieben. Erfordert die Annahme fünf aktive Meldungen und fallen drei ehrliche Melder aus, verbleiben nur 4 < 5: Ausreißerresistenz gewährleistet keine Verfügbarkeit, und das Rückfallverhalten wird Teil des Sicherheitsmodells.
  • Veraltung und unberechtigte Liquidation. Ein Feed mit acht Dezimalstellen liefert den Rohwert 140,000,000,000, also 1,400. Sein Alter beträgt jedoch 17 minutes bei einem vom Verbraucher erlaubten Höchstwert von 15 minutes, sodass er abgewiesen werden muss. Wird der veraltete Wert dennoch für 10 ETH, eine Liquidationsschwelle von 75% und Schulden von 12,000 verwendet, beträgt der Health Factor 10 * 1,400 * 0.75 / 12,000 = 0.875; bei einem aktuellen Preis von 2,000 beträgt er 1.25. Eine spätere Preiskorrektur macht eine bereits vollzogene Liquidation nicht rückgängig.

Risiken

  • Falsche Chain-, Asset-, Feed-, Proxy-, Pool- oder Verbraucheradresse.
  • Vertauschte Basis- und Quotierungswerte oder uneinheitliche Denominierung.
  • Falsche Normalisierung der Dezimalstellen von Feed, Token und internem Festkommaformat.
  • Annahme veralteter Daten oder Verwechslung von Heartbeat- und Abweichungsauslösern mit Aktualitätsgarantien.
  • Annahme unvollständiger Runden, ungültiger Statuswerte oder von Null-, Negativ-, begrenzten oder außerhalb des Bereichs liegenden Antworten.
  • Ein marktenger Spotpreis eines einzelnen Handelsplatzes steuert eine große Protokollexposition.
  • Ein TWAP-Fenster ist zu kurz, dünn belegt, falsch gewichtet oder in der falschen Richtung gelesen.
  • Beobachtungskardinalität, Initialisierung, Interpolation oder Rückfallverhalten werden missverstanden.
  • Konzentrierte oder Just-in-time-Liquidität lässt den nominalen Poolwert die Angriffskosten falsch darstellen.
  • Mehrere Feeds teilen Börsen, Datenanbieter, Betreiber, Schlüssel oder Kontrollebene.
  • Ausfall von Melder, Börse, API, Signierer, Netzwerk oder Quorum beeinträchtigt Aktualität oder Integrität.
  • L2-Sequencer-Ausfall oder fehlende beziehungsweise falsche Karenzfrist nach Wiederanlauf.
  • Eine Rückfallquelle ist veraltet, zirkulär, korreliert, anders skaliert oder semantisch unvereinbar.
  • Flash-Liquidität und atomare Komponierbarkeit machen vorübergehenden Einfluss wirtschaftlich nutzbar.
  • Reihenfolge von Oracle-Updates, Frontrunning, Sandwiching, Backrunning oder Liquidations-MEV verändert Auszahlungen.
  • Beleihungsfaktoren, Liquidationsschwellen, Limits, Boni und verfügbare Liquidität verstärken kleine Fehler.
  • Kompromittierung von Governance, Administrator, Guardian, Multisig oder Signierschlüssel verändert den Vertrauenspfad.
  • Proxy-, Aggregator-, Adapter-, Upgrade-, Speicher- oder Konfigurationsfehler wählen den falschen Wert.
  • Circuit Breaker oder Fail-closed-Logik blockieren in Stressphasen legitime Kreditaufnahme, Rückzahlung oder Liquidation.
  • Pausen-, Wiederanlauf-, Kontenabstimmungs-, Verlustzuweisungs- oder protokollübergreifende Eindämmungsprozesse versagen.

Häufige Missverständnisse

  • „Jeder Oracle-Angriff kompromittiert das Oracle-Netzwerk.“ Viele Fehler nutzen eine marktengere Quelle, einen veralteten Wert, falsche Einheiten, einen unsicheren Adapter oder Verbraucherlogik aus, während das Meldenetzwerk wie konfiguriert arbeitet.
  • „Mehrere oder dezentrale Feeds garantieren einen richtigen Preis.“ Unabhängigkeit, Quellenqualität, Quorum, Aktualität, Einheiten, Aggregation und Prüfungen des Verbrauchers bleiben erforderlich.
  • „Ein TWAP macht Manipulation unmöglich.“ Er verändert Dauer und Kosten des Einflusses; ein schwaches Fenster, wenige Beobachtungen, geringe Liquidität oder Blockkontrolle können weiterhin ausnutzbar sein.
  • „Ein Verbot von Flash Loans behebt das Oracle-Risiko.“ Flash Loans sind nur ein Finanzierungsmechanismus. Eigenkapital, Kredit, protokollübergreifende Kredite, kompromittierte Melder und Konfigurationsfehler bleiben bestehen.
  • „Die Preiserholung macht den Schaden rückgängig.“ Kanonische Kredite, Prägungen, Rücknahmen, Abrechnungen und Liquidationen bleiben bestehen, sofern das Protokoll keinen gesonderten, autorisierten Wiederherstellungsprozess besitzt.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...