Wöchentlicher Web3-Sicherheitsvorfall-Rundown | 30. März – 5. April 2026

Im vergangenen Jahr (30.03.2026 - 05.04.2026) hat BlockSec neun Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtschäden von rund 287 Millionen US-Dollar. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall finden Sie in den folgenden Unterabschnitten.

1. Unbekannter Protokollvorfall

Kurze Zusammenfassung

Am 30. März 2026 verlor ein unbekanntes Protokoll auf der BNB Chain aufgrund fehlerhafter Geschäftslogik rund 10.000 US-Dollar. Das Protokoll wies einen Teil der Einlagen der Benutzer zu, um seinen Plattform-Token PSTART zu kaufen und Liquidität bereitzustellen, was bedeutete, dass die Benutzer effektiv LP-Positionen hielten, die Marktschwankungen unterlagen. Bei der Auszahlung erfolgte jedoch keine Abrechnung auf Basis des tatsächlich zu diesem Zeitpunkt einlösbaren Wertes der LP. Stattdessen wurde weiterhin eine feste Menge an Stablecoins versprochen, basierend auf der historischen Einlage und vordefinierten Regeln. Infolgedessen konnte der Angreifer nach der Kapitalbindung durch erzwungene Investition Gelder zu einem vordefinierten Festwert abheben, wodurch Verluste, die von der LP-Position hätten getragen werden müssen, effektiv auf das Protokoll verlagert und letztendlich ein Null-Kosten-Gewinn erzielt wurde.

Hintergrund

Das Protokoll funktioniert wie folgt: Nachdem ein Benutzer BUSD eingezahlt hat, verwendet das Protokoll einen Teil der Gelder, um PSTART zu kaufen und Liquidität bereitzustellen. Die daraus resultierenden LP-Anteile werden dann vom Vault verwahrt, während das Protokoll in seinem internen Hauptbuch eine Bestellung für den Benutzer aufzeichnet, die eine feste tägliche Rendite verspricht.

Anschließend kann der Benutzer Prämien zu einem festen Zinssatz beanspruchen, und beim Ausstieg begleicht der Vault das Kapital und die Rendite gemäß vordefinierten Regeln, anstatt strikt basierend auf dem aktuellen Nettovermögenswert der zugrundeliegenden LP-Position abzurechnen.

Schwachstellenanalyse

Diese Schwachstelle beruht auf einem unzumutbaren Protokolldesign (0x587984...73a43c): Die Abwicklungslogik ist vom tatsächlichen Wert der zugrundeliegenden Vermögenswerte getrennt.

Nachdem ein Benutzer BUSD eingezahlt hat, verwendet das Protokoll einen Teil davon, um PSTART zu kaufen und Liquidität bereitzustellen. Das bedeutet, dass die tatsächliche zugrundeliegende Position des Benutzers eine LP-Exposure ist, deren Wert mit den Marktpreisen schwankt. Wenn der Benutzer jedoch aussteigt, erfolgt keine Abrechnung auf Basis des tatsächlichen einlösbaren Wertes der LP zu diesem Zeitpunkt. Stattdessen wird weiterhin versprochen, eine feste Menge an Stablecoins gemäß dem historischen Einlagebetrag und vordefinierten Abrechnungsregeln zu zahlen.

Der Angreifer nutzte diesen Fehler aus, indem er einen Flash-Loan verwendete, um eine große Menge Kapital zu erhalten, und dann wiederholt deposit() ausführte. Damit zwang der Angreifer das Protokoll, kontinuierlich PSTART zu kaufen und die Vermögenszusammensetzung des Pools zu verändern, wodurch der PSTART-Preis künstlich in die Höhe getrieben und eine Arbitragemöglichkeit geschaffen wurde.

Der Angreifer führte dann withdraw() aus und löste Gelder zum vordefinierten Festwert ein. Damit wurden Verluste, die von der zugrundeliegenden LP-Position hätten getragen werden müssen, effektiv auf das Protokoll selbst verlagert, was letztendlich zu einem risikofreien Gewinn führte.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xf3b8...55e7.

• Schritt 1: Der Angreifer erhielt ungefähr 2.000.000e18 BUSD durch einen Flash-Loan und tauschte sie im Pool gegen 19.013.120e18 PSTART.

• Schritt 2: Der Angreifer rief wiederholt die deposit()-Funktion des Vertrags auf, um Gelder einzusetzen. Für jede Einzahlung berechnete das Protokoll, wie viel BUSD zum Kauf von Token verwendet werden sollte, damit das endgültige Token-zu-BUSD-Verhältnis für die Bereitstellung von Liquidität dem aktuellen Poolverhältnis näher kommt. Durch wiederholte Einzahlungen injizierte der Angreifer kontinuierlich BUSD in den Pool, während die Menge an PSTART nahezu unverändert blieb. Infolgedessen stieg der Wert von PSTART weiter an. In dieser Phase wurde der durch die Einzahlungen des Angreifers erzielte LP tatsächlich mit Verlust erworben.

• Schritt 3: Der Angreifer verkaufte dann den in Schritt 1 gekauften PSTART zurück in den Pool. Da Schritt 2 die BUSD-Reserven des Pools erhöht hatte, lieferte dieser Tausch etwa 2.010.655e18 BUSD zurück, was einen Gewinn von etwa 10.655 BUSD in einem einzigen Angriffszyklus ergab.

• Schritt 4: Schließlich führte der Angreifer withdraw() für alle in Schritt 2 eröffneten Staking-Positionen aus. Zu diesem Zeitpunkt war der Marktwert der Vermögenswerte, die diesen Positionen entsprachen, bereits weit unter ihrem anfänglichen Einlagenwert. Nach normaler Wirtschaftslogik wäre eine vollständige Rücknahme nicht möglich gewesen. Das Protokoll berechnete jedoch den einlösbaren BUSD-Betrag auf Basis des historischen Einlagebetrags, was es dem Angreifer ermöglichte, alle zuvor erzwungenen Investitionskosten vollständig zurückzufordern, ohne Verluste zu tragen.

Schlussfolgerung

Die Hauptursache dieses Vorfalls ist, dass das Protokoll Benutzereinlagen in LP-Positionen investierte, die Marktschwankungen unterworfen waren, und dennoch eine Abrechnung in fester BUSD-Menge basierend auf historischen Einlagebeträgen und vordefinierten Regeln versprach. Dies schuf eine Diskrepanz zwischen den Verbindlichkeiten des Protokolls und dem tatsächlichen Wert seiner zugrundeliegenden Vermögenswerte.

Der Angreifer nutzte diese Schwachstelle aus, indem er wiederholt deposit() verwendete, um die Poolstruktur zu verändern und den Preis von PSTART in die Höhe zu treiben, dann durch eine externe Position Arbitrage durchführte und schließlich withdraw() verwendete, um die zuvor verlustbringenden Positionen zum Buchwert abzurechnen. Auf diese Weise wurden Verluste, die von den Positionen selbst hätten getragen werden müssen, auf das Protokoll verlagert, was letztendlich einen risikofreien Gewinn ermöglichte.

2. WDGG Token Vorfall

Kurze Zusammenfassung

Am 30. März 2026 wurde der WDGG-Token auf der BNB Chain ausgenutzt, was zu Verlusten von rund 40.000 US-Dollar führte. Die Hauptursache war das Fehlen einer Zugriffskontrolle in der Funktion burnFrom(). Insbesondere erlaubte die Funktion burnFrom() beliebigen Benutzern, WDGG-Token von beliebigen Adressen zu verbrennen. Der Angreifer nutzte dies aus, indem er WDGG-Token aus dem PancakeSwap-Pool verbrannte, dann die Funktion sync() aufrief, um die WDGG-Reserven des Pools zu reduzieren, und anschließend einen umgekehrten Tausch durchführte, um Gewinn zu erzielen.

