~1,35 Mio. $ verloren: BarnBridge, DeFiTuna | BlockSec Wöchentlich

In der vergangenen Woche (2026/07/13 - 2026/07/19) werden die folgenden 2 bemerkenswerten Sicherheitsvorfälle vorgestellt, mit einem Gesamtschaden von ca. 1,35 Mio. USD auf Ethereum und Solana.

• DeFiTuna: Die Positions-Gesundheitsprüfung akzeptierte einen Vermögenswert von null als gesund bei gleichzeitig nicht-null Schulden; der Angreifer nutzte kontrolliertes Swap-Routing und einen separaten Pool mit geringer Liquidität, um diesen Fehler auszulösen und eine Position mit faulen Schulden zu erzeugen.
• BarnBridge: Ein veraltetes Governance-System wurde ausgenutzt, um kritische Protokollkonfigurationen zu ändern und vom Benutzer freigegebene Gelder abzuschöpfen.

Wöchentliches Highlight: DeFiTuna

Die Grundursache war ein fehlerhafter Null-Wert-Zweig in der Positions-Gesundheitsprüfung: Eine Position mit einem Vermögenswert von null und ausstehenden Schulden von ca. 570K USD wurde als gesund akzeptiert. Der Angreifer löste diesen Fehler aus, indem er den Swap über einen separaten Pool mit geringer Liquidität leitete, aber die Gesundheitsprüfung war die Kontrolle, die die resultierenden faulen Schulden hätte abfangen sollen.

Am 16. Juli 2026 wurde DeFiTuna, ein Kreditprotokoll auf Solana, das gehebelte Spot-Positionen unterstützt, für ca. 570K USD in USDC ausgenutzt [1]. Die Grundursache war ein fehlerhafter Null-Wert-Zweig in der Positions-Gesundheitsprüfung, der eine Position als gesund akzeptierte, selbst wenn ihr Vermögenswert null und ihre Schulden ungleich null waren. Der Angreifer eröffnete eine gehebelte Position ohne Sicherheiten, lieh sich USDC aus dem Protokoll-Vault und leitete den Swap über einen vom Angreifer kontrollierten Pool mit geringer Liquidität, wodurch die Position nur eine vernachlässigbare Menge des Ziel-Tokens erhielt. Die Präzisionskürzung rundete den Positionswert auf null ab, und die Gesundheitsprüfung akzeptierte die Position als gesund, wodurch ca. 570K USD an faulen Schulden entstanden.

Hintergrund

DeFiTuna ist ein Kreditprotokoll auf Solana, das Margin-Trading unterstützt. Ein Benutzer kann eine Spot-Position eröffnen, indem er einen Token als Sicherheit hinterlegt, sich aus einem Protokoll-Vault leiht und die geliehenen Mittel in einen Ziel-Token tauscht. Die resultierende Position wird dann mit der Schuld verglichen, um festzustellen, ob sie gesund ist.

In einem DeFiTuna Spot-Markt werden die beiden Pool-Tokens als Token A und Token B bezeichnet. Im angegriffenen Markt war Token A TUNA und Token B USDC.

• USDC war der Sicherheiten-Token (collateral_token). Der Benutzer hinterlegt USDC als Margin, leiht sich zusätzliche USDC aus DeFiTunas Vault, und die geliehenen USDC werden dann in TUNA getauscht.
• TUNA war der Positions-Token (position_token), das Vermögen, das die Position nach dem Swap hält. Der Nettoeffekt ist ein gehebeltes Long auf TUNA, finanziert durch USDC-Schulden.
• Die Vault-Konten halten die Liquidität der Kreditgeber und sind die Quelle der geliehenen Mittel.
• Der AMM-Pool liefert Marktliquidität und Preiskontext für das TUNA/USDC-Paar.

DeFiTuna leitet Positions-Swaps über Jupiter, einen Solana Swap-Aggregator. Der Swap-Pfad wird der DeFiTuna-Anweisung als Jupiter-Routendaten und Routenkonten bereitgestellt. Da der Aufrufer diese Konten bereitstellt, kontrolliert der Aufrufer, welchen Pool der Swap verwendet. Vor der Ausführung des Swaps führt DeFiTuna eine Vorprüfung des Preises durch, indem der normale Marktpool-Preis mit einem Orakel verglichen wird.

Schwachstellenanalyse

Das fehlerhafte Programm ist DeFiTuna (tuna4u...nogD).

Die Grundursache war ein fehlerhafter Null-Wert-Zweig in der Positions-Gesundheitsprüfung. Nach einem Swap bewertete DeFiTuna die Position, indem das gehaltene TUNA in USDC-Begriffe umgerechnet wurde. Wenn das TUNA-Guthaben klein genug war, um auf null abzurunden, wurde das Feld total zu 0. Die Gesundheitsprüfungslogik behandelte total == 0 als gesunden Zustand, ohne zu verlangen, dass debt == 0 ist.

Angriffsanalyse

Zwei Designeigenschaften gaben dem Angreifer die Kontrolle darüber, wohin die geliehenen Mittel geleitet wurden. Erstens akzeptierte DeFiTuna vom Aufrufer bereitgestellte Jupiter-RouteV2-Daten, ohne eine eigene minimal akzeptable TUNA-Ausgabe aus dem Orakelpreis und dem geliehenen Betrag abzuleiten. Zweitens validierte die Vorprüfung des Orakels nur den normalen DeFiTuna-Marktpool, nicht den Pool, den die Jupiter-Route tatsächlich verwenden würde.

Hinweis: Die vom Projektteam bestätigte Nachfallanalyse [1] beschreibt den vom Angreifer erstellten Pool als nahe am legitimen Orakelpreis initialisiert. On-Chain-Beweise zeigen, dass der Pool zu einem extremen Preis initialisiert wurde; die Vorprüfung wurde bestanden, weil sie den separaten normalen Marktpool validierte, nicht den vom Angreifer kontrollierten Pool.

Die folgende Analyse basiert auf der Transaktion 4x33Dq...EXj1. Es wurden mehrere Angriffstransaktionen ausgeführt; diese veranschaulicht die grundlegende Technik.

• Schritt 1: Der Angreifer erstellte einen neuen Fusion-TUNA/USDC-Pool. Dieser Pool verwendete die echten TUNA- und USDC-Mints, war aber vom normalen DeFiTuna-Marktpool getrennt. Der Pool wurde zu einem extremen Preis nahe Tick 208636 initialisiert, wobei TUNA mit etwa 1,149 Milliarden USDC pro TUNA bewertet wurde. Bei diesem Preis konnte selbst eine winzige Menge TUNA Hunderttausende von USDC in einem Swap absorbieren.

• Schritt 2: Der Angreifer platzierte zwei kleine Verkaufs-Limit-Orders im neuen Pool. Jede Order hinterlegte 0,000526 TUNA, insgesamt 0,001052 TUNA. Da der Pool-Preis extrem hoch war, konnte dieses winzige TUNA-Angebot den gesamten geliehenen USDC-Betrag absorbieren, wenn der Swap ausgeführt wurde.

• Schritt 3: Mit dem vorbereiteten Pool eröffnete der Angreifer eine DeFiTuna-Spot-Position mit TUNA als Positions-Token und USDC als Sicherheiten-Token. Der Angreifer stellte 0 USDC als Sicherheit zur Verfügung und lieh sich 570.000 USDC aus DeFiTunas USDC-Vault.

• Schritt 4: Vor dem Swap verglich DeFiTuna den normalen Marktpool-Preis mit dem Orakelpreis. Der Spot-Preis des normalen Pools lag nahe am Orakel, sodass die Prüfung bestanden wurde. Diese Prüfung validierte nur den normalen DeFiTuna-Marktpool; sie validierte nicht den Fusion-Pool, den die Jupiter-Route verwenden würde.

• Schritt 5: Der Swap folgte der vom Angreifer bereitgestellten Jupiter-Route, die die Mittel durch den vom Angreifer kontrollierten Fusion-Pool leitete, wobei die Mindestausgabe effektiv auf null gesetzt wurde. Nach der Protokollgebühr wurden 569.601 USDC in den Angriffspool geleitet, während die DeFiTuna-Position nur 494 Roheinheiten TUNA (0,000494 TUNA) erhielt.

• Schritt 6: Nach dem Swap hielt die Position ca. 570.000 USDC an Schulden und nur einen Staub-Betrag an TUNA. Als DeFiTuna dieses TUNA-Guthaben in USDC-Wert umrechnete, wurde das Ergebnis auf 0 abgerundet. Die Gesundheitsprüfung behandelte total == 0 als gesund, sodass die Position mit faulen Schulden akzeptiert wurde.

• Schritt 7: Der Angreifer zog die im vom Angreifer kontrollierten Fusion-Pool angesammelten USDC ab. Die beiden Abhebungen waren nahezu gleich und entsprachen den in Schritt 2 erstellten zwei Limit-Order-Positionen.

Fazit

Die Grundursache war der total == 0-Zweig der Gesundheitsprüfung, der eine Position unabhängig von ausstehenden Schulden als gesund akzeptierte. Das vom Angreifer kontrollierte Routing und die Liquidität schufen die Bedingungen, um diesen Fehler auszulösen, aber die Gesundheitsprüfung war die finale Kontrolle, die die faulen Schulden hätte verhindern sollen.

Die direkteste Lösung besteht darin, jede Position abzulehnen, bei der total == 0 und debt > 0. Eine Position mit null Wert und ausstehenden Schulden ist niemals gesund. Zusätzlich sollte das Protokoll eine minimal akzeptable Swap-Ausgabe aus dem Orakelpreis und dem geliehenen Betrag ableiten, unabhängig von den vom Aufrufer bereitgestellten Routenparametern. Die Bindung der Orakel-/Preisüberprüfung an den tatsächlichen Swap-Pool oder die Überprüfung der Swap-Ausgabe gegen einen protokollberechneten Mindestwert würde verhindern, dass die Vorprüfung durch Routing über einen nicht validierten Pool umgangen werden kann.

Referenzen

• [1] DeFiTuna Stellungnahme nach dem Vorfall

Weitere Vorfälle dieser Woche

BarnBridge

Am 15. Juli 2026 wurde BarnBridge, ein Renditeallokationsprotokoll auf Ethereum, für ca. 776K USD in USDC ausgenutzt [1]. Die Grundursache war, dass der aufgegebene Governance-Vertrag die Befugnis behielt, kritische Protokollkonfigurationen zu ändern. Der Angreifer erwarb ausreichend Stimmrechte, um einen bösartigen Vorschlag zu verabschieden, der den Controller einer Protokollkomponente ersetzte, und nutzte dann den neuen Controller, um vom Benutzer freigegebene USDC zu übertragen.

Hintergrund

BarnBridge ist ein DAO-gesteuertes Protokoll, das die Gelder der Benutzer auf verschiedene Kreditmärkte verteilt, um Rendite zu erwirtschaften. Die Stimmrechte werden durch die Menge der gestakten BOND und die Sperrdauer bestimmt. Für die Erstellung eines Vorschlags ist eine Stimmrechte von mindestens 1% der Gesamtstimmrechte erforderlich. Ein Vorschlag muss ein Mindestquorum von 40% erfüllen und mindestens 60% der gesamten teilnehmenden Stimmen dafür erhalten, um angenommen zu werden. Nach der Einreichung durchläuft ein Vorschlag eine zweitägige Aufwärmphase, eine dreitägige Abstimmungsphase und eine zweitägige Warteschlange, bevor er ausgeführt werden kann.

Schwachstellenanalyse

Die Grundursache war, dass der aufgegebene Governance-Vertrag die Befugnis behielt, kritische Protokollkonfigurationen zu ändern, nachdem das Protokoll eingestellt worden war. Das Governance-System kontrollierte die Controller-Zuweisung für CompoundProvider, einen Vertrag, den Benutzer zuvor genehmigt hatten, ihre USDC auszugeben. Da BarnBridge eingestellt worden war, waren die gesamten gestakten BOND und die aktive Beteiligung erheblich zurückgegangen, was die Durchsetzung eines feindlichen Vorschlags trivial erreichbar machte.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xd191fe...895afb.

Der Angreifer gab ca. 0,335 ETH aus, um etwa 32.795 BOND zu erwerben, hinterlegte und sperrte dann 32.000 BOND und erhielt damit ca. 43% der Gesamtstimmrechte.

• Schritt 1: Der Angreifer setzte einen Proxy-Vertrag ein und reichte einen bösartigen Vorschlag ein. Nach der zweitägigen Aufwärmphase setzte der Angreifer alle seine Stimmrechte dafür ein und erfüllte damit sowohl die Quorum- als auch die Genehmigungsanforderungen.

• Schritt 2: Der Angreifer stellte den Vorschlag in die Warteschlange. Nach Ablauf der zweitägigen Warteschlange führte der Angreifer ihn aus und setzte den Controller von CompoundProvider auf den Proxy-Vertrag des Angreifers.

• Schritt 3: Der Angreifer aktualisierte die Logik des Proxy-Vertrags und rief _takeUnderlying() auf, das die ausstehenden USDC-Genehmigungen von ca. 50 Benutzern nutzte, um deren USDC in CompoundProvider zu übertragen. Der Angreifer rief dann transferFees() auf, um die Mittel an die Adresse des Angreifers weiterzuleiten, und erzielte damit einen Gewinn von ca. 776K USD in USDC.

Fazit

Wenn ein DAO oder Protokoll eingestellt wird, sollte sein Governance-Vertrag die Fähigkeit aufgeben oder dauerhaft deaktivieren, sicherheitskritische Konfigurationen zu ändern, insbesondere Administrator-, Controller- und Fondsabhebungsberechtigungen. Konkrete Maßnahmen umfassen die Aufhebung der Admin-Rolle des Governance-Vertrags über nachgelagerte Verträge, die Übertragung des Eigentums an eine Burn-Adresse oder die Ausführung eines abschließenden Vorschlags, der Upgrade-Funktionen deaktiviert und Controller-Referenzen auf unveränderliche sichere Werte setzt. Das Belassen der Governance-Befugnis in einem eingestellten Protokoll schafft eine kostengünstige Angriffsfläche: Da die Beteiligung sinkt, sinkt auch das erforderliche Kapital zum Erreichen des Quorums proportional.

Referenzen

• [1] Phalcon-Alarm: BarnBridge-Exploit

• Get Started with Phalcon Security

  Detect every threat, alert what matters, and block attacks.

  Try now for free