Voltage Finance ERC-677 Reentrancy

Am 31. März 2022 verlor Voltage Finance — eine DeFi-Suite im Fuse Network — rund 4 Millionen Dollar aus seinem Lending-Markt durch eine ERC-677-Reentrancy. Voltages Fork eines Compound-artigen Lending-Vertrags unterstützte ERC-677-Tokens, deren transferAndCall-Callback einem Angreifer erlaubte, erneut in die Borrow-Funktion einzutreten, bevor seine Schulden erfasst wurden.

Was geschah

Voltages Lending-Markt akzeptierte verschiedene Tokens als Sicherheit, einschließlich ERC-677-Tokens. ERC-677 erweitert ERC-20 um eine transferAndCall-Funktion — wenn Tokens übertragen werden, wird der onTokenTransfer-Hook des Empfänger-Vertrags aufgerufen, was dem Empfänger erlaubt, beliebigen Code während des Transfers auszuführen.

Der Lending-Vertrag folgte dem Standard- (anfälligen) Muster: geliehene Tokens an den Borrower senden, dann die Schuldenbuchhaltung des Borrowers aktualisieren. Bei einem ERC-677-Token löste der „Geliehene Tokens senden"-Schritt den onTokenTransfer-Callback des Borrowers aus, bevor die Schuld erfasst wurde.

Der Angriff:

1. Nutzte ein ERC-677-Token im Borrow-Pfad.
2. Rief borrow auf — der Vertrag sendete die geliehenen Tokens und löste den onTokenTransfer-Callback des Angreifers aus.
3. Von innerhalb des Callbacks — bevor die Schuld des ersten Borrows erfasst wurde — trat der Angreifer erneut in borrow ein, gegen Sicherheit, die der Vertrag immer noch als unbelastet sah.
4. Schleifte die Reentrancy und akkumulierte geliehene Mittel ohne entsprechend erfasste Schuld.
5. Verschwand mit ~4 Mio. $.

Nachwirkungen

• Voltage Finance pausierte den Lending-Markt und veröffentlichte eine Post-Mortem, die die ERC-677-Reentrancy als Wurzelursache identifizierte.
• Ein Kompensationsplan wurde ausgerollt; die Wiederherstellung vom Angreifer war minimal.

Warum es zählt

Voltage Finance ist Teil der Callback-fähigen-Token-Reentrancy-Linie — derselben strukturellen Klasse wie Cream Finances AMP-Exploit (ERC-777 tokensReceived). Die wiederkehrende Lehre:

Token-Standards mit Transfer-Callbacks (ERC-777, ERC-677, ERC-1363 und andere) brechen die Reentrancy-Annahmen, die für reines ERC-20 gelten. Ein Lending- oder Vault-Vertrag, der für ERC-20-Tokens reentrancy-sicher ist, kann in dem Moment vollständig exploitbar sein, in dem er ein callback-fähiges Token akzeptiert, weil der „Transfer"-Schritt nun vom Angreifer kontrollierten Code mitten in der Operation ausführt.

Die defensiven Antworten:

1. Reentrancy-Guards auf jeden state-mutierenden Pfad anwenden, der Token-Transfers macht — nicht selektiv und nicht mit der Annahme „ERC-20-Transfers rufen nicht zurück" (wahr für reines ERC-20, falsch für die callback-fähigen Erweiterungen).
2. Den tatsächlichen Standard jedes gelisteten Tokens auditieren, nicht nur „ist es ein ERC-20-Interface". Viele Tokens implementieren ERC-20 plus eine Callback-Erweiterung; die Erweiterung ist die Angriffsfläche.
3. Checks-Effects-Interactions rigoros befolgen — Schuld vor dem Senden geliehener Tokens erfassen, sodass ein reentranter Aufruf den aktualisierten Zustand sieht.

Voltage ist einer der Einträge mit kleinerem Verlust im Katalog, aber es ist eine saubere Instanz einer Lektion, die das Ökosystem über Jahre und Chains hinweg ständig neu lernt: Das Token, das du listest, bestimmt deine Reentrancy-Oberfläche, und Callback-fähige Tokens sind ein anderes Bedrohungsmodell als reines ERC-20.