Hintergrund

Dieser Vorfall betrifft einen einzelnen Token, WDGG, der ein dividendenverteilender Token ist, der bei jeder Übertragung eine Gebühr erhebt.

Schwachstellenanalyse

Der WDGG-Token-Vertrag (0x512de7...6b90c5) exponierte burnFrom() ohne jegliche Berechtigung des Aufrufers. Infolgedessen konnte jede Adresse WDGG-Token von jedem Halter verbrennen, einschließlich des PancakeSwap-Pools selbst. Gepaart mit dem öffentlich aufrufbaren sync() von PancakeSwap, das die aufgezeichneten Reserven mit den tatsächlichen Guthaben abgleicht, ermöglichte dieser Fehler eine beliebige Reduzierung der WDGG-Reserven des Pools und das Brechen der konstanten Produktinvariante ohne legitimen Handel, wodurch der Pool Preisungleichgewichts-Arbitragen ausgesetzt war.

Eine sekundäre Schwachstelle in setWdgAddress() erlaubte es jedem Aufrufer, eine beliebige Adresse als Gebührenbefreit zu markieren, was den durch diese Angriffsfläche zu extrahierenden Gewinn weiter maximierte.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x2da5...0bd1.

• Schritt 1: Der Angreifer rief zunächst setWdgAddress() auf, um seine eigene Adresse als gebührenbefreit zu setzen, wodurch nachfolgende Übertragungen die Übertragungsgebühr des Tokens umgehen konnten.

• Schritt 2: Der Angreifer tauschte dann eine kleine Menge BNB gegen WDGG-Token über den PancakeSwap-Pool.

• Schritt 3: Nach Erhalt von WDGG rief der Angreifer burnFrom() auf, um WDGG-Token direkt von der PancakeSwap-Paaradresse zu verbrennen.

• Schritt 4: Anschließend rief der Angreifer sync() auf, wodurch das Paar gezwungen wurde, seine Reserven an die manipulierten Token-Guthaben anzupassen. Infolgedessen wurde die WDGG-Reserve im Pool auf nur noch 1 Wei reduziert.

• Schritt 5: Mit den stark verzerrten Poolreserven führte der Angreifer einen umgekehrten Tausch durch und zog Gewinn aus dem Preisungleichgewicht.

Schlussfolgerung

Dieser Vorfall wurde letztendlich durch fehlende Zugriffskontrollen in der Funktion burnFrom() des WDGG-Token-Vertrags verursacht. Infolgedessen konnte ein Angreifer Token direkt aus dem PancakeSwap-Pool verbrennen, die Reserven des Pools über sync() manipulieren und das resultierende Preisungleichgewicht gewinnbringend ausnutzen.

3. i6Token Vorfall

Kurze Zusammenfassung

Am 31. März 2026 verlor der i6-Token auf der BNB Chain rund 273.800 US-Dollar, da invest() den Spotpreis des Pools bewegte, während withdraw() Salden über einen verzögerten TWAP abrechnete und die beiden in derselben Transaktion kombiniert werden konnten. Der Angreifer pumpte den Spotpreis durch invest(), löste überschüssige i6 zum veralteten TWAP über withdraw() ein und verkaufte die i6 zurück in den aufgeblähten Pool, um Gewinn zu erzielen.

Hintergrund

Das Protokoll funktioniert wie folgt. Wenn ein Benutzer invest() aufruft, wird USDT eingezahlt und teilweise zum Kauf von i6 auf PancakeSwap verwendet. Die erworbenen i6, zusammen mit dem verbleibenden USDT, werden dann als Liquidität zum USDT/i6-Pool hinzugefügt und die resultierenden LP-Token werden verbrannt. Das Protokoll zeichnet Benutzer- und Empfehlungsbilanzen in USDT auf.

Wenn withdraw() aufgerufen wird, berechnet das Protokoll den angesammelten Wert des Benutzers in USDT und wandelt ihn anhand eines vom Protokoll geführten TWAP-Preises (twapPrice) in i6 um.

Schwachstellenanalyse

Die Hauptursache im Protokollvertrag (0x1cb36b...2a18a) ist, dass invest() als Nebeneffekt des Kaufs von i6 und der Bereitstellung von Liquidität den Spotpreis des USDT/i6-Pools verändert, während withdraw() angesammelte USDT-denominierte Salden anhand eines vom Protokoll geführten TWAP (twapPrice) in i6 abrechnet, der sich erst nach Ablauf eines Zeitfensters aktualisiert. Nichts im Vertrag verhindert, dass diese beiden Funktionen in derselben Transaktion ausgeführt werden.

Da ein invest()-Aufruf den Spotpreis innerhalb derselben Transaktion, in der ein nachfolgender withdraw() einen noch nicht aktualisierten TWAP liest, beeinflussen kann, sehen die beiden unterschiedliche Preise für denselben Poolzustand. Ein durch withdraw() eingelöster USDT-denominierter Saldo wird dann zum veralteten, viel niedrigeren Preis in i6 ausgezahlt, obwohl jeder i6 jetzt im Pool selbst für weit mehr USDT realisierbar ist. Diese Lücke verwandelt jeden angesammelten USDT-Saldo im Protokoll in eine ausnutzbare Differenz zwischen interner Abrechnung und dem Live-Pool.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xc1b9...2f16.

• Schritt 1: Der Angreifer erhielt zunächst 270.000 WBNB durch einen Flash-Loan, hinterlegte diese dann als Sicherheit bei Venus und lieh sich eine große Menge USDT. Der Angreifer setzte auch den Angriffskontrakt A unter 0xda49 und den Hilfskontrakt B unter 0x096a ein.

• Schritt 2: Der Angriffskontrakt führte die erste invest()-Transaktion aus. Während dieses Prozesses verwendete das Protokoll zunächst 531.489e18 USDT zum Kauf von 234.188e18 i6 und stellte dann 354.326e18 USDT zusammen mit 72.607e18 i6 dem Pool zur Verfügung. Infolgedessen stieg der Pool-Spotpreis schnell von etwa 1,05159 USDT/i6 auf etwa 4,89287 USDT/i6, während der vom Protokoll aufgezeichnete TWAP immer noch nur bei 1,05159 lag.

• Schritt 3: Der Angreifer transferierte dann 124.014.184e18 USDT an den Hilfskontrakt B, der wiederum invest() mit referrer = A aufrief. Dieser Schritt zwang das Protokoll erneut zu einem massiven Kauf von USDT -> i6 und zu addLiquidity(), wodurch die Poolreserven in einen neuen Zustand versetzt wurden, der einem Spotpreis von etwa 15.528 USDT/i6 entsprach. Da jedoch kein neues Zeitfenster verstrichen war, aktualisierte das Protokoll den TWAP nicht entsprechend.

• Schritt 4: Nach Abschluss der zweiten invest()-Transaktion wurde der Angriffskontrakt A, der als Empfehlungsgeber fungierte, sofort berechtigt, eine Empfehlungsprämie in USDT zu erhalten. Der Angreifer rief dann withdraw() auf. Das Protokoll verwendete den veralteten TWAP, um die auszuzahlende i6-Menge zu berechnen und die Token aus seinem eigenen Guthaben zu transferieren, was zu einer Gesamtauszahlung von 5.896.508e18 i6 führte.

• Schritt 5: Nach Erhalt der i6 rief der Angreifer sofort swapExactTokensForTokensSupportingFeeOnTransferTokens() auf, um alle 5.896.508e18 i6 zurück in den Pool zu verkaufen und im Austausch 125.177.224e18 USDT zu erhalten. Da diese i6-Token mit dem veralteten TWAP von etwa 1,05159 USDT/i6 abgerechnet worden waren, während sie gegen einen Pool-Spotpreis verkauft wurden, der vom Angreifer auf rund 15.528 USDT/i6 hochgetrieben worden war, konnte der Angreifer die enorme Differenz zwischen den beiden Preisen direkt realisieren.

• Schritt 6: Nach Rückzahlung des Flash-Loans verblieben dem Angreifer 273.802e18 USDT, was der tatsächliche Gewinn aus dem Angriff war.

Schlussfolgerung

Die Hauptursache liegt darin, dass eine Spotpreis-beeinflussende Funktion (invest()) und eine TWAP-abgerechnete Funktion (withdraw()) in einer einzigen Transaktion kombiniert werden konnten, wodurch die beiden unterschiedliche Preise für denselben Poolzustand sehen konnten.

Um diese Art von Fehler zu vermeiden, sollten Protokolle, die AMM-Interaktionen mit verzögerten Preisen kombinieren, die Abrechnung von Salden zu einem TWAP in derselben Transaktion vermeiden, in der eine Begleitfunktion den Spotpreis des zugrundeliegenden Pools bewegt, und stattdessen Auszahlungen an den live realisierbaren Wert des Pools anstatt an einen veralteten oder abgeleiteten Preis anbinden.

4. Drift Protocol Vorfall

Kurze Zusammenfassung

Am 1. April 2026 (UTC) wurde das Drift Protocol auf Solana für rund 285,3 Millionen US-Dollar kompromittiert. Die Hauptursache war kein Fehler in der Smart-Contract-Logik, sondern ein Zusammenbruch des Multisig-Autorisationsprozesses, verstärkt durch einen 2-von-5-Sicherheitsrat ohne Timelock und den dauerhaften Nonce-Mechanismus von Solana, der es erlaubte, vorab gesammelte Multisig-Genehmigungen auf unbestimmte Zeit gültig zu bleiben, bis der Angreifer sie ausführte. Nach wochenlanger Vorbereitung lockte der Angreifer zwei von fünf Unterzeichnern dazu, bösartige Governance-Transaktionen, die an dauerhafte Nonce-Konten gebunden waren, vorab zu unterzeichnen, und reichte sie später ein, um die Admin-Kontrolle zu übernehmen, und führte dann einen erfundenen Sicherheiten-Asset (CVT) ein, blähte seinen Orakelpreis auf, lockerte Auszahlungslimits und zog reale Vermögenswerte über den Drift Vault (JCNCMF...XJfrw) ab.

Hintergrund

Drift Protocol ist ein DeFi-Protokoll auf Solana, das Margin-Handel, Kreditvergabe, Spotmärkte und Derivate unterstützt. Seine hochprivilegierten Operationen, einschließlich Admin-Änderungen, Markterstellung, Orakelkonfiguration, Aktualisierungen von Risikoparametern und Anpassungen von Auszahlungslimits, werden vom Squads Multisig-Framework anstelle eines einzelnen privaten Schlüssels gesteuert. Zum Zeitpunkt des Angriffs operierte der Sicherheitsrat von Drift unter einer 2-von-5-Schwellenwertkonfiguration ohne Timelock, was bedeutete, dass beliebige zwei von fünf Unterzeichnern administrative Aktionen mit sofortiger Wirkung genehmigen konnten. Die Sicherheit dieses Systems hängt nicht nur von der Verwahrung der Unterzeichnerschlüssel ab, sondern auch von der Integrität der gesamten Genehmigungspipeline: welche Transaktion wurde erstellt, was die Unterzeichner zu genehmigen glaubten und ob die endgültigen ausgeführten Anweisungen dem Überprüfungskontext entsprachen.

Separat ersetzt das dauerhafte Nonce-Konto von Solana den kurzlebigen Blockhash durch einen persistenten Nonce, der in einem dedizierten Konto gespeichert ist, wodurch eine signierte Transaktion auf unbestimmte Zeit gültig bleibt, bis der Nonce vorgerückt wird. Dieser Mechanismus ist für legitime Anwendungsfälle wie Offline-Signierung und verzögerte Einreichung konzipiert, führt aber ein kritisches Angriffs-Primitiv ein, indem er entkoppelt, wann eine Transaktion signiert wird, von wann sie auf der Kette ausgeführt wird. Sobald ein Unterzeichner eine Transaktion mit dauerhaftem Nonce genehmigt, kann die Genehmigung nicht mehr widerrufen werden, es sei denn, der Nonce-Autor autorisiert das Nonce-Konto manuell.

Schwachstellenanalyse

Die Hauptursache ist kein Smart-Contract-Bug, sondern drei strukturelle Schwächen in der Governance-Konfiguration von Drift, die zusammen eine Social-Engineering-Möglichkeit in einen 285,3-Millionen-Dollar-Abfluss verwandelten. Erstens entfernten dauerhafte Nonces das implizite Signatur-Ablauf-Sicherheitsnetz. Bei normalen Blockhash-basierten Transaktionen wird die Genehmigung eines getäuschten Unterzeichners entweder prompt ausgeführt oder läuft innerhalb eines engen Fensters harmlos ab, was den Spielraum für koordinierte Ausnutzung begrenzt. Dauerhafte Nonces lösen diese Einschränkung auf: Sobald zwei Mitglieder des Sicherheitsrats dazu gebracht wurden, bösartige Governance-Transaktionen durch irreführende Signierungsanfragen zu genehmigen, blieben ihre Signaturen auf unbestimmte Zeit ausnutzbar, was dem Angreifer die vollständige Kontrolle über den Zeitpunkt der Ausführung gab.

Zweitens bedeutete der Null-Timelock für administrative Aktionen, dass, sobald die vorab signierten Transaktionen eingereicht wurden, die Admin-Übertragung sofort wirksam wurde, ohne ein Fenster zur Erkennung oder Intervention. Drittens war der Umfang der Admin-Rolle so breit, dass sie neue Sicherheitenmärkte schaffen, Orakelquellen wechseln und Auszahlungslimits in einem einzigen privilegierten Pfad lockern konnte, so dass eine einzige erfolgreiche Governance-Übernahme ausreichte, um einen beliebigen Asset in die Extraktion realer Gelder umzuwandeln, ohne weitere Genehmigungsbarrieren.

Angriffsanalyse

Der Angriff entfaltete sich in drei verschiedenen Phasen: Vorbereitung vor dem Angriff, in der der Angreifer eine mehrtägige Operation durchführte, um ein gefälschtes Sicherheiten-Asset herzustellen und durch irreführende Signierungsanfragen Zugang zur Governance zu erhalten; Governance-Übernahme, in der zwei vorab signierte Transaktionen mit dauerhaftem Nonce in schneller Folge eingereicht wurden, um die administrative Kontrolle zu erlangen; und Geldernte, in der der Angreifer Protokollparameter manipulierte und reale Vermögenswerte über die Kreditvergabe-Pfade des Protokolls abzog. Das Diagramm unten veranschaulicht den Ausführungsfluss über diese drei Phasen.

• Phase 1 (Vorbereitung vor dem Angriff): Ab dem 11. März zog der Angreifer 10 ETH aus Tornado Cash ab und setzte CarbonVote Token (CVT) ein, prägte 750 Millionen Einheiten, schuf dann Liquidität auf Raydium und baute durch Wash-Trading eine künstliche Preisgeschichte nahe 1 US-Dollar auf. Parallel dazu wurden bis zum 23. März vier dauerhafte Nonce-Konten erstellt, zwei verbunden mit Mitgliedern des Drift Security Council und zwei vom Angreifer kontrolliert, was darauf hindeutet, dass mindestens zwei von fünf Unterzeichnern bereits Transaktionen signiert hatten, die an dauerhafte Nonce-Konten gebunden waren. Am 27. März führte Drift aufgrund eines Mitgliederwechsels eine geplante Migration des Sicherheitsrats durch, wodurch die zuvor gesammelten Signaturen ungültig wurden; bis zum 30. März hatte der Angreifer jedoch den erforderlichen Schwellenwert unter der neuen Konfiguration wiedererlangt, was eine aktive Überwachung von On-Chain-Governance-Änderungen und eine Echtzeit-Anpassung zeigte.

• Phase 2 (Governance-Übernahme): Am 1. April gegen 16:05 UTC, etwa eine Minute nachdem Drift eine legitime Testabhebung aus dem Versicherungsfonds durchgeführt hatte, reichte der Angreifer zwei vorab signierte Transaktionen mit dauerhaftem Nonce in vier Slots Abstand ein. Die erste Transaktion (2HvMSg...2C4H) erstellte und genehmigte den bösartigen Admin-Übertragungsvorschlag. Die zweite Transaktion (4BKBmA...RsN1) genehmigte und führte diese aus, beginnend mit AdvanceNonceAccount zur Aktivierung des gespeicherten Nonce, fortgesetzt über proposalApprove und vaultTransactionExecute und endend mit dem Aufruf von UpdateAdmin, um die administrative Kontrolle an eine vom Angreifer kontrollierte Adresse zu übertragen.

• Phase 3 (Geldernte): Mit voller Admin-Berechtigung schuf der Angreifer einen Sicherheitenmarkt für CVT, wechselte zu einem vom Angreifer kontrollierten Orakel, um dessen Buchpreis aufzublasen, und erhöhte oder entfernte Auszahlungslimits auf wichtigen Asset-Märkten. Der Angreifer hinterlegte dann eine große Menge überbewerteten CVT im Protokoll und führte 31 schnelle Abhebungen über etwa 12 Minuten durch, wobei er USDC, JLP, SOL, cbBTC, USDT, wETH, dSOL, WBTC, JTO und FARTCOIN für einen Gesamtverlust von rund 285,3 Millionen US-Dollar abhob, berechnet auf Basis des Angreifer-Abbuchungskontos (HkGz4K...pZES).

Schlussfolgerung

Die Hauptursache dieses Vorfalls ist kein Smart-Contract-Schwachstelle oder Schlüsselkompromittierung, sondern ein Zusammenbruch des Multisig-Autorisationsprozesses in Kombination mit Nonce-basierter verzögerter Ausführung und einem administrativen Pfad ohne Timelock. Vorab gesammelte Genehmigungen, die normalerweise innerhalb von Minuten abgelaufen wären, blieben auf unbestimmte Zeit ausnutzbar, und nach der Einreichung boten die Admin-Übernahme und die anschließende Geldernte kein Fenster für Interventionen.

Die Eindämmung dieser Art von Risiko erfordert die Sicherung der gesamten Autorisierungspipeline und nicht nur der Verwahrung von Signierschlüsseln, die Durchsetzung von Timelocks für hochprivilegierte Operationen und die Behandlung von verzögerten Ausführungsmechanismen wie dauerhaften Nonces als separate Bedrohungsfläche, die höhere Signaturschwellenwerte, zeitlich begrenzte oder widerrufliche Genehmigungen und Beschränkungen für auf unbestimmte Zeit gültige signierte Transaktionen erfordert.

5. LML Staking Protocol Vorfall

Kurze Zusammenfassung

Am 1. April 2026 wurde das LML-Staking-Protokoll auf der BNB Chain für rund 950.000 US-Dollar ausgenutzt. Die Hauptursache war eine Inkonsistenz in der Logik der Belohnungsberechnung: Die Belohnungskonvertierung las einen gespeicherten LML/USDT-Preis, der hinter einer 3600-Sekunden-Aktualisierungs-Cooldown gesperrt war, während die ausgezahlten LML zum Live-AMM-Preis einlösbar waren, ohne Abweichungsprüfung zwischen den beiden. Der Angreifer verwendete Flash-Loans, um den Pool-Spotpreis aufzublasen, und nutzte EIP-7702-Code-Delegierung, um Belohnungen für 11 vorab gestakte EOAs in einer einzigen Transaktion zu stapeln, eine übermäßige Menge an LML zum veralteten gespeicherten Preis zu erhalten und sie dann über den nun stark verzerrten Pool zu verkaufen, um Gewinn zu erzielen.

Hintergrund

LML ist ein Staking-Protokoll auf der BNB Chain, bei dem Benutzer BNB über den APower-Vertrag staken, um LML-Token als Belohnung zu erhalten. Belohnungen werden in USDT berechnet und dann basierend auf einem vom Protokoll gespeicherten LML/USDT-Preis in LML-Beträge umgerechnet, bevor sie verteilt werden. Der gespeicherte Preis wird durch updatePrice() aktualisiert, der den AMM-Spotpreis liest, aber einen 3600-Sekunden-Cooldown zwischen Updates erzwingt. Belohnungsansprüche werden über APower's receive() basierend auf msg.sender ausgelöst, so dass nur die ursprüngliche Staking-Adresse ihre eigenen Belohnungen beanspruchen kann.

Schwachstellenanalyse

Der Kernfehler im Staking-Vertrag (0xbe9713...adce19) liegt darin, dass die Belohnungsakkumulation und die Belohnungseinlösung an zwei verschiedene Preise desselben Pools gebunden sind, ohne dass eine Konsistenzprüfung zwischen ihnen erfolgt. Die Belohnungsformel reward += (10^18 * base_reward) / stored_price berechnet die LML-Auszahlung aus _prices[], einem vom Protokoll gespeicherten LML/USDT-Preis, der nur durch updatePrice() nach einem 3600-Sekunden-Cooldown aktualisiert wird, doch die ausgezahlten LML sind sofort zum Live-AMM-Spotpreis einlösbar. Jede externe Aktivität, die den Spotpreis innerhalb dieses Cooldown-Fensters bewegt, öffnet eine Lücke zwischen einem gefrorenen Akkrualpreis und einem Live-Verkaufspreis, und nichts im Vertrag lehnt einen Anspruch ab, wenn diese Lücke unangemessen groß wird.

Ein zweiter struktureller Fehler liegt darin, wie die Belohnungsquelle aufgefüllt wird. Wenn das LML-Guthaben des PROOF-Vertrags nicht ausreicht, um einen Anspruch zu begleichen, füllt swapBack() es auf, indem es super._transfer(swapPair, PROOF, deficit) aufruft, gefolgt von sync(), das LML direkt aus den Reserven des LP-Paares zieht und den gespeicherten Zustand des Paares neu ausrichtet, anstatt einen normalen Tausch durchzuführen. Da dieser Pfad die Preisentdeckung des Paares umgeht, reduziert jeder Anspruch, der ihn auslöst, die LML-Reserven des Paares und verschiebt den Spotpreis weiter, ohne dass es zu einem entsprechenden Token-Zufluss kommt. Wiederholte Ansprüche vergrößern somit mechanisch die Lücke zwischen dem gefrorenen gespeicherten Preis und dem Live-Verkaufspreis.

Angriffsanalyse

Die folgende Analyse basiert auf den Transaktionen 0x805d...5b47, 0x70f7...3572.

• Schritt 1: Der Angreifer sammelte durch Flash-Loans von Moolah, Darlehen von Venus und Moolah Pool (mit WBNB als Sicherheit) sowie Flash-Loans von PancakeSwap V4, mehreren V3-Pools und V2-Pools eine große Menge USDT und WBNB. Dieses Kapital wurde benötigt, um den Preis des LML/USDT-Paares zu manipulieren.

• Schritt 2: Der Angreifer rief swapAndTrans() auf dem LML-Token-Vertrag auf, der die im Vertrag angesammelten LML-Gebühren in USDT tauschte. Dies entzog dem eigenen LML-Guthaben des LML-Vertrags, was bedeutete, dass er kein lokales Token-Angebot mehr bereitstellen konnte; jede nachfolgende Belohnungsverteilung müsste LML über swapBack() aus dem LP-Paar ziehen.

• Schritt 3: Der Angreifer tauschte USDT gegen LML über den PancakeRouter swapExactTokensForTokensSupportingFeeOnTransferTokens mit dem Empfänger auf die tote Adresse gesetzt. Die gekauften LML-Token wurden verbrannt, anstatt vom Angreifer empfangen zu werden. Der alleinige Zweck war es, LML aus dem Paar zu ziehen und den LML-Preis auf dem AMM in die Höhe zu treiben; der Angreifer brauchte die Token selbst nicht, nur die Preisverzerrung.

• Schritt 4: Der Angreifer hatte zuvor mit 11 EOA-Adressen in das Staking-Protokoll eingezahlt. Da APower's receive() _claimReward(msg.sender) basierend auf msg.sender auslöst, können Belohnungen nur von der einzahleenden Adresse selbst beansprucht werden. Um Belohnungen für alle 11 EOAs innerhalb einer einzigen Transaktion zu beanspruchen, verwendete der Angreifer EIP-7702, um diesen EOAs Code zuzuweisen, was ihnen erlaubte, als Verträge vom Hauptkontrakt des Angreifers aufgerufen zu werden. Jede EOA führte eine Funktion transfer(rst, fte) aus, die eine kleine Menge BNB an APower sendete, was receive() und _claimReward(EOA) auslöste. Innerhalb jeder Prämie: updatePrice() wurde übersprungen (3600s-Cooldown nicht erreicht, daher blieb stored_price auf dem historischen niedrigen Wert), updateUser() berechnete die Belohnung unter Verwendung des veralteten niedrigen Preises, sendMining() transferierte LML von PROOF an APower und löste dann swapBack() aus, das PROOF auffüllte, indem es LML aus dem LP-Paar zog und sync() aufrief, wodurch die Reserven des Paares weiter reduziert wurden. Schließlich verteilte claimReward() LML an die EOA, und jede EOA transferierte ihre erhaltene LML zurück an den Angreifervertrag.

• Schritt 5: Der Angreifer tauschte die angesammelte LML über den nun stark entleerten Pool zum extrem aufgeblähten Preis zurück in USDT.

• Schritt 6: Rückzahlung aller Flash-Loans, Kredite und Gebühren. Übertragung des verbleibenden Gewinns.

Schlussfolgerung

Die Hauptursache ist eine Diskrepanz zwischen Belohnungsakkumulation und -einlösung im Staking-Protokoll: Auszahlungen werden basierend auf einem gespeicherten LML/USDT-Preis berechnet, der hinter einem 3600-Sekunden-Cooldown gesperrt ist, aber in LML abgerechnet, deren realer Wert dem Live-AMM-Preis folgt, ohne dass eine Abweichungsprüfung die beiden verbindet. Der swapBack()-Nachfüllpfad verstärkt diesen Fehler, indem er bei jedem Anspruch LML direkt aus dem LP-Paar zieht und somit die Lücke zwischen dem gefrorenen gespeicherten Preis und dem Live-Verkaufspreis mechanisch vergrößert, je mehr Ansprüche verarbeitet werden.

Staking-Protokolle, die Belohnungen basierend auf AMM-abgeleiteten Preisen bemessen, sollten eine Abweichungsprüfung zwischen dem gespeicherten Preis und dem aktuellen Spotpreis zum Zeitpunkt des Anspruchs durchsetzen und zurückweisen, wenn die Lücke einen sicheren Schwellenwert überschreitet. Außerdem sollten sie Nachfüllmechanismen vermeiden, die LP-Reserven außerhalb normaler Swap-Pfade verändern, da solche Mechanismen die Preisentdeckung umgehen, die andernfalls den Schaden aus veralteter Preisgestaltung begrenzen würde.

6. Tactile Vorfall

Kurze Zusammenfassung

Am 1. April 2026 erlitt Tactile, ein gestaffeltes Einlagenprotokoll auf Polygon, einen Verlust von rund 12.000 US-Dollar. Die Hauptursache war eine Inkonsistenz in der Ein- und Auszahlungsabwicklungslogik: Sowohl Ein- als auch Auszahlungen wurden gegen den aktuellen Spotpreis von CES abgerechnet, und die interne Aktie trug keine Aufzeichnung des Asset-Werts, zu dem sie ursprünglich geprägt wurde. Der Angreifer nutzte dies aus, indem er den Spotpreis vor der Einzahlung aufpumpte, um übermäßige Anteile zu erhalten, dann den Preis vor der Auszahlung senkte, um mehr CES pro Aktie einzulösen, und den Zyklus über Hilfskontrakte wiederholte, um Gewinn zu erzielen.

Hintergrund

Tactile ist ein gestaffeltes Einlagenprotokoll auf Polygon, bei dem Benutzer CES gemäß einer ausgewählten Stufe in einen Zahlungsvertrag einzahlen. Der erforderliche Einzahlungsbetrag wird aus dem aktuellen Spotpreis von CES und der Stufenkonfiguration berechnet, und der Benutzer erhält eine interne Abrechnungsaktie, die seine Position darstellt. Bei der Auszahlung wird die aufgezeichnete Aktie nicht gegen den ursprünglich eingezahlten Betrag abgerechnet, sondern stattdessen gegen den Spotpreis zum Zeitpunkt des Ausstiegs in CES umgerechnet, so dass die Benutzerguthaben effektiv als preisabhängige Abrechnungseinheiten und nicht als feste Asset-Beträge verfolgt werden.

Schwachstellenanalyse

Der Kernfehler im Zahlungsvertrag (0x9153e1...09b654) besteht darin, dass Einzahlung und Auszahlung gegen dasselbe Spotpreis-Orakel zu zwei verschiedenen Zeitpunkten abgerechnet werden, ohne einen unveränderlichen Anker, der sie verbindet. Zum Zeitpunkt der Einzahlung liest der Vertrag getActualPrice() und wandelt die eingezahlten CES auf Basis des aktuellen Preises in eine interne Aktie um. Zum Zeitpunkt der Auszahlung wird dieselbe Aktie mit dem Spotpreis zum Zeitpunkt der Einlösung wieder in CES umgewandelt.

Da die Aktie selbst keinen Aufzeichnung über den Preis oder den Asset-Betrag enthält, zu dem sie geprägt wurde, führt jede Bewegung des Spotpreises zwischen diesen beiden Zeitpunkten zu einer Diskrepanz zwischen eingezahltem CES und ausgezahltem CES, wodurch die Buchhaltung des Protokolls vollständig dem Preisverlauf und nicht dem zugrundeliegenden Asset-Wert ausgesetzt ist.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xc321...da74.

• Schritt 1: Der Angreifer lieh sich zunächst 55.365e18 CES aus einem Uniswap V3 Flash-Pool und verteilte die Gelder auf 5 Hilfskontrakte. Jeder Hilfskontrakt erhielt zunächst 6.426e18 CES und rief dann deposit(12) auf. Während dieses Prozesses fragte jeder Hilfskontrakt zunächst getPriceForLevel(12) ab und bereitete dann den für diese Einzahlung erforderlichen CES-Betrag basierend auf dem aktuellen Preis vor.

• Schritt 2: Nachdem alle 5 Hilfskontrakte die erste Runde deposit abgeschlossen hatten, verkaufte der Angreifer 300.000 CES auf dem DEX, wodurch der vom bank verwendete Preis von 1,067585 auf 0,688542 fiel. Die 5 Hilfskontrakte führten dann nacheinander withdraw aus und lösten die zuvor zu einem hohen Preis erstellten Aktien zum nun niedrigeren Preis in CES ein. Jeder Hilfskontrakt erhielt 9.427e18 CES.

• Schritt 3: Nach Abschluss der ersten Runde withdraw tauschte der Angreifer den erworbenen Gegenwert-Asset zurück in CES und trieb den Preis damit wieder nach oben. Der Angreifer wiederholte dann die Schritte 2-3.

• Schritt 4: Schließlich, nach mehreren Angriffszyklen und nach Rückzahlung des Flash-Loans plus der Flash-Gebühr von 166.097975017841805126 CES, behielt der Angreifer 567.736e18 CES als Gewinn.

Schlussfolgerung

Die Hauptursache dieses Vorfalls liegt darin, dass Tactile sowohl die Ein- als auch die Auszahlung gegen einen manipulierbaren Spotpreis abgerechnet hat, ohne die Abrechnungsaktie an den Asset-Betrag oder den Preis zum Zeitpunkt der Einzahlung zu binden, wodurch seine interne Buchhaltung vollständig jeder Preisbewegung zwischen Eintritt und Austritt ausgesetzt war.

Protokolle, die Aktien-ähnliche Positionen gegen ein volatiles Asset ausgeben, sollten jede Aktie an den konkreten Asset-Betrag oder Preis zum Zeitpunkt der Prägung binden, damit die Rücknahme den ursprünglichen wirtschaftlichen Wert reproduziert und nicht gegen ein Live-Orakel neu bewertet wird. Wo Abrechnungsfunktionen einen aktuellen Preis referenzieren müssen, sollten sie zeitgewichtete oder anderweitig manipulationsresistente Quellen verwenden und vermeiden, denselben Spotpreis zu lesen, der durch Transaktionen bewegt werden kann, die in derselben Transaktion wie der Abrechnungsaufruf ausgeführt werden.

7. SAS Token Vorfall

Kurze Zusammenfassung

Am 2. April 2026 wurde der SAS-Token auf der BNB Chain für rund 12.000 US-Dollar ausgenutzt. Die Hauptursache war ein Fehler in der benutzerdefinierten Übertragungslogik des Tokens: Das Senden von SAS an den LP-Pool erhöhte nur einen globalen sellBurn-Zähler, und jede nachfolgende normale Übertragung konnte dann SAS direkt aus dem Pool verbrennen und sync() aufrufen, um seine Reserven neu zu schreiben, alles ohne den AMM-Swap-Logik zu durchlaufen. Der Angreifer nutzte dies aus, indem er sellBurn durch Verkäufe ansammelte, eine nicht verwandte normale Übertragung auslöste, um SAS aus dem Pool zu verbrennen und seine Reserve auf 1 Wei zu reduzieren, und dann den verbleibenden SAS für Gewinn zurücktausch.

Hintergrund

SAS ist ein deflationärer Token auf der BNB Chain mit benutzerdefinierter Übertragungslogik, die auf einem PancakeSwap V2-Pool aufbaut. Seine transfer()-Funktion unterscheidet zwischen zwei Pfaden: einem Verkaufs-Pfad, der ausgelöst wird, wenn das Ziel einer Übertragung der LP-Pool ist und der einen globalen sellBurn-Akkumulator um den übertragenen Betrag erhöht; und einem normalen Übertragungs-Pfad, der, wenn sellBurn nicht null ist, SAS direkt aus dem LP-Pool verbrennt und dann sync() aufruft, um seine Reserven an das neue On-Chain-Guthaben anzupassen. Die beiden Pfade sollen zusammen als deflationärer Mechanismus fungieren, der die SAS-Reserve des Pools als Reaktion auf kumulativen Verkaufsdruck reduziert.

Schwachstellenanalyse

Der Kernfehler im SAS-Token-Vertrag (0xbfa266...3d91c6) liegt darin, wie der deflationäre Mechanismus in transfer() verdrahtet ist. Wenn SAS an den LP-Pool gesendet wird, erhöht der Vertrag einen globalen sellBurn-Akkumulator um den übertragenen Betrag. Dann ruft bei jeder späteren normalen Übertragung, wenn sellBurn nicht null ist, der Vertrag _burnFromPair() auf, um SAS direkt aus dem LP-Pool zu verbrennen, und folgt ihm mit sync(), das die Reserven des Pools neu schreibt, um seinem On-Chain-Guthaben zu entsprechen.

Das Problem ist, dass dieser Verbrennungs- und Synchronisationspfad die Reserven des Pools neu schreibt, ohne die AMM-Swap-Logik zu durchlaufen. Sobald sellBurn durch Übertragungen in den Pool erhöht wurde, reicht eine nicht verwandte normale Übertragung aus, um den Verbrennungs- und Synchronisationsvorgang auszulösen, wodurch die SAS-Reserve des Pools gegen Null gedrängt und eine große Preisverzerrung erzeugt wird, die dann durch einen normalen Tausch geerntet werden kann.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x878e...adc5.

• Schritt 1: Der Angreifer lieh sich WBNB über einen Flash-Loan.

• Schritt 2: Der Angreifer tauschte WBNB gegen SAS.

  

• Schritt 3: Der Angreifer setzte einen Vertrag ein und führte die Angriffslogik im constructor() aus. Dies wurde verwendet, um die is_contract()-Prüfung des Protokolls zu umgehen, da der Tokenvertrag verlangte, dass transfer() von einer Whitelist-Adresse oder einer EOA stammt.

• Schritt 4: Der Angreifer transferierte SAS an den Pool, was den Verkaufspfad auslöste und sellBurn ansammelte.

• Schritt 5: Der Angreifer setzte einen zweiten Vertrag ein und löste, ebenfalls in seinem constructor(), eine normale Übertragung aus. Da sellBurn bereits aus Schritt 4 ungleich null war, löste diese Übertragung die Funktion _burnFromPair() aus, die SAS direkt aus dem LP-Pool verbrannte und dann die Funktion sync() aufrief, wodurch die SAS-Reserve auf 1 Wei reduziert wurde.

• Schritt 6: Der Angreifer führte einen Rücktausch durch und verkaufte den verbleibenden SAS mit Gewinn.

Schlussfolgerung

Die Hauptursache dieses Vorfalls liegt in einem Fehler in der benutzerdefinierten Übertragungslogik des SAS-Tokens: Eine normale Übertragung konnte SAS direkt aus dem LP-Pool verbrennen und seine Reserven an den reduzierten Saldo synchronisieren, wodurch kumulative Verkaufsaktivitäten in eine beliebige Reduzierung der SAS-Reserve des Pools und von dort in eine große Preisverzerrung umgewandelt werden konnten, die dann durch einen normalen Tausch geerntet werden konnte.

Token sollten nicht in einen externen AMM-Pool greifen und dessen Reserven außerhalb normaler Swap-Pfade verändern. Wenn ein deflationäres Design tatsächlich das Verbrennen aus einem Pool erfordert, müssen das Verbrennen und das begleitende sync() an einen eng kontrollierten internen Auslöser gebunden sein, wie z. B. einen vertrauenswürdigen Keeper oder einen ratenbegrenzten Zeitplan, anstatt sich auf beliebige Benutzertransfers zu verlassen.

8. Unknown-EIP-7702 Vorfall

Kurze Zusammenfassung

Am 3. April 2026 wurde ein Benutzerkonto auf der BNB Chain, das die delegierte Codeausführung über EIP-7702 aktiviert hatte, für rund 17.200 US-Dollar geleert. Der delegierte Code exponierte eine pancakeV3SwapCallback()-Funktion ohne ordnungsgemäße Zugriffskontrolle. Der Angreifer rief diesen Callback direkt mit präparierten Calldata auf, wodurch das Konto des Opfers gezwungen wurde, seine Token an eine vom Angreifer kontrollierte Adresse zu übertragen.

Hintergrund

Die EOA des Opfers verwendete eine EIP-7702 Typ-4-Transaktion, um delegierten Code festzulegen, damit das Konto Swap-bezogene Logik ausführen konnte. Die delegierte Implementierung enthielt jedoch eine öffentliche pancakeV3SwapCallback()-Funktion, die nur während eines legitimen PancakeSwap V3-Pool-Callbacks aufgerufen werden sollte.

Schwachstellenanalyse

Die Hauptursache ist das Fehlen einer Zugriffskontrolle in der pancakeV3SwapCallback()-Funktion des delegierten Vertrags (0x02C809...aEDbAE).

Bei einem korrekten UniswapV3/PancakeV3 Callback-Design muss der Callback überprüfen, ob msg.sender der erwartete kanonische Pool ist (abgeleitet von Fabrik + Token-Paar + Gebühr oder verifiziert gegen eine vertrauenswürdige Pool-Liste). In diesem Fall fehlte diese Validierung, so dass jeder externe Aufrufer den Callback direkt aufrufen konnte.

Da der Callback Token-Übertragungen von dem Konto ausführt, das ihn hostet, bedeutet die fehlende msg.sender-Prüfung, dass jeder externe Aufruf mit positiven amount0Delta/amount1Delta in den Zahlungspfad innerhalb des Callbacks gelangt und Token aus dem Konto des Opfers bewegt, ohne dass ein tatsächlicher Swap stattfindet.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x5b2c...4261.

• Schritt 1: Der Angreifer rief direkt pancakeV3SwapCallback() mit präparierten Parametern auf, wodurch die Callback-Übertragungslogik ausgelöst wurde, um die Token des Opfers an vom Angreifer kontrollierte Adressen zu übertragen.

Schlussfolgerung

Dieser Vorfall wurde durch die Bereitstellung von Swap-Callback-Logik auf einem EIP-7702-Konto ohne strenge Callback-Authentifizierung verursacht. Da pancakeV3SwapCallback() die Zugriffskontrolle vermissen ließ, konnte der Callback von jedem externen Aufrufer aufgerufen und verwendet werden, um Token aus dem Konto des Opfers zu bewegen, ohne dass jemals ein legitimer Swap stattfand.

Für jeden Vertrag oder delegierten EIP-7702-Code, der V3-artige Callbacks implementiert, müssen Entwickler überprüfen, ob msg.sender der kanonische PancakeV3-Pool ist (abgeleitet von der vertrauenswürdigen Fabrik, dem Token-Paar und der Gebührenstufe), bevor der Callback in eine Übertragungslogik eintritt.

9. Silo Finance Vorfall

Kurze Zusammenfassung

Am 3. April 2026 wurde der Silo Finance soUSDC-Tresor auf Arbitrum für rund 359.000 US-Dollar ausgenutzt. Die Hauptursache war die Konvergenz von drei Mängeln: ein unveränderliches wstUSR-Orakel, das den Token immer noch mit ca. 1,133 bewertete, nachdem sein Marktpreis auf ca. 0,12 gefallen war; ein Einzahlungskapazitätsmechanismus für soUSDC, der nur die eigenen Einlagen des Tresors beschränkte, aber nicht die externen; und ein totalAssets()-Buchhaltungsfehler, der extern gutgeschriebene bUSDC-Anteile zählte, ohne entsprechende soUSDC-Anteile zu prägen. Durch die Einzahlung von USDC direkt in den Null-Kapazitäts-wstUSR-Markt mit receiver=soUSDC blähte der Angreifer den Anteilspreis des Tresors auf, lieh sich dieselben USDC gegen überbewertete wstUSR-Sicherheiten zurück und löste zuvor erworbene soUSDC-Anteile zur aufgeblähten Bewertung ein, wobei die Differenz aus anderen gesunden Märkten in der Auszahlungswarteschlange entnommen wurde.

Hintergrund

Silo Finance ist ein risikoisolierter Kreditprotokoll auf Arbitrum. Jeder Silo-Markt ist ein zweiseitiges Kreditpaar (z. B. wstUSR/USDC): Kreditnehmer hinterlegen Sicherheiten (wstUSR) und leihen das Kredit-Asset (USDC), während Kreditgeber USDC einzahlen und Zinsen verdienen. Wenn ein Kreditgeber USDC in einen bestimmten Markt einzahlt, erhält er den Einzahlungsanteil-Token dieses Marktes. Wenn ein Kreditnehmer Sicherheiten hinterlegt, erhält er einen Sicherheitenanteil-Token (z. B. bwstUSR-149).

soUSDC ist ein SiloVault, das mehrere Silo-Märkte überlagert, um USDC-Kredite zu aggregieren. Benutzer zahlen USDC in soUSDC ein und erhalten soUSDC-Anteile. Der Tresor leitet die eingezahlten USDC dann basierend auf den vom Allocator festgelegten Angebotsobergrenzen in genehmigte Silo-Märkte weiter, und der Tresor selbst hält die bUSDC-Anteile jedes Marktes, in den er eingezahlt hat. Wenn ein Benutzer soUSDC-Anteile einlöst, berechnet der Tresor, wie viel USDC die Anteile wert sind, indem er totalAssets() verwendet, das jeden Markt in der Auszahlungswarteschlange durchläuft und das bUSDC-Anteilsguthaben des Tresors in jedem Markt summiert. Der Tresor zieht dann USDC aus seinen zugrundeliegenden Märkten ab, um den Einlöser zu bezahlen.

wstUSR (Wrapped Staked USR) ist ein Staking-Derivat des USR-Stablecoins, der von Resolv ausgegeben wird. Nachdem Resolv ausgenutzt worden war, verlor USR seinen Peg, stUSR verlor ebenfalls seinen Peg, und der Marktpreis von wstUSR fiel auf ca. 0,12. Die Chainlink-Feed für wstUSR verfolgte jedoch nur die wstUSR/stUSR-Austauschrate (ca. 1,133), und das Protokoll ging implizit davon aus, dass 1 stUSR = 1 USD, so dass das Orakel wstUSR weiterhin mit ca. 1,133 bewertete, eine Lücke von etwa 10x gegenüber der Marktrealität.

Schwachstellenanalyse

Die Orakeladresse des wstUSR/USDC-Marktes ist in SiloConfig fest codiert und unveränderlich und kann nicht ersetzt werden. Der Orakelvertrag selbst (0x836a1a...04425e) ist ein ChainlinkV3Oracle, dessen zugrundeliegender Chainlink-Feed (Beschreibung: "wstUSR / stUSR Exchange Rate") nur das Wrapping-Verhältnis von wstUSR zu stUSR (ca. 1,133) verfolgt und nicht den Sekundärmarktpreis. Das Protokoll geht implizit davon aus, dass 1 stUSR = 1 USD, so dass es wstUSR mit ca. 1,133 bewertet. Nachdem USR seinen Peg verloren hatte, verlor auch stUSR seinen Peg und wstUSR fiel auf dem offenen Markt auf ca. 0,12, aber das Orakel meldete weiterhin ca. 1,133, eine etwa 10-fache Überbewertung.

Das Protokoll war sich der Gefahr teilweise bewusst: Die Versorgungsobergrenze für den wstUSR-Markt von soUSDC war auf 0 gesetzt, was bedeutet, dass der Tresor nie freiwillig USDC dorthin leiten würde. Diese Obergrenze regelt jedoch nur die ausgehenden deposit()-Aufrufe des Tresors selbst. Da wstUSR_Market.deposit() einen beliebigen receiver-Parameter akzeptiert, kann jeder USDC direkt in den wstUSR-Markt einzahlen und die resultierenden bUSDC-Anteile an die Adresse von soUSDC gutschreiben, wodurch die Angebotsobergrenze vollständig umgangen wird.

Dies schafft den Kern-Exploit-Pfad. Wenn bUSDC-Anteile über eine solche externe Einzahlung im soUSDC-Guthaben landen, zählt totalAssets() sie: Es durchläuft jeden Markt in der Auszahlungswarteschlange und liest das tatsächliche Guthaben der Anteile des Tresors, ohne zu prüfen, ob die Position freiwillig eingegangen wurde. In der Zwischenzeit werden keine neuen soUSDC-Anteile für diese extern gutgeschriebenen Positionen geprägt, da die eigene Prägelogik des Tresors nie aufgerufen wurde – totalAssets steigt, totalShares bleibt gleich, und der soUSDC-Anteilspreis steigt. Gleichzeitig schafft dies USDC-Liquidität im zuvor leeren wstUSR-Markt, die für den nächsten Schritt benötigt wird.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xf77a...f3e1.

Der Angreifer kaufte zunächst wstUSR auf dem Sekundärmarkt zu ca. 0,12 pro Token.

• Schritt 1: Leihe per Flash-Loan rund 4.236.352 USDC von Morpho. Die Orakel-Fehlbewertung allein reicht nicht aus – der wstUSR-Markt hatte keine USDC-Liquidität (Cap=0, soUSDC hat dort nie eingezahlt), daher gibt es nichts, was gegen die überbewertete Sicherheit geliehen werden kann. Der Flash-Loan stellt das für die nachfolgenden Ein- und Spenden-Schritte benötigte Kapital bereit.

• Schritt 2: Zahle wstUSR in den wstUSR-Markt als Sicherheit ein und erhalte bwstUSR-149. Dies ist eine Vorbereitung für die Anleihe in Schritt 5 – das Orakel bewertet 13.797 wstUSR mit ca. 15.633 (zu je 1,133), obwohl der Angreifer nur ca. 1.656 bezahlt hat.

• Schritt 3: Zahle ca. 4.222.007 USDC in den soUSDC-Tresor ein und erhalte soUSDC-Anteile (ca. 91,5% des Gesamtangebots). Der Tresor leitet diese USDC in bestehende gesunde Märkte (nicht den wstUSR-Markt, da Cap=0) weiter. Diese soUSDC-Anteile sind das Instrument zur Gewinnrealisierung in Schritt 6 – je mehr Anteile der Angreifer hält, desto mehr profitiert er, wenn der Anteilspreis aufgebläht wird.

• Schritt 4: Zahle ca. 14.344 USDC direkt in den wstUSR-Markt über wstUSR_Market.deposit(receiver=soUSDC) ein und präge bUSDC-149 für soUSDC. Die resultierenden bUSDC-Anteile werden an die Adresse von soUSDC gutgeschrieben, nicht an die des Angreifers. Dies ist die Kernmanipulation: soUSDCs totalAssets() beinhaltet nun diese bUSDC-Anteile zum Nennwert (ca. 14.344 USDC), aber es werden keine neuen soUSDC-Anteile geprägt, da die eigene Einzahlungslogik des Tresors nie aufgerufen wurde – totalAssets steigt, totalShares bleibt gleich, und der soUSDC-Anteilspreis steigt. Gleichzeitig schafft dies USDC-Liquidität im zuvor leeren wstUSR-Markt, die für den nächsten Schritt benötigt wird.

• Schritt 5: Leihe ca. 14.344 USDC aus dem wstUSR-Markt unter Verwendung der in Schritt 2 hinterlegten Sicherheiten. Das Orakel bewertet die Sicherheiten mit ca. 15.633, so dass bei 92% maximalem LTV der Angreifer ca. 14.344 leihen kann. Dies deckt die in Schritt 4 gespendeten USDC ab – die Anleihe und die Spende sind Cash-neutral. Aber der wstUSR-Markt ist nun vollständig entleert: Alle USDC wurden ausgeliehen, es verbleibt nur eine ausstehende Anleihe, die durch nahezu wertlose wstUSR-Sicherheiten gedeckt ist. soUSDC hält immer noch die bUSDC-Anteile zum Nennwert in totalAssets().

• Schritt 6: Löse alle in Schritt 3 erworbenen soUSDC-Anteile ein. Der Anteilspreis ist nun durch die Spende aus Schritt 4 aufgebläht, so dass der Angreifer ca. 4.235.143 USDC erhält, ca. 13.136 mehr als die 4.222.007, die in Schritt 3 eingezahlt wurden. Der Tresor versucht, aus dem wstUSR-Markt abzuheben, findet aber keine Liquidität (in Schritt 5 ausgeliehen), so dass er die Differenz aus anderen gesunden Märkten in der Auszahlungswarteschlange zieht. Hier materialisiert sich der Verlust: reale USDC aus anderen Märkten von soUSDC-Einlegern wird transferiert, um die aufgeblähte Rücknahme zu decken.

• Schritt 7: Rückzahlung des Flash-Loans.

Nach 32 Schleifen verbleibt soUSDC mit bUSDC-Positionen im wstUSR-Markt, die zum Nennwert von ca. 359.000 bewertet sind, aber durch wstUSR-Sicherheiten gedeckt sind, die einen Bruchteil davon wert sind – 100% Auslastung, effektiv uneinbringliche faule Schulden, die von den verbleibenden soUSDC-Einlegern getragen werden.

Schlussfolgerung

Dieser Vorfall wurde durch die Konvergenz eines Orakels, das einen Staking-Austauschkurs statt des Marktpreises eines depeggten Assets verfolgte, eines Tresor-Buchhaltungssystems, das extern gutgeschriebene Positionen in totalAssets() zählte, ohne entsprechende Anteile zu prägen, und eines Versorgungsgrenzen-Mechanismus, der nur die eigenen Einlagen des Tresors, nicht aber externe, beschränkte, verursacht. Die Orakeladresse, die in SiloConfig fest kodiert war, verhinderte eine Notfallkorrektur, nachdem das Problem offensichtlich geworden war.

Tresorprotokolle, die über Kreditmärkte aggregieren, sollten sicherstellen, dass totalAssets() nur Positionen zählt, die der Tresor über seine eigenen Einzahlungsoperationen eingegangen ist, nicht extern gutgeschriebene Guthaben. Orakeladressen sollten nicht dauerhaft unveränderlich sein; es sollten Notfall-Governance-Mechanismen für Preis-Feed-Aktualisierungen vorhanden sein, wenn zugrundeliegende Assets ihren Peg verlieren.

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei 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-Sicherheitsartikel auf angesehenen Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe von 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/

• Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance