Web3-Sicherheitsvorfälle der Woche | 16. – 22. März 2026

Während der vergangenen Woche (16.03.2026 - 22.03.2026) hat BlockSec sieben Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtschäden von rund 82,7 Millionen US-Dollar. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall werden in den nachfolgenden Unterabschnitten bereitgestellt.

*Der Venus-Vorfall wurde im Bericht der letzten Woche nicht behandelt und ist hier der Vollständigkeit halber enthalten.

1. Venus Vorfall

Kurze Zusammenfassung

Am 15. März 2026 wurde der THE (Thena)-Markt des Venus-Protokolls auf der BNB-Kette Opfer eines Spendenangriffs in Kombination mit Marktmanipulation, was zu uneinbringlichen Forderungen von rund 2,15 Millionen US-Dollar führte. Die Deckelung der angebotenen Menge des THE-Marktes galt nur für den Mint-Pfad, während direkte Token-Spenden in den Markt weiterhin den cash-Wert erhöhten und den exchangeRate aufblähten. Der Angreifer nutzte dann diesen aufgeblähten Kollateralwert, um liquide Vermögenswerte zu leihen, mehr THE zu erwerben und dabei den Marktpreis von THE zu treiben, was letztendlich zu uneinbringlichen Forderungen für das Protokoll führte, nachdem die Position zwangsliquidiert wurde.

Hintergrund

Venus ist ein auf Compound V2 basierendes Kreditprotokoll. Im THE-Markt hinterlegen Nutzer THE und erhalten vTHE-Token. Der exchangeRate bestimmt, wie viel der zugrunde liegenden Vermögenswerte des Marktes jeder vTHE repräsentiert, und seine Kernformel lautet:

exchangeRate = (cash + borrows - reserves) / totalSupply

Hierbei ist cash der zugrunde liegende Token-Saldo des Marktes, borrows ist die gesamte ausstehende Schuld, reserves sind protokolleigene Reserven und totalSupply ist die gesamte vTHE-Angebot. Der THE-Markt hat auch eine Angebotsobergrenze, die darauf abzielt, die gesamte Kollateralexposition zu begrenzen.

Schwachstellenanalyse

Dieser Vorfall umfasste zwei sich ergänzende Vektoren gegen den vTHE-Marktvertrag (0x86e0...739f).

Spendenangriff

Das Protokoll leitet cash direkt aus dem rohen Token-Saldo des Marktvertrags ab, was ihn anfällig für Spendenangriffe macht. Jede direkte Überweisung von THE in den vTHE-Marktvertrag erhöht cash und damit den exchangeRate. Der Angreifer nutzte dies aus, um den exchangeRate um etwa das 3,81-fache aufzublähen und den Kollateralwert seiner bestehenden vTHE-Position zu steigern.

Marktmanipulation

Der THE-Token hatte eine geringe On-Chain-Liquidität, was seinen Spotpreis durch relativ bescheidenen Kaufdruck anfällig für Manipulationen machte. Das Orakel des Protokolls ist darauf ausgelegt, Preise abzulehnen, die zu weit von einem Referenzwert abweichen, was extreme Preise für etwa 37 Minuten während des Angriffs korrekt ablehnte. Nachhaltiger Kaufdruck trieb den Preis des THE-Tokens schließlich auf etwa 0,51 US-Dollar, ungefähr das Doppelte seines Preises vor dem Angriff, was das Orakel schließlich akzeptierte.

Diese beiden Vektoren verstärkten sich gegenseitig. Der aufgeblähte exchangeRate durch den Spendenangriff erhöhte den Kollateralwert jeder vTHE-Einheit, während der manipulierte THE-Token-Preis die Kreditkapazität weiter aufblähte. Zusammen ermöglichten sie es dem Angreifer, Kredite in Höhe von rund 14,9 Millionen US-Dollar gegen eine Position aufzunehmen, die das 3,67-fache der Angebotsobergrenze betrug.

Angriffsanalyse

Die folgende Analyse basiert auf der Beispiel-Angriffstransaktion 0xce6e3e...1f5fb0e.

• Schritt 1: Ein mit dem Angreifer verknüpftes Wallet erhielt über neun Monate hinweg 7.447 ETH durch 77 TornadoCash-bezogene Transaktionen. Dieses ETH wurde bei Aave hinterlegt und rund 9,92 Millionen US-Dollar in Stablecoins geliehen, um eine vTHE-Position von etwa 12,2 Millionen THE aufzubauen, was etwa 84 % der 14,5 Millionen THE-Angebotsgrenze entspricht.

• Schritt 2: In der ersten Angriffstransaktion überwiesen sechs Adressen etwa 36 Millionen THE direkt in den vTHE-Marktvertrag. Der Angriffsvertrag lieh sich auch 1,58 Millionen USDC, lieferte diese erneut ein und lieh sich dann etwa 4,6 Millionen THE und überwies sie direkt in vTHE. Dies erhöhte den exchangeRate um etwa das 3,81-fache.

• Schritt 3: In den nachfolgenden Transaktionen lieh sich der Angreifer liquide Vermögenswerte, darunter CAKE, BNB, BTCB und USDC. Der Angreifer kaufte weiterhin THE mit geliehenen Vermögenswerten und spendete mehr THE in vTHE, wodurch eine Schleife entstand, die sowohl die Kreditfähigkeit der Position als auch den Marktpreis des THE-Tokens erhöhte.

• Schritt 4: Der Preis des THE-Tokens stieg von etwa 0,2 US-Dollar, wobei die Binance-Preisquelle kurzzeitig 4 US-Dollar erreichte. Das Orakel des Protokolls lehnte extreme Preise für etwa 37 Minuten ab, bevor es schließlich einen Preis von etwa 0,51 US-Dollar akzeptierte.

• Schritt 5: Bis 20:42 UTC+8 erreichte die Position des Angreifers etwa 53,2 Millionen THE, rund das 3,67-fache der Angebotsobergrenze, mit einer gesamten Kreditexposition von rund 14,9 Millionen US-Dollar.

• Schritt 6: Die Position trat dann in große Liquidationen ein. Etwa 42 Millionen THE-Kollateral wurden in 8.048 Liquidierungstransaktionen von 254 Liquidator-Adressen liquidiert. Während der Verkäufe fiel der THE-Token auf etwa 0,22 US-Dollar. Die Liquidationserlöse konnten die volle Schuld nicht decken, wodurch Venus mit rund 2,15 Millionen US-Dollar Netto-Forderungsausfällen verblieb.

Schlussfolgerung

Dieser Vorfall offenbarte keine neuartige Schwachstelle. Er zeigte, wie ein bekannter Angriffsvektor, methodisch ausgeführt, den gesamten Risikostapel eines Protokolls überwinden kann, wenn jede Schicht davon ausgeht, dass die anderen standhalten werden. Warnsignale waren monatelang On-Chain sichtbar, doch die Lücke zwischen Erkennung und Intervention blieb ungelöst. Die Überbrückung dieser Lücke durch liquiditätsbewusste Risikoparameter, automatisierte Notabschaltungen und positionsbezogene Überwachung ist die zentrale Lektion, die dieser Vorfall für andere Kreditprotokolle hinterlässt.

Für eine detaillierte Analyse siehe unseren Deep-Dive-Beitrag [1].

Referenzen

• [1] https://blocksec.com/blog/venus-thena-donation-attack

2. dTRINITY Vorfall

Kurze Zusammenfassung

Am 17. März 2026 wurde dTRINITY, ein auf Aave V3 basierendes Kreditprotokoll auf Ethereum, über seinen dLEND-Kreditmarkt ausgenutzt, was zu einem Verlust von rund 257,3K US-Dollar führte. Die Hauptursache war die dem Aave V3-Fork inhärente Schwachstelle des leeren Marktes. Wenn ein Reservekonto eine Liquidität nahe Null aufweist, treibt die wiederholte Prämienakkumulation von Flash-Krediten den liquidityIndex auf einen extremen Wert. Sobald die Reservebuchhaltung verzerrt war, nutzte der Angreifer den Präzisionsverlust in den Einzahlungs- und Auszahlungspfaden aus, um Kollateral zu überbewerten, dUSD zu leihen und das eingezahlte cbBTC für einen Nettogewinn zurückzugewinnen.

Hintergrund

dTRINITY umfasst das Stablecoin-System dUSD und dLEND, einen von Aave V3 geforkten Kreditmarkt. Im zentralen L2Pool-Vertrag (0xfda3...e19e84) hat jede Anlage ihr eigenes Reservekonto, und die Reservebuchhaltung basiert auf skalierten Salden und einem Reservestand liquidityIndex. Der aktuelle zugrunde liegende Saldo eines Nutzers ergibt sich aus dem skalierten Saldo multipliziert mit dem normalisierten Ertrag der Reserve.

Flash-Kreditprämien werden über cumulateToLiquidityIndex() zur Reservebuchhaltung hinzugefügt, wobei:

nextLiquidityIndex = ((amount / totalLiquidity) + 1) * reserve.liquidityIndex

Wenn totalLiquidity extrem klein wird, kann jede Prämienakkumulation den liquidityIndex ungewöhnlich schnell nach oben treiben.

Schwachstellenanalyse

Die Schlüsselbedingung für den Angriff war eine nahezu leere Reserve im dLEND-cbBTC-Markt (0x504d...3acc). Sobald die Reserve auf einen einzigen skalierten Anteil komprimiert war, wurden Flash-Kreditprämien nicht mehr über eine sinnvolle Angebotsbasis verteilt. Wiederholte Flash-Kredite führten daher zu einem extrem schnellen Anstieg des liquidityIndex.

Nach der Aufblähung des liquidityIndex geriet die Konvertierung von zugrunde liegenden zu skalierten Werten in einen extremen Rundungsmodus. In diesem Zustand konnte eine kleine Einzahlung eine zusätzliche Aktie prägen, während eine viel größere Auszahlung immer noch nur eine Aktie verbrennen konnte. Diese Asymmetrie erlaubte es dem Angreifer, aCbBTC-Kollateral zu überbewerten und echte dUSD aus einer anderen Reserve zu leihen, da Gesundheitsprüfungen auf Pool-Ebene durchgeführt wurden und die beschädigte cbBTC-Reserve die Kreditaufnahme über verschiedene Anlagen hinweg direkt beeinflusste.

Angriffsanalyse

Der Exploit bestand aus zwei Transaktionen: 0x8d33d6...40ae7139 und 0xbec4c8...4fc33260.

Transaktion 1: liquidityIndex Manipulation

• Schritt 1: cbBTC von Morpho Blue leihen.

• Schritt 2: cbBTC in dLEND-cbBTC einzahlen, um 100 skalierte Anteile zu prägen.

• Schritt 3: 99 Einheiten Anteile abheben, so dass nur 1 Anteil übrig bleibt, wodurch die dLEND-cbBTC-Reserve in einen fast leeren skalierten Angebot-Zustand komprimiert wird.

• Schritt 4: Übertragen Sie 80.000.000 Einheiten cbBTC (d. h. 0,8 cbBTC) direkt an den dLEND-cbBTC aToken.

• Schritt 5: Führen Sie 150 Pool.flashLoan()-Aufrufe aus, um Prämien in die Reservebuchhaltung aufzunehmen und den liquidityIndex auf 6.226.621.999.999.999.999.999.999.979.728.276 zu erhöhen.

• Schritt 6: Führen Sie wiederholte Einzahlungs- und Auszahlungszyklen durch, um verbleibendes Reserveguthaben zu entnehmen.

• Schritt 7: Flash-Kredit zurückzahlen.

Transaktion 2: Gewinrealisierung

• Schritt 1: Erneut cbBTC von Morpho Blue leihen.

• Schritt 2: Rund 7,72 cbBTC in die bereits manipulierte Reserve einzahlen, um eine überbewertete aCbBTC-Kollateralposition aufzubauen.

• Schritt 3: Nutzen Sie das überbewertete Kollateral, um 257.328 dUSD aus dem dLEND-dUSD-Markt zu leihen.

• Schritt 4: Setzen Sie die cbBTC-Entnahme durch wiederholte Einzahlungs-/Auszahlungszyklen fort.

• Schritt 5: Morpho Flash-Kredit zurückzahlen und geliehene dUSD an die Angreifer-EOA übertragen.

Schlussfolgerung

Dieser Vorfall ist ein Beispiel für den Empty-Market-Angriff, der bei Aave V3-Forks gut dokumentiert ist. Dieses Muster ist in mehreren Protokollen aufgetreten, und die Abhilfemaßnahmen sind etabliert. Die Erzwingung eines minimalen Angebotschwellenwerts während der Reserveinitialisierung verhindert, dass die Reserve in einen Zustand gerät, in dem das Indexwachstum außer Kontrolle gerät. Protokolle, die Aave V3 forken, sollten daher die Reserve-Bootstrapping als kritische Operation behandeln und sicherstellen, dass bei der Bereitstellung eine sinnvolle Liquidität gesperrt wird, anstatt sich auf organische Einzahlungsflüsse zur Stabilisierung des Index zu verlassen.

3. Fun.xyz Vorfall

Kurze Zusammenfassung

Am 17. März 2026 wurde Fun.xyz, ein Checkout-Infrastrukturprotokoll auf Polygon, für rund 85,7K US-Dollar ausgenutzt. Die Hauptursache war, dass der Legacy-CheckoutPool eine kritische Funktion bridge() ohne Zugriffskontrolle und ohne Bindung der Bridge-Calldata an den beabsichtigten Empfänger preisgab. Diese Schwachstelle ermöglichte es dem Angreifer, die Ausführung in den vertrauenswürdigen Abwicklungspfad umzuleiten und Gelder an ein vom Angreifer kontrolliertes Smart-Account zu überweisen.

Hintergrund

CheckoutPool ist der zentrale Abwicklungsvertrag in der Checkout-Infrastruktur von Fun.xyz. Im normalen Ablauf erstellt ein Benutzer einen Checkout über deposit(), und ein vertrauenswürdiger Operator versetzt ihn durch Abwicklungspfade wie bridge() und execute() voran. Für Bridge-Operationen führt bridge() einen externen Aufruf basierend auf den vom Aufrufer bereitgestellten bridgeParams.target und bridgeParams.callData aus.

Schwachstellenanalyse

Die Hauptursache ist, dass der Legacy-CheckoutPool (0x1304...2ec01a) einen sensiblen Abwicklungsrouting-Pfad über die Funktion bridge() ohne angemessene Zugriffskontrolle freigab, während gleichzeitig versäumt wurde, die extern bereitgestellten Bridge-Calldata gegen den beabsichtigten Empfänger zu validieren. Insbesondere:

• Die Legacy-Implementierung erzwang onlyOperator auf bridge() nicht, was es jedem externen Aufrufer ermöglichte, die Funktion nach der Erstellung eines Checkouts über deposit() aufzurufen.

• bridge() übergab die vom Aufrufer bereitgestellten bridgeParams an _bridgeToRecipient(), die einen externen Aufruf durchführte, ohne den Empfänger anhand des Checkout-Datensatzes zu validieren.

Eine zusätzliche operative Bedingung machte den Exploit praktikabel: Der Legacy-CheckoutPool behielt zum Zeitpunkt des Exploits noch Operator-Berechtigungen in CheckoutPaymaster. Dies ermöglichte es dem konstruierten bridge()-Aufruf, CheckoutPaymaster.activateAndCall() zu erreichen, das dann den neueren CheckoutPool.execute()-Pfad aufrief und Gelder an eine vom Angreifer kontrollierte Adresse transferierte.

Angriffsanalyse

Die folgende Analyse basiert auf der Angriffstransaktion 0x957bcf...1f4f5a.

• Schritt 1: Erstellen Sie das ERC-4337-Smart-Account 0xb648 und bezeichnen Sie es sowohl als Sender als auch als Paymaster in der externen UserOperation.

• Schritt 2: Rufen Sie deposit() sowohl im Legacy- als auch im neuen CheckoutPool auf, wodurch ein Checkout-Datensatz im neuen CheckoutPool mit einem Abwicklungsbetrag von 85.730 USDC erstellt wird.

• Schritt 3: Rufen Sie bridge() im Legacy-CheckoutPool mit bösartigen bridgeParams auf: Setzen Sie bridgeParams.target auf CheckoutPaymaster und kodieren Sie bridgeParams.callData als Aufruf von activateAndCall() mit der externen UserOperation als seinem internen Payload.

• Schritt 4: Erreichen Sie execute() im neuen CheckoutPool (0x1929...0215), der 85.730 USDC an 0xb648 transferiert, die Adresse, die als ops[0].sender in der externen UserOperation angegeben ist.

• Schritt 5: Geben Sie EntryPoint.handleOps() ein: Da 0xb648 sowohl als Sender als auch als Paymaster fungiert, bleiben sowohl die Kontenprüfung als auch die Paymaster-Prüfung unter der Kontrolle des Angreifers, was es dem Angreifer ermöglicht, 85.730 USDC zu profitieren.

Schlussfolgerung

Dieser Vorfall wurde durch den Mangel an Zugriffskontrolle und Kalldata-zu-Empfänger-Bindung im bridge()-Pfad des Legacy-CheckoutPool verursacht, was zu Verlusten von rund 85,7K US-Dollar führte. Um ähnliche Vorfälle zu verhindern, sollten Protokolle eine strenge Zugriffskontrolle für sensible Routing- und Abwicklungspfade durchsetzen, sicherstellen, dass extern bereitgestellte Payloads mit protokollgenerierten Empfängern übereinstimmen, und veraltete Verträge aus vertrauenswürdigen Berechtigungsbeziehungen entfernen, sobald gepatchte Ersatzobjekte bereitgestellt werden.

4. Keom Vorfall

Kurze Zusammenfassung

Am 18. März 2026 wurde Keom, ein auf Compound V2 basierendes Kreditprotokoll auf Polygon zkEVM, für etwa 35K US-Dollar ausgenutzt. Die Hauptursache war die fehlerhafte Buchhaltungslogik in redeemFresh(), die von redeemUnderlying() aufgerufen wurde. Die Funktion begrenzte die Aktienreduktion auf den tatsächlichen Saldo des Benutzers, berechnete jedoch den zugrunde liegenden Auszahlungsbetrag nicht entsprechend neu. Diese Diskrepanz ermöglichte es dem Angreifer, weitaus mehr Vermögenswerte zurückzufordern, als seine Aktien erlauben sollten.

Hintergrund

Keom ist ein Kreditprotokoll, das von Compound V2 geforkt wurde. Nutzer zahlen ETH in den Markt ein und erhalten kETH. Wenn ein Nutzer eine Rücknahme tätigt, wandelt das Protokoll kETH-Anteile über den aktuellen Wechselkurs wieder in ETH um. Es gibt zwei Rücknahmestellen im Protokoll: redeem() für die Rücknahme nach Anteilsbetrag und redeemUnderlying() für die Rücknahme nach gewünschtem zugrunde liegendem Betrag.

Schwachstellenanalyse

Der Fehler liegt in redeemFresh() des kETH-Marktes (0x4c6e...0403), der von redeemUnderlying() aufgerufen wird. Der vom Benutzer kontrollierte redeemAmountIn wird zuerst redeemAmount zugewiesen und dann zur Berechnung von redeemTokens über den aktuellen Wechselkurs verwendet. Wenn redeemTokens den Saldo des Einlösenden übersteigt, begrenzt die Funktion ihn auf accountTokens[redeemer]. redeemAmount wird jedoch nach dieser Kappung nicht neu berechnet und bleibt gleich dem ursprünglichen redeemAmountIn. Dies ermöglicht es dem Einlösenden, den vollen redeemAmount an zugrunde liegenden Vermögenswerten abzuheben, während nur ein Bruchteil der entsprechenden Anteile verbrannt wird.

Wie im folgenden Code-Snippet gezeigt, führt redeemFresh() auch eine Gesundheitsprüfung über redeemAllowed() durch. Im Compound V2-Design prüft redeemAllowed() markets[cToken].accountMembership[redeemer] und ruft die Liquiditätsprüfung nur auf, wenn das Konto diesem cToken-Markt beigetreten ist; andernfalls wird die Prüfung vollständig übersprungen. Da redeemAmountIn vom Angreifer kontrolliert wird und beliebig groß eingestellt werden kann, schlägt die Liquiditätsprüfung fehl, wenn kETH immer noch als Kollateral zählt. Das bedeutet, dass der reine Buchhaltungsfehler ohne Umgehung der Gesundheitsprüfung nicht direkt ausnutzbar ist.

Angriffsanalyse

Die folgende Analyse basiert auf der Angriffstransaktion 0x4ccde7...03d9dfd8.

• Schritt 1: Rufen Sie mint() mit nur 0,001 ETH auf und erhalten Sie einen minimalen kETH-Saldo.

• Schritt 2: Rufen Sie exitMarket() auf, um die Mitgliedschaft des Kontos im kETH-Markt zu beenden, so dass redeemAllowed() die Liquiditätsprüfung vollständig umgeht (wie in der Schwachstellenanalyse oben beschrieben).

• Schritt 3: Rufen Sie redeemUnderlying() auf, um den gesamten ETH-Saldo des Marktes (~38,6 ETH) abzuheben und dabei die fehlerhafte Buchhaltung auszunutzen, um ETH aus dem Markt abzuziehen.

Schlussfolgerung

Dieser Vorfall wurde durch eine Buchhaltungsschwachstelle verursacht, die redeemAmount nach der Kappung von redeemTokens auf den tatsächlichen Saldo des Benutzers nicht neu berechnet, was zu Verlusten von rund 35K US-Dollar führte. Die Rücklogik muss alle abhängigen Werte nach jeder Kappung oder Anpassung neu berechnen, um die Invariante von Anteilen zu zugrunde liegenden Werten zu wahren. Compound V2-Forks sollten diesen Pfad sorgfältig überprüfen, da ähnliche Fehler in anderen Derivaten vorhanden sein könnten.

5. ShiMama Vorfall

Kurze Zusammenfassung

Am 18. März 2026 wurde ShiMama, ein deflationäres Token-Protokoll auf BNB Chain, für rund 35K US-Dollar ausgenutzt. Die Hauptursache war ein Mangel an Zugriffskontrolle auf die Funktion executePairBurn(), die es jedem Benutzer ermöglichte, die Auszahlung und das Verbrennen von Paarreserven auszulösen und somit Preismanipulationen zu ermöglichen.

Hintergrund

Das ShiMama-Protokoll enthält einen deflationären On-Chain-Mechanismus, der darauf abzielt, Token aus dem AMM-Paar zu ziehen und zu verbrennen. Dieser Mechanismus ist im ShiMama-Protokoll und im ShiMama-Token implementiert. Die Funktion executePairBurn() im ShiMama-Protokoll berechnet einen Abzugsbetrag aus dem vom Aufrufer bereitgestellten referenceIn-Parameter:

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

Es ruft dann die forcePullFromPair() des ShiMama-Tokens auf, gefolgt von pair.sync() und dem Verbrennen der abgezogenen Token.

Schwachstellenanalyse

Die Hauptursache ist ein Mangel an Zugriffskontrolle auf executePairBurn() im ShiMamaProtocol-Vertrag (0x5049...0b49a). Die Funktion ist extern ohne Einschränkungen aufrufbar, sodass jeder Benutzer privilegierte Reservebewegungen und Paar-Synchronisationen auslösen kann. referenceIn wird ebenfalls vom Aufrufer gesteuert und nicht an einen tatsächlichen Verkaufbetrag gebunden. In ShiMamaToken.forcePullFromPair() kann das Protokoll Salden direkt vom Pancake-Paar verschieben, ohne Einschränkungen, was die willkürliche Entnahme von Reserven zuzüglich sofortiger Synchronisation und damit die Spot-Preis-Manipulation ermöglicht.

Angriffsanalyse

Die folgende Analyse basiert auf der Angriffstransaktion 0x13959b...3c20e001.

• Schritt 1: Leihen Sie WBNB von Moolah flashLoan.

• Schritt 2: Übertragen Sie 30,78e18 ShiMama, die in einer früheren Transaktion vorab beschafft wurden, in den Angriffsvertrag. Da direkte ShiMama-Käufe vom Pancake-Paar deaktiviert waren, beschaffte der Angreifer ShiMama, indem er vor dem Angriff Liquidität im ShiMama-Protokoll bereitstellte und zurückzog.

• Schritt 3: Rufen Sie executePairBurn() auf, um 1.311.349.143,96 ShiMama-Token aus dem Pancake-Paar zu ziehen und zu verbrennen, wodurch der ShiMama-Preis effektiv aufgebläht wird.

• Schritt 4: Der Angreifer tauschte 30,78e18 ShiMama gegen 52,98e18 WBNB auf PancakeSwap zum aufgeblähten Preis.

• Schritt 5: Zurückzahlen des Flash-Kredits, wodurch 52,98 WBNB als Nettogewinn verbleiben.

Schlussfolgerung

Dieser Vorfall wurde durch mangelnde Zugriffskontrolle auf executePairBurn() verursacht, die einen nicht autorisierten Pfad zur Änderung von Poolreserven freigab. Jede Reserve-verändernde Funktion ist wirtschaftlich sensibel und muss streng genehmigungspflichtig sein. Vom Aufrufer gesteuerte Eingaben müssen an protokollgenerierte Werte gebunden werden, um eine Verstärkung der Reserveentnahme zu verhindern.

6. BlindBox Vorfall

Kurze Zusammenfassung

Am 19. März 2026 wurde BlindBox, ein GameFi-Wettprotokoll auf BNB Chain, für rund 99K US-Dollar ausgenutzt. Die Hauptursache war schwache Zufälligkeit, die es dem Angreifer ermöglichte, das Ergebnis vorherzusagen und eine Gewinnquote von 100 % zu erzielen. Darüber hinaus stützte sich getTwapPrice() auf manipulierte Spotpreise anstelle eines echten zeitgewichteten Durchschnitts, was es dem Angreifer ermöglichte, den Poolpreis im Voraus aufzublähen und Wetten zu platzieren, die größer waren als die vom Protokoll vorgesehenen Grenzen.

Hintergrund

Die BlindBox ist ein GameFi-Protokoll, das es Nutzern ermöglicht, Wetten zu platzieren, indem sie ATM-Token an die tote Adresse überweisen. Das Protokoll bestimmt das Ergebnis basierend auf der Parität eines späteren Blockhashes. Wenn die Wette gewinnt, zahlt BlindBox das 1,95-fache des ursprünglichen ATM-Betrags aus der Bankroll der toten Adresse aus. Das Protokoll verwendet getTwapPrice(), um die Größe jedes Einsatzes zu begrenzen.

Schwachstellenanalyse

Der BlindBox-Vertrag (0x1F83...734c59) enthält zwei Schwachstellen:

1. Schwache Zufälligkeit: Wenn die Abwicklungszeit 256 Blöcke überschreitet, gibt blockhash(bet.blockNum + 2) Null zurück. Das Protokoll greift dann auf Zufälligkeit zurück, die von block.prevrandao, betId und block.timestamp abgeleitet wird. Da diese Eingaben vor dem Absenden der Transaktion off-chain simuliert werden können, konnte der Angreifer settle() nur dann aufrufen, wenn das berechnete Ergebnis günstig war, und somit einen deterministischen Gewinn erzielen.

2. Manipulierbare Preisgrenze: Das Protokoll verwendet getTwapPrice(), um die Einsatzgröße zu beschränken. Diese Funktion implementiert jedoch keinen echten zeitgewichteten Durchschnittspreis; stattdessen liest sie den Spotpreis im ATM/USDT-Pool. Dies ermöglicht es Angreifern, die Grenze zu umgehen, indem sie den Poolpreis manipulieren, bevor sie ihre Wette platzieren.

Angriffsanalyse

Die folgenden Schritte veranschaulichen das Angriffsmuster. Schritte 2 und 3 bildeten eine gepaarte Sequenz (z. B. betId=5.284), und der Angreifer wiederholte dieses Paar mehrmals, um den Gewinn zu steigern.

• Schritt 1: Manipulieren Sie den ATM/USDT-Pool, indem Sie den ATM-Spotpreis aufblähen, sodass getTwapPrice() eine größere Einsatzgröße im nächsten Schritt zulässt.

• Schritt 2: Platzieren Sie eine große Wette, indem Sie den aufgeblähten zugelassenen ATM-Betrag an die tote Adresse übertragen (z. B. 0x4be049...3af12c).

• Schritt 3: Warten Sie, bis mehr als 256 Blöcke vergangen sind, sodass blockhash Null zurückgibt und der Fallback-Pfad aktiviert wird. Der Angreifer simulierte dann Ergebnisse off-chain und rief settle() nur dann auf, wenn das berechnete Ergebnis günstig war (z. B. 0x68eedc...718ce8).

Schlussfolgerung

Dieser Vorfall wurde durch vorhersagbare Zufälligkeit in Verbindung mit einem manipulierbaren Spotpreis als TWAP-Eingabe verursacht, was zu Verlusten von rund 99K US-Dollar führte. Um ähnliche Risiken zu reduzieren, sollte das Protokoll jeden Abwicklungspfad entfernen, der nach Ablauf des blockhash-Fensters vorhersagbar wird, und getTwapPrice() durch eine Preisquelle ersetzen, die gegen kurzfristige Reservemanipulationen resistent ist.

7. Resolv Vorfall

Kurze Zusammenfassung

Am 22. März 2026 erlebte Resolv, ein Stablecoin-Protokoll auf Ethereum, eine Kompromittierung seines Infrastrukturschlüssels, die die unbefugte Ausführung von privilegierten Swap-Abschluss-Logik ermöglichte. Bei dem Vorfall nutzte der Angreifer die privilegierte Funktion aus, um über 80 Millionen unbesicherte USR zu prägen. Die Auswirkungen gingen über die direkte Prägeveranstaltung hinaus, da der resultierende USR-Depeg eine breitere Ansteckung über Kreditprotokolle auslöste, bei denen Resolv-Vermögenswerte als Kollateral verwendet wurden.

Hintergrund

Resolv ist ein Stablecoin-Protokoll, bei dem die USR-Ausgabe von kollateralgedeckten Swap-Abwicklungen abhängt. Seine Swap-Abschluss-Pipeline completeSwap() -> mint() -> transfer() wirkt sich direkt auf die im Umlauf befindliche Menge von USR aus und hängt daher sowohl von der Autorisierungsintegrität als auch von der Kollateralintegrität ab. Unter normalen Betriebsbedingungen ist completeSwap() im Resolv-Vertrag (0xa27a...5861) nur von einem privilegierten Infrastrukturschlüssel (im Code als SERVICE_ROLE bezeichnet) aufrufbar, nachdem die entsprechende Kollateraleinzahlung verifiziert wurde.

Schwachstellenanalyse

Der Vorfall war eine Kompromittierung eines privilegierten Schlüssels, der vertrauenswürdige Abwicklungslogik aufrief und den USR-Prägepfad erreichte, ohne dass eine entsprechende Kollateraleinzahlung erfolgte. Sobald der Angreifer die Kontrolle über die privilegierte Signaturautorität erlangte, bot der completeSwap()-Pfad keine On-Chain-Prägevorbedingungen; die Kollateralverifizierung war vollständig von der Off-Chain-Autorisierung abhängig. Dies wandelte eine Kompromittierung der Steuerebene direkt in einen Ausfall der Lieferkettenintegrität um.

Angriffsanalyse

• Schritt 1: Vor dem Exploit reichte der Angreifer eine Swap-Anfrage in Transaktion 0x590b5c...de732c89 ein und bereitete den notwendigen Zustand für die anschließende bösartige Swap-Abwicklung vor.

• Schritt 2: Unter Verwendung des kompromittierten privilegierten Schlüssels rief der Angreifer completeSwap() auf, um über drei Transaktionen mehr als 80.000.000 USR zu prägen: 0xfe37f2...dc33743, 0x41b6b9...db1f18f und 0x7f9143...53a931d.

Schlussfolgerung

Dieser Vorfall unterstreicht, dass die Sicherheit von Stablecoins von harten On-Chain-Prägevorbedingungen abhängt, nicht nur von vertrauenswürdigen Operatorrollen. Bemerkenswerterweise gingen die Auswirkungen dieses Vorfalls weit über die unbefugte Prägung von 80 Millionen US-Dollar hinaus. Da Resolv-Vermögenswerte als Kollateral in mehreren Kreditprotokollen weit verbreitet waren, löste der Depeg eine breitere Ansteckung aus. Wie von Chaos Labs berichtet, fehlten On-Chain-Kuratoren mit automatisierten ertragsorientierten Allokationen Echtzeit-Risikokontrollen, und sie lenkten weiterhin frisches Kapital in bereits beeinträchtigte Märkte. Was als lokalisierter Exploit begann, eskalierte schnell zu einem Cross-Protocol-Ansteckungsereignis, das Kreditprotokolle mit Millionen an uneinbringlichen Forderungen zurückließ.

Über BlockSec

BlockSec ist ein Anbieter von Blockchain-Sicherheit und Krypto-Compliance aus einer Hand. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Durchführung von Code-Audits (einschließlich Smart Contracts, Blockchains und Wallets), Echtzeit-Angriffen, Incident-Analysen, der Rückverfolgung illegaler Gelder und der Erfüllung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.

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 US-Dollar zu retten, und Kryptowährungen im Wert von Milliarden gesichert.

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

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

• 🔗 BlockSec Audit Service: Anfrage senden

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance