Wöchentlicher Web3-Sicherheitsvorfall-Rundown | 16. – 22. März 2026

In der vergangenen Woche (16.03.2026 - 22.03.2026) hat BlockSec sieben Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtverlusten von ca. 82,7 Mio. USD. Die folgende Tabelle fasst diese Ereignisse zusammen, und detaillierte Analysen für jeden Fall sind in den folgenden Unterabschnitten aufgeführt.

1. Venus Incident

Kurze Zusammenfassung

Am 15. März 2026 wurde der THE (Thena)-Markt von Venus Protocol auf der BNB Chain Opfer eines Donation Attacks in Kombination mit Market Manipulation, was zu Schulden von ca. 2,15 Mio. USD führte. Die Obergrenze für Einlagen im THE-Markt galt nur für den Mint-Pfad, während direkte Token-Spenden in den Markt den cash-Wert erhöhten und den exchangeRate aufblähten. Der Angreifer nutzte diesen aufgeblähten Kollateralwert aus, um liquide Vermögenswerte zu leihen, mehr THE zu erwerben und dabei den Marktpreis des THE-Tokens zu steigern, was nach der erzwungenen Liquidation der Position zu Schulden für das Protokoll führte.

Hintergrund

Venus ist ein auf Compound V2 basierendes Kreditprotokoll. Auf dem THE-Markt zahlen Benutzer THE ein und erhalten vTHE-Tokens. 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 Saldo des zugrunde liegenden Tokens des Marktes, borrows die gesamten ausstehenden Schulden, reserves die dem Protokoll gehörenden Rücklagen und totalSupply die gesamte vTHE-Menge. Der THE-Markt hat auch eine Einlagenobergrenze, die die gesamte Kollateralbelastung begrenzen soll.

Schwachstellenanalyse

Dieses Ereignis umfasste zwei sich verstärkende Vektoren gegen den vTHE-Marktvertrag (0x86e0...739f).

Donation Attack

Das Protokoll ermittelt den cash-Betrag direkt aus dem Token-Saldo des Marktvertrags, was ihn anfällig für Donation Attacks macht. Jede direkte Überweisung von THE in den vTHE-Marktvertrag erhöht den cash-Betrag und damit den exchangeRate. Der Angreifer nutzte dies aus, um den exchangeRate um etwa das 3,81-fache zu erhöhen, wodurch der Kollateralwert seiner bestehenden vTHE-Position verstärkt wurde.

Market Manipulation

Der THE-Token hatte eine geringe On-Chain-Liquidität, was seinen Spotpreis anfällig für Manipulationen durch relativ geringen Kaufdruck machte. Das Oracle des Protokolls ist so konzipiert, dass es Preise ablehnt, die zu stark von einem Referenzwert abweichen, und lehnte während des Angriffs für etwa 37 Minuten extreme Preise korrekt ab. Anhaltender Kaufdruck trieb jedoch letztendlich den Preis des THE-Tokens auf etwa 0,51 USD, etwa das Doppelte seines Preises vor dem Angriff, was das Oracle schließlich akzeptierte.

Diese beiden Vektoren verstärkten sich gegenseitig. Der erhöhte exchangeRate durch den Donation Attack verstärkte den Kollateralwert jeder vTHE-Einheit, während der manipulierte THE-Token-Preis die Kreditkapazität weiter erhöhte. Zusammen ermöglichten sie es dem Angreifer, Kredite in Höhe von ca. 14,9 Mio. USD gegen eine Position aufzunehmen, die das 3,67-fache der Einlagenobergrenze betrug.

Angriffsanalyse

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

• Schritt 1: Eine Wallet, die mit dem Angreifer in Verbindung steht, erhielt über 77 TornadoCash-bezogene Transaktionen über etwa neun Monate 7.447 ETH. Dieses ETH wurde bei Aave hinterlegt und ca. 9,92 Mio. USD in Stablecoins geliehen, um eine vTHE-Position von etwa 12,2 Mio. THE aufzubauen, was etwa 84% der 14,5 Mio. THE-Einlagenobergrenze entspricht.

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

• Schritt 3: In den folgenden 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 Kreditwürdigkeit der Position als auch den Marktpreis des THE-Tokens erhöhte.

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

• Schritt 5: Um 20:42 UTC+8 erreichte die Position des Angreifers etwa 53,2 Mio. THE, etwa das 3,67-fache der Einlagenobergrenze, mit einer gesamten Kreditaufnahme von etwa 14,9 Mio. USD.

• Schritt 6: Die Position geriet dann in eine massive Liquidation. Etwa 42 Mio. THE-Kollateral wurden in 8.048 Liquidierungstransaktionen von 254 Liquidator-Adressen liquidiert. Da der Verkauf fortgesetzt wurde, fiel der THE-Token auf etwa 0,22 USD. Die Liquidationserlöse konnten die vollständigen Schulden nicht decken, was bei Venus zu Nettoschulden von ca. 2,15 Mio. USD führte.

Schlussfolgerung

Dieses Ereignis offenbarte keine neuartige Schwachstelle. Es zeigte, wie ein bekannter Angriffsvektor, methodisch ausgeführt, den gesamten Risikostapel eines Protokolls überwältigen kann, wenn jede Ebene davon ausgeht, dass die anderen halten werden. Warnsignale waren monatelang auf der Kette sichtbar, doch die Lücke zwischen Erkennung und Intervention blieb unadressiert. Das Schließen dieser Lücke durch liquiditätsabhängige Risikoparameter, automatisierte Notbremsen und Positionsüberwachung ist die zentrale Lektion, die dieses Ereignis für andere Kreditprotokolle hinterlässt.

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

Referenzen

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

2. dTRINITY Incident

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 ca. 257.328 USD führte. Die Hauptursache war die Schwachstelle des leeren Marktes, die Aave V3-Forks inhärent ist. Wenn ein Reservekonto nahezu null Liquidität aufweist, treibt die wiederholte Accrual von Flash-Loan-Prämien den liquidityIndex auf einen extremen Wert. Sobald die Reservebuchhaltung verzerrt war, nutzte der Angreifer den Präzisionsverlust in den Ein- und Auszahlungsmechanismen aus, um Kollateral zu überbewerten, dUSD zu leihen und das eingezahlte cbBTC zur Realisierung eines Nettogewinns zurückzuziehen.

Hintergrund

dTRINITY umfasst das dUSD-Stablecoin-System und dLEND, einen Kreditmarkt, der von Aave V3 abgezweigt wurde. Im Kern-L2Pool-Vertrag (0xfda3...e19e84) hat jeder Vermögenswert seine eigene Reserve, und die Reservebuchhaltung basiert auf skalierten Salden und einem Reservelevel liquidityIndex. Der aktuelle zugrunde liegende Saldo eines Benutzers leitet sich aus dem skalierten Saldo multipliziert mit dem normalisierten Einkommen der Reserve ab.

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

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

Wenn die totalLiquidity extrem klein wird, kann jede Prämienakkumulation den liquidityIndex abnormal schnell nach oben treiben.

Schwachstellenanalyse

Die Schlüsselbedingung für den Angriff war eine nahezu leere Reserve auf dem dLEND-cbBTC-Markt (0x504d...3acc). Sobald die Reserve auf einen einzigen skalierten Anteil komprimiert war, verteilten sich Flash-Loan-Prämien nicht mehr über eine aussagekräftige Versorgungsgrundlage. Wiederholte Flash-Loans führten daher zu einem extrem schnellen Anstieg des liquidityIndex.

Nach der Aufblähung des liquidityIndex trat die Umrechnung vom zugrunde liegenden Wert in skalierte Werte in eine extreme Rundungsphase ein. In diesem Zustand konnte eine kleine Einzahlung einen zusätzlichen Anteil prägen, während eine viel größere Auszahlung immer noch nur einen Anteil verbrennen konnte. Diese Asymmetrie erlaubte es dem Angreifer, aCbBTC-Kollateral zu überbewerten und reale dUSD aus einer anderen Reserve zu leihen, da Gesundheitschecks auf Pool-Ebene durchgeführt wurden und die korrupte cbBTC-Reserve die Kreditkapazität für verschiedene Vermögenswerte direkt beeinflusste.

Angriffsanalyse

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

Transaktion 1: liquidityIndex-Manipulation

• Schritt 1: Leihen von cbBTC von Morpho Blue.

• Schritt 2: Einzahlung von cbBTC in dLEND-cbBTC zur Prägung von 100 skalierten Anteilen.

• Schritt 3: Auszahlung von 99 Anteilen, sodass nur noch 1 Anteil übrig bleibt, was die dLEND-cbBTC-Reserve in einen nahezu leeren skalierten Lieferzustand komprimiert.

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

• Schritt 5: Ausführung von 150 Pool.flashLoan()-Aufrufen zur Akkumulation von Prämien in der Reservebuchhaltung, wodurch der liquidityIndex auf 6.226.621.999.999.999.999.999.999.979.728.276 erhöht wurde.

• Schritt 6: Wiederholte Ein- und Auszahlungszyklen zur Entnahme von Restbeträgen aus der Reservekasse.

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

Transaktion 2: Gewinnrealisierung

• Schritt 1: Erneutes Leihen von cbBTC von Morpho Blue.

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

• Schritt 3: Nutzung des überbewerteten Kollaterals zur Aufnahme von 257.328 dUSD aus dem dLEND-dUSD-Markt.

• Schritt 4: Fortsetzung der cbBTC-Entnahme durch wiederholte Ein- und Auszahlungszyklen.

• Schritt 5: Rückzahlung des Morpho-Flash-Loans und Überweisung der geliehenen dUSD an die EOA des Angreifers.

Schlussfolgerung

Dieses Ereignis ist ein Beispiel für den "Empty Market Attack", der bei Aave V3-Forks gut dokumentiert ist. Dieses Muster ist in mehreren Protokollen aufgetreten, und die Abhilfemaßnahmen sind gut etabliert. Die Durchsetzung eines minimalen Einlagenvolumens 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 abzweigen, sollten daher die Reserve-Bootstrapping als kritischen Vorgang betrachten 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 Incident

Kurze Zusammenfassung

Am 17. März 2026 wurde Fun.xyz, ein Checkout-Infrastrukturprotokoll auf Polygon, für ca. 85.700 USD ausgenutzt. Die Hauptursache war, dass der ältere CheckoutPool eine kritische Funktion bridge() ohne Zugangskontrolle und ohne Bindung der Bridge-Kalldata an den vorgesehenen Empfänger offengelegt hat. Diese Schwachstelle ermöglichte es dem Angreifer, die Ausführung in den vertrauenswürdigen Abrechnungspfad umzuleiten und Gelder auf ein vom Angreifer kontrolliertes Smart-Account zu übertragen.

Hintergrund

CheckoutPool ist der Kernabrechnungsvertrag in der Checkout-Infrastruktur von Fun.xyz. Im normalen Ablauf erstellt ein Benutzer einen Checkout über deposit(), und ein vertrauenswürdiger Operator führt ihn durch Abrechnungspfade wie bridge() und execute(). Bei 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 ältere CheckoutPool (0x1304...2ec01a) einen sensiblen Abrechnungsrouting-Pfad über die Funktion bridge() ohne ordnungsgemäße Zugangskontrolle offengelegt hat, während er gleichzeitig versäumt hat, die extern bereitgestellten Bridge-Kalldaten gegen den vorgesehenen Empfänger zu validieren. Insbesondere:

• Die ältere Implementierung erzwingte onlyOperator nicht bei bridge(), was es jedem externen Aufrufer erlaubte, die Funktion nach der Erstellung eines Checkouts über deposit() aufzurufen.

• bridge() übergab vom Aufrufer bereitgestellte bridgeParams an _bridgeToRecipient(), die einen externen Aufruf ausführte, ohne den Empfänger gegen den Checkout-Datensatz zu validieren.

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

Angriffsanalyse

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

• Schritt 1: Erstellen des ERC-4337 Smart Accounts 0xb648 und dessen Bezeichnung als Sender und Paymaster in der externen UserOperation.

• Schritt 2: Aufrufen von deposit() sowohl im älteren als auch im neuen CheckoutPool, wodurch ein Checkout-Datensatz im neuen CheckoutPool mit einem Abrechnungsbetrag von 85.730 USDC erstellt wurde.

• Schritt 3: Aufrufen von bridge() im älteren CheckoutPool mit bösartigen bridgeParams: Setzen von bridgeParams.target auf CheckoutPaymaster und Kodieren von bridgeParams.callData als Aufruf von activateAndCall() mit der externen UserOperation als internem Payload.

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

• Schritt 5: Betreten von EntryPoint.handleOps(): Da 0xb648 sowohl als Sender als auch als Paymaster fungiert, bleiben die Konto- und Paymaster-Validierung unter der Kontrolle des Angreifers, was es dem Angreifer ermöglicht, 85.730 USDC zu stehlen.

Schlussfolgerung

Dieses Ereignis wurde durch den älteren CheckoutPool verursacht, dem sowohl Zugangskontrolle als auch die Bindung von Kalldaten an Empfänger auf seinem bridge()-Pfad fehlten, was zu Verlusten von ca. 85.700 USD führte. Um ähnliche Vorfälle zu verhindern, sollten Protokolle strenge Zugangskontrollen für sensible Routing- und Abrechnungsflüsse durchsetzen, sicherstellen, dass extern bereitgestellte Payloads mit protokollbasierten Empfängern übereinstimmen, und veraltete Verträge aus vertrauenswürdigen Privilegienbeziehungen entfernen, sobald gepatchte Ersatzsysteme bereitgestellt werden.

4. Keom Incident

Kurze Zusammenfassung

Am 18. März 2026 wurde Keom, ein auf Compound V2 basierendes Kreditprotokoll auf Polygon zkEVM, für ca. 35.000 USD ausgenutzt. Die Hauptursache war eine fehlerhafte Buchhaltungslogik in redeemFresh(), die von redeemUnderlying() aufgerufen wurde. Die Funktion kappte die Aktienreduzierung auf den tatsächlichen Saldo des Benutzers, berechnete aber den zugrunde liegenden Auszahlungsbetrag nicht entsprechend neu. Dieser Abgleich erlaubte es dem Angreifer, weitaus mehr Vermögenswerte einzulösen, als seine Aktien zulassen sollten.

Hintergrund

Keom ist ein Kreditprotokoll, das von Compound V2 abgezweigt wurde. Benutzer zahlen ETH in den Markt ein und erhalten kETH. Wenn ein Benutzer einlöst, rechnet das Protokoll kETH-Aktien über den aktuellen Wechselkurs in ETH um. Es gibt zwei Einlöse-Einstiegspunkte im Protokoll: redeem() zum Einlösen nach Aktienbetrag und redeemUnderlying() zum Einlösen 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 zunächst redeemAmount zugewiesen und dann über den aktuellen Wechselkurs zur Berechnung von redeemTokens verwendet. Wenn redeemTokens den Saldo des Einlösenden übersteigt, wird die Funktion auf accountTokens[redeemer] gekappt. redeemAmount wird jedoch nach dieser Kappung nicht neu berechnet und bleibt gleich dem ursprünglichen redeemAmountIn. Dies erlaubt es dem Einlösenden, den vollen redeemAmount-Betrag an zugrunde liegenden Vermögenswerten abzuheben, während nur ein Bruchteil der entsprechenden Aktien verbrannt wird.

Wie im folgenden Code-Snippet gezeigt, führt redeemFresh() auch einen Gesundheitscheck über redeemAllowed() durch. Im Compound V2-Design prüft redeemAllowed() markets[cToken].accountMembership[redeemer] und ruft die Liquiditätsprüfung nur dann 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, würde die Liquiditätsprüfung fehlschlagen, wenn kETH weiterhin als Kollateral zählt. Dies bedeutet, dass der reine Buchhaltungsfehler ohne vorherige Umgehung des Gesundheitschecks nicht direkt ausnutzbar ist.

Angriffsanalyse

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

• Schritt 1: Aufrufen von mint() mit nur 0,001 ETH, um einen minimalen kETH-Saldo zu erhalten.

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

• Schritt 3: Aufrufen von redeemUnderlying(), um den gesamten ETH-Saldo des Marktes (ca. 38,6 ETH) abzuheben, und Ausnutzen der fehlerhaften Buchhaltung, um ETH aus dem Markt abzuziehen.

Schlussfolgerung

Dieses Ereignis 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 ca. 35.000 USD führte. Die Einlösungslogik muss alle abhängigen Werte nach jeder Kappung oder Anpassung neu berechnen, um die Konstante von Aktien 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 Incident

Kurze Zusammenfassung

Am 18. März 2026 wurde ShiMama, ein deflationäres Token-Protokoll auf der BNB Chain, für ca. 35.000 USD ausgenutzt. Die Hauptursache war ein Mangel an Zugangskontrolle für die Funktion executePairBurn(), die es jedem Benutzer ermöglichte, die Auszahlung und das Verbrennen von Paarreserven auszulösen, was eine Preismanipulation ermöglichte.

Hintergrund

Das ShiMama-Protokoll enthält einen deflationären Mechanismus, der dazu dient, Token aus dem AMM-Paar zu ziehen und zu verbrennen. Dieser Mechanismus wird sowohl im ShiMama-Protokoll als auch im ShiMama-Token implementiert. Die Funktion executePairBurn() im ShiMama-Protokoll berechnet einen Abzugsbetrag aus dem vom Aufrufer bereitgestellten Parameter referenceIn:

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

Anschließend ruft sie forcePullFromPair() des ShiMama-Tokens auf, gefolgt von pair.sync() und dem Verbrennen der abgezogenen Token.

Schwachstellenanalyse

Die Hauptursache ist ein Mangel an Zugangskontrolle für executePairBurn() im ShiMamaProtocol-Vertrag (0x5049...0b49a). Die Funktion kann ohne Einschränkungen extern aufgerufen werden, sodass jeder Benutzer privilegierte Reservebewegungen und Paarsynchronisationen auslösen kann. referenceIn wird ebenfalls vom Aufrufer gesteuert und nicht an einen realen Verkaufbetrag gebunden. In ShiMamaToken.forcePullFromPair() kann das Protokoll Salden direkt vom Pancake-Paar verschieben, ohne jegliche Einschränkung, was eine willkürliche Reserveentnahme plus sofortige Synchronisation und damit eine Spotpreismanipulation ermöglicht.

Angriffsanalyse

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

• Schritt 1: Leihen von WBNB von Moolah flashLoan.

• Schritt 2: Überweisung von 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: Aufrufen von executePairBurn(), um 1.311.349.143,96 ShiMama-Token aus dem Pancake-Paar zu ziehen und zu verbrennen, wodurch der ShiMama-Preis effektiv in die Höhe getrieben wurde.

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

• Schritt 5: Rückzahlung des Flash-Loans, wodurch 52,98 WBNB als Nettogewinn verbleiben.

Schlussfolgerung

Dieses Ereignis wurde durch einen Mangel an Zugangskontrolle für executePairBurn() verursacht, der einen nicht autorisierten Weg zur Änderung von Pool-Reserven offengelegt hat. Jede Reserve-verändernde Funktion ist wirtschaftlich sensibel und muss streng genehmigungspflichtig sein. Vom Aufrufer gesteuerte Eingaben müssen an protokollbasierte Werte gebunden werden, um eine Verstärkung der Reserveentnahme zu verhindern.

6. BlindBox Incident

Kurze Zusammenfassung

Am 19. März 2026 wurde BlindBox, ein GameFi-Wettprotokoll auf der BNB Chain, für ca. 99.000 USD 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 manipulierbare 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 Limits.

Hintergrund

Die BlindBox ist ein GameFi-Protokoll, das es Benutzern ermöglicht, Wetten zu platzieren, indem sie ATM-Token an die Dead-Adresse überweisen. Das Protokoll bestimmt das Ergebnis anhand 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 Dead-Adresse aus. Das Protokoll verwendet getTwapPrice(), um die Größe jeder Wette zu begrenzen.

Schwachstellenanalyse

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

1. Schwache Zufälligkeit: Wenn die Abrechnungszeit 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 der Übermittlung der Transaktion off-chain simuliert werden können, konnte der Angreifer settle() nur dann aufrufen, wenn das berechnete Ergebnis günstig war, und so einen deterministischen Gewinn erzielen.

2. Manipulierbares Preislimit: Das Protokoll verwendet getTwapPrice(), um die Wettgröße zu begrenzen. Diese Funktion implementiert jedoch keinen echten zeitgewichteten Durchschnittspreis; sie liest stattdessen den Spotpreis im ATM/USDT-Pool. Dies ermöglicht es Angreifern, das Limit zu umgehen, indem sie den Poolpreis vor der Platzierung ihrer Wette manipulieren.

Angriffsanalyse

Die folgenden Schritte veranschaulichen das Angriffsmuster. Schritte 2 und 3 bildeten eine Paarsequenz (z. B. betId=5,284), und der Angreifer wiederholte dieses Paar mehrmals, um den Gewinn zu akkumulieren.

• Schritt 1: Manipulation des ATM/USDT-Pools, wodurch der Spotpreis von ATM aufgebläht wurde, damit getTwapPrice() in der nächsten Phase eine größere Wettgröße zuließ.

• Schritt 2: Platzieren einer großen Wette durch Überweisung des aufgeblähten ATM-Betrags an die Dead-Adresse (z. B. 0x4be049...3af12c).

• Schritt 3: Warten, bis mehr als 256 Blöcke vergangen waren, damit blockhash Null zurückgab und der Fallback-Pfad aktiviert wurde. 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

Dieses Ereignis wurde durch vorhersagbare Zufälligkeit in Kombination mit einem manipulierbaren Spotpreis als TWAP-Eingabe verursacht, was zu Verlusten von ca. 99.000 USD führte. Um ähnliche Risiken zu reduzieren, sollte das Protokoll jeden Abrechnungspfad entfernen, der nach Ablauf des blockhash-Fensters vorhersagbar wird, und getTwapPrice() durch eine Preisquelle ersetzen, die gegen kurzfristige Reservemanipulationen resistent ist.

7. Resolv Incident

Kurze Zusammenfassung

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

Hintergrund

Resolv ist ein Stablecoin-Protokoll, bei dem die USR-Emission von der Ausgabe von kollateralgestützten Swap-Abschlüssen abhängt. Seine Swap-Vervollständigungs-Pipeline, completeSwap() -> mint() -> transfer(), beeinflusst direkt die zirkulierende Menge von USR 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 durch einen privilegierten Infrastrukturschlüssel (im Code als SERVER_ROLE bezeichnet) aufrufbar, nachdem die entsprechende Kollateralhinterlegung verifiziert wurde.

Schwachstellenanalyse

Das Ereignis war eine Kompromittierung eines privilegierten Schlüssels, der vertrauenswürdige Abrechnungslogik aufrief und den USR-Mint-Pfad erreichte, ohne einen entsprechenden Kollateraleingang. Nachdem der Angreifer die Kontrolle über die privilegierte Signaturberechtigung erlangt hatte, bot der completeSwap()-Pfad keine On-Chain-Mint-Vorbedingungsprüfung; die Kollateralüberprüfung hing vollständig von der Off-Chain-Autorisierung ab. Dies verwandelte eine Kompromittierung der Steuerebene direkt in einen Ausfall der Lieferintegrität.

Angriffsanalyse

• Schritt 1: Vor dem Exploit reichte der Angreifer eine Swap-Anfrage in Transaktion 0x590b5c...de732c89 ein, wodurch der notwendige Zustand für die anschließende bösartige Swap-Abschluss vorbereitet wurde.

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

Schlussfolgerung

Dieses Ereignis unterstreicht, dass die Sicherheit von Stablecoins von harten On-Chain-Prämissen für die Prägung abhängt, nicht nur von vertrauenswürdigen Betreiberrollen. Insbesondere reichten die Auswirkungen dieses Vorfalls weit über die 80 Millionen nicht autorisierter USR-Prägungen hinaus. Da Resolv-Vermögenswerte weit verbreitet als Kollateral in mehreren Kreditprotokollen verwendet wurden, löste der Depeg eine breitere Kontagion aus. Wie von Chaos Labs berichtet, verfügten On-Chain-Kuratoren, die automatisierte ertragsorientierte Allokationen nutzten, nicht über Echtzeit-Risikokontrollen und lenkten weiterhin frisches Kapital in bereits geschädigte Märkte. Was als lokalisierter Exploit begann, eskalierte schnell zu einem protokollübergreifenden Kontagionereignis, das Kreditprotokolle mit Millionen an faulen Schulden hinterließ.

Über BlockSec

BlockSec ist ein Anbieter von Blockchain-Sicherheit und Krypto-Compliance aus einer Hand. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei unterstützen, Code-Audits (einschließlich Smart Contracts, Blockchains 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 hinweg zu erfüllen.

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

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

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

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance