Zum Inhalt springen
Gegr. MMXXVIBd. VI · № 273RSS
Blockchain Breaches

Ein Archiv von Sicherheitsvorfällen im Kryptobereich — Hacks, Exploits, Bridge-Ausfälle und Rug Pulls, dokumentiert mit On-Chain-Belegen.

Dossier № 146Reentrancy

Conic Finance Read-Only Reentrancy

Conic Finances ETH-Omnipool hatte Reentrancy-Guards, nahm aber eine Curve-v2-ETH-Adresse an. Ein neues CurveLPOracleV2 entging ihm – 3,2 Mio. USD entzogen.

Datum
Chain(s)
Status
Mittel entwendet

Am 21. Juli 2023 verlor die Curve-Omnipool-Plattform Conic Finance 1.724 ETH (~3,2 Millionen US-Dollar) durch einen Read-Only-Reentrancy-Exploit. Das Protokoll hatte Reentrancy-Guards vorhanden — aber sie stützten sich auf eine falsche Annahme darüber, wie Curve-v2-ETH-Pools ETH intern repräsentieren, was es dem Angreifer erlaubte, am Guard vollständig vorbeizuschlüpfen.

Was geschah

Conics ETH-Omnipool aggregierte Nutzereinlagen über mehrere Curve-Liquidity-Pools, um den Yield zu maximieren. Um die hinterlegten LP-Tokens zu bewerten, nutzte Conic seinen CurveLPOracleV2-Vertrag — ein neu deploytes Oracle, das die zugrundeliegenden Curve-Pools las, um den fairen Wert zu berechnen.

Der Reentrancy-Guard im Oracle war konditional auf eine _isETH()-Methode, die true zurückgab, wenn einer der Coins des Pools die kanonische ETH-Adresse (0xeeeeeeee...eeeeeeee) war. Für Pools, die diese Prüfung erfüllten, würde der Vertrag einen Reentrancy-Lock erwerben, bevor er State las. Für Pools, die nicht passten, würde er den Lock überspringen.

Der fatale Fehler: Curve-v2-Pools, die ETH halten, nutzen intern die WETH-Adresse, nicht die kanonische ETH-Adresse. Die _isETH()-Methode gab für diese Pools false zurück, und der Vertrag fuhr ohne den Reentrancy-Lock fort.

Der Angriff:

  1. Flash-borrowte 20.000 stETH.
  2. Initiierte eine Reihe von Swaps durch den rETH-Curve-Pool, die ihn in einen Teilausführungszustand brachten.
  3. Mid-Execution — während der rETH-Pool intern inkonsistent war — rief er Conics Oracle auf, um den rETH-LP-Token-Preis zu lesen.
  4. Das Oracle, ohne den Reentrancy-Guard, las den manipulierten Mid-Swap-Zustand und gab einen falschen (aufgeblähten) Preis für rETH-LP-Tokens zurück.
  5. Hinterlegte und hob Conic-Positionen zum aufgeblähten Kurs ab und prägte fast doppelt so viele cncETH-Tokens für denselben Einlagenwert.
  6. Loopte die Operation, entzog Mittel aus dem Omnipool, zahlte den Flash-Loan zurück.

Nettodiebstahl: 1.724 ETH (~3,2 Mio. USD).

Folgen

  • Conic pausierte den Omnipool und veröffentlichte ein detailliertes Post-Mortem.
  • Das Team kündigte einen aus Protokolleinnahmen finanzierten Entschädigungsplan an.
  • Das CurveLPOracleV2 wurde gepatcht, um die korrekte WETH-bewusste Reentrancy-Logik zu nutzen.
  • Der Exploit offenbarte, dass der Audit-Umfang das CurveLPOracleV2 nicht eingeschlossen hatte — der Vertrag wurde nach dem jüngsten Audit deployt, und dasselbe Reentrancy-Problem war zuvor in früheren Oracle-Versionen identifiziert und behoben worden, aber wieder eingeführt, als V2 geschrieben wurde.

Warum es wichtig ist

Der Conic-Finance-Vorfall ist ein lehrbuchmäßiger Fall für zwei kombinierte Fehlermodi:

  1. Read-Only-Reentrancy ist schwerer zu erkennen als Write-Reentrancy. Die meiste Reentrancy-Bildung fokussiert auf Angriffe, die State während der Re-Entry mutieren — Checks-Effects-Interactions-Guards speziell dagegen. Read-Only-Reentrancy — bei der die re-entrierte Funktion nur State liest, dieser State aber mitten in einer Mutation ist — entgeht intuitiver Analyse, weil sich „wir lesen nur" sicher anfühlt. Curve-v1s remove_liquidity ist eine besonders fruchtbare Quelle von Read-Only-Reentrancy-Bugs, die nachfolgende Oracle-Integrationen wiederholt verfehlen.

  2. Gepatchte Bugs tauchen in neuem Code wieder auf. Conics früheres Oracle war gegen dieselbe Reentrancy-Klasse auditiert und gepatcht worden; das V2-Oracle, von Grund auf vom selben Team geschrieben, führte den Bug wieder ein, weil er nicht Teil des Audit-Umfangs war. Das Muster wiederholt sich überall, wo ein Team ein „v2 Rewrite" eines Vertrags ausliefert, der in v1 gehärtet worden war — institutionelles Wissen über spezifische bekannte Schwachstellen überträgt sich nicht immer durch den Rewrite.

Die defensive Antwort ist konsistent: Jede Oracle-Integration, die aus dem State eines anderen Protokolls liest, muss die bekannte Reentrancy-Fläche dieses Protokolls explizit behandeln, und jeder Rewrite eines zuvor auditierten Vertrags muss ein Re-Audit der spezifischen Bug-Klasse einschließen, die der ursprüngliche Fix adressierte. Conics 3,2 Mio. USD sind der Preis dafür, diese Schritte zu überspringen.

Quellen & On-Chain-Belege

  1. [01]halborn.comhttps://www.halborn.com/blog/post/explained-the-conic-finance-hack-july-2023
  2. [02]coindesk.comhttps://www.coindesk.com/tech/2023/07/21/defi-protocol-conic-finance-hacked-for-1700-ether
  3. [03]immunebytes.comhttps://immunebytes.com/blog/conic-finance-detailed-hack-analysis-july-21/

Verwandte Einträge