#6 Cork-Protokoll-Vorfall: Zwei unabhängige Fehler ergeben eine verheerende Exploit-Kette

Am 28. Mai 2025 wurde das Cork Protocol auf Ethereum ausgenutzt [1], was zu Verlusten von rund 12 Millionen US-Dollar führte. Die Grundursache war eine Kombination aus einer Manipulation des historischen impliziten Renditedurchschnitts (HIYA) durch Zeitablauf und fehlender Zugriffskontrolle in einem Uniswap v4 Hook-Callback. Da die Risikoaufschläge von HIYA exponentiell ansteigen, wenn die Laufzeit gegen Null geht, blähten späte Swaps die HIYA auf und führten dazu, dass neu initialisierte Märkte Cover Tokens stark unterbewerteten. Gleichzeitig fehlte bei CorkHook.beforeSwap die msg.sender-Authentifizierung, was willkürliche Aufrufe mit präparierten Parametern ermöglichte. Durch die Ausnutzung beider Schwachstellen extrahierte der Angreifer große Mengen CT und DS und wandelte sie zurück in wstETH um, wodurch die Reserven des Protokolls geleert wurden.

Hintergrund

0x1.1 Tokenomics

Das Cork Protocol [2] führt ein neues Primärinstrument für tokenisiertes Risiko ein und dient als programmierbare Risikoschicht für On-Chain-Assets wie Vault-Tokens, Rendite-stabile Coins und liquide (Re-)Staking-Tokens. Die grundlegende Komponente ist der Cork Pool, der Mechanismus, um den herum Märkte aufgebaut werden. Jeder Cork Pool basiert auf einem Asset-Paar: Redemption Asset (RA) und Pegged Asset (PA).

Der Cork Pool empfängt Einlagen von Redemption Asset, das gesperrt wird. Im Gegenzug werden zwei Tokens geprägt und an den Einleger zurückgegeben: Depeg Swap (DS) und Cover Token (CT). Vor dem festgelegten Ablaufdatum können 1 DS + 1 CT/PA gegen 1 RA zurückgetauscht werden; nach Ablauf kann 1 CT proportional für die verbleibenden RA + PA im Pool eingelöst werden.

$$PA+DS=RAPA\; +\; DS\; =\; RA$$

$$CT+DS=RACT\; +\; DS\; =\; RA$$

0x1.2 Contract Implementation

Sowohl DS als auch CT sind handelbar. Benutzer können CT und RA über einen NormalSwap basierend auf einer benutzerdefinierten AMM-Kurve über CorkHook handeln, während DS und RA über einen FlashSwap über Router und CorkHook gehandelt werden.

NormalSwap [Benutzerdefinierte AMM-Kurve]:

$$x^{1-t}{y}^t=kx^\{1-t\}\; y^\{t\}\; =\; k$$

FlashSwap [FlashSwapRouter.swapDsforRa]:

1. Der Käufer transferiert RA an den Router.

2. Im ersten beforeSwap-Aufruf berechnet der Router den zu tauschenden DS-Betrag. Falls erforderlich, leiht er RA und CT aus dem Uniswap v4 Pool, wandelt das geliehene CT und das DS des Protokolls in RA um, behält das erforderliche RA und gibt das geliehene RA an den Uniswap Pool zurück.

3. Im zweiten beforeSwap-Aufruf zerlegt der Router RA in CT und DS über depositPsm, transferiert das gesamte DS an den Benutzer, zahlt das geliehene CT an den Uniswap Pool zurück und erstattet jegliches überschüssige CT an den Käufer.

Fund Distribution Nach Ausgabe:

$$RA+CT:AMMRA+CT:\; AMM$$

$$DS:RouterDS:\; Router$$

0x1.3 Pricing Mechanism for New Issuance

Das Protokoll verwendet HIYA (Historical Implied Yield Average), berechnet als die kumulative Summe von Volumen ($v_{T}v\_T$) × Risikoaufschlag ($r_{T}r\_T$), um Risikoaufschläge zu messen und die Initialisierungspreise nach Ablauf anzupassen. Wenn die HIYA hoch ist, geht das Protokoll von einem höheren Depeg-Risiko aus, was zu einer niedrigeren initialen CT-Preisgestaltung führt.

$KumulierteHIYA={\sum }_T{r}_T{v}_{T}Kumulierte\backslash \; HIYA\; =\; \backslash sum\_T\; r\_T\; v\_T$

Die Berechnung des Risikoaufschlags ($r_{T}r\_T$) besteht aus zwei Komponenten: Hohe CT-Preise korrelieren mit niedrigen $r_{T}r\_T$-Werten (was intuitiv ist), und die Ablaufzeit T hat einen exponentiellen Verstärkungseffekt. Nahe dem Ablauf nähert sich T Null, wodurch der Exponent $1\mathrm{/}T1/T$ schnell anwächst. Dies verstärkt selbst kleine CT-Preisänderungen zu großen Risikoaufschlagswerten.

$$r_T=(F\mathrm{/}{p}_T{)}^{1\mathrm{/}T}-1r\_T\; =\; (F\; /\; p\_T)^\{1/T\}\; -\; 1$$

• $FF$ ist 1

• $P_{T}P\_T$ ist der Preis von CT

• $TT$ ist die Laufzeit, normalisiert zwischen 1 und 0

Vulnerability Analysis

Der betroffene Markt umfasst die folgenden Tokens:

Zur Verdeutlichung bezieht sich der Rest dieses Berichts auf die Tokens anhand ihrer abstrakten Rollen (RA, DS, CT) und nicht ihrer konkreten Namen, außer wenn der Unterschied relevant ist.

Der Angreifer extrahierte sowohl DS als auch CT aus dem AMM und dem Router mit zwei verschiedenen Methoden. Da DS + CT gegen RA eingelöst werden kann, ermöglicht der Erhalt beider eine direkte Gewinnabschöpfung. Der Angriff besteht aus zwei Komponenten.

0x2.1 Cover Token Extraction: HIYA-Manipulation führt zu künstlich niedrigen Marktinitialisierungspreisen

Der Marktinitialisierungspreis nach Ablauf ergibt sich aus dem accumulatedHIYA-Wert des vorherigen Zeitraums. Da die HIYA während Swaps aktualisiert wird und Risikoaufschläge enthält, kann ein Angreifer kurz vor Ablauf Swaps ausführen, um die accumulatedHIYA künstlich zu erhöhen.

Dadurch wird der neue Markt zu einem verzerrten Preisverhältnis initialisiert, was dazu führt, dass Cover Tokens im AMM extrem niedrig bepreist werden, wodurch der Angreifer RA gegen eine übermäßige Menge CT tauschen kann.

0x2.2 Depeg Swap Extraction: Fehlende Zugriffskontrolle in `CorkHook.beforeSwap`

Die Schwachstelle wird durch die fehlende Senderprüfung in CorkHook.beforeSwap verursacht. Da die Funktion msg.sender == PoolManager nicht erzwingt, kann ein Angreifer sie direkt mit beliebigen Parametern aufrufen.

Durch die Bereitstellung von DS-Tokens, als wären sie RA, und das Spoofen von Router.CorkCall über präparierte Calldata kann der Angreifer eine unbefugte Aufspaltung auslösen und Werte aus einem bösartig initialisierten Markt extrahieren.

Attack Analysis

Dieser Vorfall entfaltet sich in drei Phasen: die Vorbereitungstransaktion, die Initialisierungstransaktion und die Angriffstransaktion.

The preparation transaction

In dieser Transaktion rief der Angreifer SwapRaForDs() auf, was die accumulatedHIYA manipulierte.

The initialization transaction

In dieser Transaktion wurde der Markt zu dem manipulierten Preisverhältnis initialisiert, was einen sehr niedrigen Preis für CT im AMM schuf. Der Angreifer tauschte dann RA gegen eine große Menge CT.

The attack transaction

Die wichtigsten Schritte von der Angriffstransaktion werden wie folgt zusammengefasst.

In dieser Phase erstellte der Angreifer einen gefälschten Markt, der den echten DS (weETH8DS‑2) als seinen RA behandelt. Alle in diesem gefälschten Markt geprägten Tokens werden unten als gefälschtes CT und gefälschtes DS bezeichnet.

1. Der Angreifer tauschte zunächst RA gegen DS im legitimen Markt.

2. Der Angreifer stellte einen gefälschten Markt bereit und initialisierte ihn, wobei er den echten DS als gefälschten RA deklarierte.

   

3. Der Angreifer rief beforeSwap direkt auf (unter Umgehung der fehlenden Zugriffskontrolle) mit nicht-leerem hookData, was den FlashSwap-Ausführungspfad auslöste.

   

4. Innerhalb von hookData gab der Angreifer paymentToken als gefälschtes CT an, was dazu führte, dass das Protokoll die RA-Zerlegungslogik gegen den gefälschten Markt ausführte.

5. Das Protokoll zerlegte den gesamten gefälschten RA (d.h. echten DS) in gefälschtes CT und gefälschtes DS. Der gesamte gefälschte DS-Anteil wurde an den Angreifer transferiert, und der gefälschte CT-Anteil (abzüglich eines minimalen paymentAmount) wurde dem Angreifer erstattet.

6. Der Angreifer tauschte das extrahierte gefälschte CT und gefälschte DS im gefälschten Markt zurück gegen gefälschtes RA und erhielt den echten DS zurück.

7. Schließlich kombinierte der Angreifer den wiederhergestellten DS mit dem zuvor gekauften CT, um RA zu komponieren und dadurch den Angriffsgewinn zu realisieren.

Summary

Dieser Vorfall kombinierte zwei unabhängige Schwachstellen, von denen keine allein ausreichte, zu einer einzigen Exploit-Kette, die 12 Millionen US-Dollar aus dem Protokoll entzog.

• Exponentieller Risikoaufschlag nahe Ablaufdatum. Die HIYA-Preisformel verstärkt Risikoaufschläge, wenn die Laufzeit gegen Null geht, was späte Swaps zu einem Manipulationsvektor für Marktinitialisierungspreise macht.
• Fehlende Senderprüfung in Hook-Callbacks. CorkHook.beforeSwap erzwingte nicht, dass msg.sender der PoolManager war, was direkte Aufrufe mit willkürlichen Parametern ermöglichte und es dem Angreifer ermöglichte, den FlashSwap-Ausführungspfad zu spoofen.
• Interaktion zwischen Modulen als blinder Fleck. Das ökonomische Design (HIYA-basierte Preisgestaltung) und die Lücke in der Zugriffskontrolle (unauthentifizierter Hook-Callback) befanden sich in separaten Modulen. Ihre Interaktion schuf einen ausnutzbaren Pfad, der bei einer Einzelmodulanalyse wahrscheinlich nicht erkannt worden wäre.

Reference

1. https://www.cork.tech/blog/post-mortem

2. https://docs.cork.tech/core-concepts/cork-pool

About BlockSec

BlockSec ist ein Full-Stack Blockchain-Sicherheits- und Krypto-Compliance-Anbieter. Wir entwickeln Produkte und Dienstleistungen, die unseren Kunden helfen, Code-Audits (einschließlich Smart Contracts, Blockchain und Wallets) durchzuführen, Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zu verfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen zu erfüllen.

BlockSec hat mehrere Blockchain-Sicherheitsarbeiten auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Milliarden von Kryptowährungen gesichert.

• Offizielle Website: https://blocksec.com/

• Offizielles Twitter-Konto: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage senden

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance