Wöchentliche Zusammenfassung der Web3-Sicherheitsvorfälle | 16. – 22. März 2026

Während der vergangenen Woche (16.03.2026 – 22.03.2026) hat BlockSec sieben Angriffsereignisse erkannt und analysiert, die zu geschätzten Gesamtverlusten von ca. 82,7 Mio. USD führten. Die folgende Tabelle fasst diese Vorfälle zusammen; detaillierte Analysen für jeden Einzelfall finden sich in den nachfolgenden Unterabschnitten.

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

1. Venus-Vorfall

Kurze Zusammenfassung

Am 15. März 2026 erlitt der THE (Thena)-Markt des Venus-Protokolls auf der BNB Chain einen Spendengriff (Donation Attack) in Kombination mit Marktmanipulation, was zu faulen Krediten in Höhe von ca. 2,15 Mio. USD führte. Das Versorgungslimit des THE-Marktes galt nur für den Mint-Pfad, während direkte Token-Spenden in den Markt weiterhin den cash-Bestand erhöhten und die exchangeRate in die Höhe trieben. Der Angreifer nutzte diesen künstlich aufgeblähten Sicherheitenwert aus, um liquide Vermögenswerte zu leihen und mehr THE zu erwerben, während er gleichzeitig den Marktpreis des THE-Tokens nach oben trieb. Dies hinterließ das Protokoll nach der erzwungenen Liquidation der Position mit faulen Krediten.

Hintergrund

Venus ist ein Lending-Protokoll, das auf einem Compound V2-Fork basiert. Auf dem THE-Markt hinterlegen Benutzer THE-Token und erhalten dafür vTHE-Token. Die exchangeRate (Wechselkurs) bestimmt, wie viel der zugrunde liegenden Vermögenswerte des Marktes ein einzelner vTHE repräsentiert. Die Kernformel lautet:

exchangeRate = (cash + borrows - reserves) / totalSupply

Hierbei ist cash der Bestand an zugrunde liegenden Token des Marktes, borrows die gesamte ausstehende Verschuldung, reserves die protokolleigenen Reserven und totalSupply die gesamte vTHE-Versorgung. Der THE-Markt hat zudem ein Versorgungslimit, das dazu dient, das Risiko durch Sicherheiten zu begrenzen.

Schwachstellenanalyse

Dieser Vorfall betraf zwei zusammengesetzte Vektoren gegen den vTHE-Marktkontrakt (0x86e0...739f).

Spendengriff (Donation Attack)

Das Protokoll leitet cash direkt aus dem rohen Token-Bestand des Marktkontrakts ab, was es anfällig für Spendengriffe macht. Jeder direkte Transfer von THE in den vTHE-Marktkontrakt erhöht cash und damit die exchangeRate. Der Angreifer nutzte dies, um die exchangeRate um das ca. 3,81-fache aufzublähen und den Sicherheitenwert seiner bestehenden vTHE-Position zu verstärken.

Marktmanipulation

Der THE-Token verfügte über eine geringe On-Chain-Liquidität, wodurch sein Spot-Preis anfällig für Manipulationen durch relativ bescheidenen Kaufdruck war. Das Oracle des Protokolls ist darauf ausgelegt, Preise abzulehnen, die zu weit von einem Referenzwert abweichen, was während des Angriffs etwa 37 Minuten lang korrekt funktionierte. Anhaltender Kaufdruck trieb den Preis des THE-Tokens jedoch schließlich auf ca. 0,51 USD, etwa das Doppelte des Preises vor dem Angriff, was das Oracle schließlich akzeptierte.

Beide Vektoren verstärkten sich gegenseitig. Die aufgeblähte exchangeRate aus dem Spendengriff verstärkte den Sicherheitenwert jeder vTHE-Einheit, während der manipulierte THE-Token-Preis die Kreditaufnahmekapazitä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 des Versorgungslimits betrug.

Angriffsanalyse

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

• Schritt 1: Eine dem Angreifer zugeordnete Wallet erhielt 7.447 ETH über 77 mit TornadoCash verbundene Transaktionen über einen Zeitraum von rund neun Monaten. Diese ETH wurden bei Aave hinterlegt, und ca. 9,92 Mio. USD in Stablecoins wurden geliehen, um eine vTHE-Position von etwa 12,2 Mio. THE aufzubauen, was etwa 84 % des 14,5 Mio. THE-Versorgungslimits entspricht.

• Schritt 2: In der ersten Angriffstransaktion transferierten sechs Adressen etwa 36 Mio. THE direkt in den vTHE-Marktkontrakt. Der Angriffskontrakt lieh zudem 1,58 Mio. USDC, hinterlegte diese erneut, lieh dann etwa 4,6 Mio. THE und transferierte diese direkt in den vTHE-Kontrakt. Dies hob die exchangeRate um etwa das 3,81-fache an.

• Schritt 3: In den nachfolgenden Transaktionen lieh der Angreifer liquide Vermögenswerte, darunter CAKE, BNB, BTCB und USDC. Der Angreifer kaufte mit den geliehenen Vermögenswerten weiterhin THE und spendete mehr THE an vTHE, was einen Kreislauf schuf, der sowohl die Kreditaufnahmekraft 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 fast 4 USD erreichte. Das Protokoll-Oracle 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 3,67-mal so viel wie das Versorgungslimit, bei einem gesamten Kreditvolumen von ca. 14,9 Mio. USD.

• Schritt 6: Die Position ging dann in große Liquidationen über. Etwa 42 Mio. THE-Sicherheiten wurden über 8.048 Liquidations-Transaktionen von 254 Liquidatoren-Adressen liquidiert. Als der Verkaufsdruck anhielt, fiel der THE-Token auf etwa 0,22 USD. Die Liquidationserlöse konnten die gesamte Verschuldung nicht decken und hinterließen Venus mit ca. 2,15 Mio. USD an Netto-Schulden.

Fazit

Dieser Vorfall offenbarte keine neuartige Schwachstelle. Er demonstrierte, wie ein bekannter Angriffsvektor, methodisch ausgeführt, das gesamte Risikosystem eines Protokolls überfordern kann, wenn jede Ebene davon ausgeht, dass die anderen halten würden. Warnsignale waren monatelang auf der Chain sichtbar, doch die Lücke zwischen Erkennung und Intervention blieb unadressiert. Diese Lücke durch liquiditätsbewusste Risikoparameter, automatisierte Schutzschalter (Circuit Breaker) und Überwachung auf Positionsebene zu schließen, ist die zentrale Lehre dieses Vorfalls für andere Lending-Protokolle.

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

Quellen

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

2. dTRINITY-Vorfall

Kurze Zusammenfassung

Am 17. März 2026 wurde dTRINITY, ein Aave V3-Fork-Lending-Protokoll auf Ethereum, über seinen dLEND-Markt manipuliert, was zu einem Verlust von ca. 257.300 USD führte. Die Ursache war die Schwachstelle des leeren Marktes (Empty Market), die Aave V3-Forks inhärent ist. Wenn eine Reserve nahezu keine Liquidität aufweist, treibt die wiederholte Zinsakkumulation von Flash-Loans den liquidityIndex auf einen extremen Wert. Sobald die Reserve-Buchhaltung verzerrt war, nutzte der Angreifer den Präzisionsverlust in den Ein- und Auszahlungspfaden aus, um Sicherheiten zu überbewerten, dUSD zu leihen und die hinterlegten cbBTC für einen Nettogewinn zurückzuerlangen.

Hintergrund

dTRINITY umfasst das dUSD-Stablecoin-System und dLEND, einen von Aave V3 geforkten Kreditmarkt. Im zentralen L2Pool-Kontrakt (0xfda3...e19e84) hat jeder Vermögenswert seine eigene Reserve, und die Reservebuchhaltung basiert auf skalierten Salden und einem Reserve-Level liquidityIndex. Das aktuelle Guthaben eines Benutzers leitet sich aus dem skalierten Saldo multipliziert mit dem normalisierten Einkommen der Reserve ab.

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

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

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

Schwachstellenanalyse

Die zentrale Bedingung 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-Loan-Prämien nicht mehr auf eine nennenswerte Versorgungsbasis verteilt. Wiederholte Flash-Loans ließen daher den liquidityIndex extrem schnell ansteigen.

Nachdem der liquidityIndex aufgebläht war, trat die Umrechnung von zugrunde liegenden Werten auf skalierte Werte in einen extremen Rundungsbereich ein. In diesem Zustand konnte eine kleine Einzahlung einen zusätzlichen Anteil minten, während eine viel größere Auszahlung immer noch nur einen Anteil verbrennen konnte. Diese Asymmetrie erlaubte es dem Angreifer, aCbBTC-Sicherheiten zu überbewerten und echte dUSD aus einer anderen Reserve zu leihen, da Gesundheitsprüfungen auf Pool-Ebene durchgeführt werden und die korrumpierte cbBTC-Reserve direkt die kreditaufnehmende Kraft über Vermögenswerte hinweg beeinflusste.

Angriffsanalyse

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

Transaktion 1: liquidityIndex Manipulation

• Schritt 1: Leih cbBTC von Morpho Blue.

• Schritt 2: Hinterlege cbBTC bei dLEND-cbBTC, um 100 skalierte Anteile zu minten.

• Schritt 3: Hebe 99 Anteils-Einheiten ab, sodass nur 1 Anteil übrig bleibt, was die dLEND-cbBTC-Reserve in einen nahezu leeren Zustand skalierten Angebots komprimiert.

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

• Schritt 5: Führe 150 Pool.flashLoan()-Aufrufe aus, um Prämien in der Reservebuchhaltung anzuhäufen, wodurch der liquidityIndex auf 6.226.621.999.999.999.999.999.999.979.728.276 ansteigt.

• Schritt 6: Führe wiederholte Ein- und Auszahlungszyklen durch, um verbleibende Reserve-Cash-Bestände zu extrahieren.

• Schritt 7: Zahle das Flash-Loan zurück.

Transaktion 2: Gewinnrealisierung

• Schritt 1: Leih erneut cbBTC von Morpho Blue.

• Schritt 2: Hinterlege ~7,72 cbBTC in der bereits manipulierten Reserve, um eine überbewertete aCbBTC-Sicherheitsposition aufzubauen.

• Schritt 3: Nutze die überbewerteten Sicherheiten, um 257.328 dUSD aus dem dLEND-dUSD-Markt zu leihen.

• Schritt 4: Setze die cbBTC-Extraktion durch wiederholte Ein-/Auszahlungszyklen fort.

• Schritt 5: Zahle das Morpho-Flash-Loan zurück und transferiere die geliehenen dUSD an die EOA (Externally Owned Account) Adresse des Angreifers.

Fazit

Dieser Vorfall ist ein Beispiel für den "Empty Market Attack", der bei Aave V3-Forks gut dokumentiert ist. Dieses Muster ist bereits bei mehreren Protokollen aufgetreten, und die Gegenmaßnahmen sind etabliert. Die Durchsetzung einer Mindestversorgungsschwelle während der Reserve-Initialisierung verhindert, dass die Reserve in einen Zustand gerät, in dem das Indexwachstum unkontrollierbar wird. Protokolle, die Aave V3 forken, sollten daher das Bootstrapping der Reserven als kritischen Vorgang betrachten und sicherstellen, dass bei der Bereitstellung eine nennenswerte Liquidität gesperrt ist, anstatt sich auf organische Einzahlungsströme zur Stabilisierung des Index zu verlassen.

3. Fun.xyz-Vorfall

Kurze Zusammenfassung

Am 17. März 2026 wurde Fun.xyz, ein Checkout-Infrastruktur-Protokoll auf Polygon, um ca. 85.700 USD erleichtert. Die Ursache war, dass der Legacy-CheckoutPool eine kritische Funktion bridge() ohne Zugriffskontrolle und ohne Bindung der Bridge-Calldata an den beabsichtigten Empfänger offenlegte. Diese Schwachstelle ermöglichte es dem Angreifer, die Ausführung auf den vertrauenswürdigen Abwicklungspfad umzuleiten und Gelder an ein vom Angreifer kontrolliertes Smart-Account zu transferieren.

Hintergrund

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

Schwachstellenanalyse

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

• Die Legacy-Implementierung erzwang kein onlyOperator für bridge(), wodurch jeder externe Aufrufer die Funktion aufrufen konnte, nachdem ein Checkout über deposit() erstellt wurde.

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

Eine zusätzliche betriebliche Bedingung machte den Exploit praktikabel: Zum Zeitpunkt des Exploits besaß der Legacy-CheckoutPool im CheckoutPaymaster noch Betreiberprivilegien. Dies ermöglichte es dem manipulierten bridge()-Aufruf, CheckoutPaymaster.activateAndCall() zu erreichen, was dann den neueren CheckoutPool.execute()-Pfad aufrief und Gelder an eine unter Kontrolle des Angreifers stehende Adresse transferierte.

Angriffsanalyse

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

• Schritt 1: Erstelle das ERC-4337 Smart-Account 0xb648 und bestimme es sowohl als Absender als auch als Paymaster in der externen UserOperation.

• Schritt 2: Rufe deposit() sowohl im Legacy- als auch im neuen CheckoutPool auf und erstelle einen Checkout-Datensatz im neuen CheckoutPool mit einem Abwicklungsbetrag von 85.730 USDC.

• Schritt 3: Rufe bridge() im Legacy-CheckoutPool mit bösartigen bridgeParams auf: Setze bridgeParams.target auf CheckoutPaymaster und kodiere bridgeParams.callData als Aufruf an activateAndCall(), der die externe UserOperation als internes Payload trägt.

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

• Schritt 5: Gehe in EntryPoint.handleOps(): Da 0xb648 sowohl als Absender als auch als Paymaster fungiert, bleiben sowohl die Account-Validierung als auch die Paymaster-Validierung unter der Kontrolle des Angreifers, was es dem Angreifer ermöglichte, 85.730 USDC zu gewinnen.

Fazit

Dieser Vorfall wurde dadurch verursacht, dass dem Legacy-CheckoutPool sowohl eine Zugriffskontrolle als auch eine Bindung der Calldata an den Empfänger auf seinem bridge()-Pfad fehlte, was zu Verlusten von ca. 85.700 USD führte. Um ähnliche Vorfälle zu verhindern, sollten Protokolle eine strikte Zugriffskontrolle für sensible Routing- und Abwicklungsvorgänge durchsetzen, sicherstellen, dass extern bereitgestellte Payloads mit den vom Protokoll abgeleiteten Empfängern übereinstimmen, und veraltete Kontrakte aus vertrauenswürdigen Privilegienbeziehungen entfernen, sobald fehlerbereinigte Ersatzkontrakte bereitgestellt wurden.

4. Keom-Vorfall

Kurze Zusammenfassung

Am 18. März 2026 wurde Keom, ein Compound V2-Fork-Lending-Protokoll auf Polygon zkEVM, um etwa 35.000 USD manipuliert. Die Ursache war eine fehlerhafte Buchhaltungslogik in redeemFresh(), das von redeemUnderlying() aufgerufen wird. Die Funktion begrenzte die Anteilsreduzierung auf das tatsächliche Guthaben des Benutzers, berechnete jedoch den zugrunde liegenden Auszahlungsbetrag nicht entsprechend neu. Diese Diskrepanz erlaubte es dem Angreifer, weit mehr Vermögenswerte einzulösen, als seine Anteile zulassen sollten.

Hintergrund

Keom ist ein Lending-Protokoll, das von Compound V2 geforkt wurde. Benutzer stellen ETH auf dem Markt zur Verfügung und erhalten kETH. Wenn ein Benutzer Anteile einlöst, konvertiert das Protokoll kETH-Anteile zum aktuellen Wechselkurs zurück in ETH. Es gibt zwei Einstiegspunkte für das Einlösen im Protokoll: redeem() für das Einlösen von Anteilsbeträgen und redeemUnderlying() für das Einlösen des gewünschten zugrunde liegenden Betrags.

Schwachstellenanalyse

Der Fehler liegt in redeemFresh() des kETH-Marktes (0x4c6e...0403), das von redeemUnderlying() aufgerufen wird. Der benutzergesteuerte redeemAmountIn wird zunächst redeemAmount zugewiesen und dann verwendet, um redeemTokens über den aktuellen Wechselkurs zu berechnen. Wenn redeemTokens das Guthaben des Einlösers übersteigt, begrenzt die Funktion diesen Wert auf accountTokens[redeemer]. Jedoch wird redeemAmount nach dieser Begrenzung nicht neu berechnet und bleibt gleich redeemAmountIn. Dies ermöglicht dem Einlöser, den vollen redeemAmount an zugrunde liegenden Vermögenswerten abzuheben, während nur ein Bruchteil der entsprechenden Anteile verbrannt wird.

Wie im Code-Schnipsel unten 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 hoch eingestellt werden kann, würde die Liquiditätsprüfung fehlschlagen, wenn kETH weiterhin als Sicherheit zählt. Dies bedeutet, dass der Buchhaltungsfehler allein ohne vorherige Umgehung der Gesundheitsprüfung nicht direkt ausnutzbar ist.

Angriffsanalyse

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

• Schritt 1: Rufe mint() mit nur 0,001 ETH auf, um ein minimales kETH-Guthaben zu erhalten.

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

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

Fazit

Dieser Vorfall wurde durch eine Buchhaltungsschwachstelle verursacht, bei der es versäumt wurde, redeemAmount neu zu berechnen, nachdem redeemTokens auf den tatsächlichen Kontostand des Benutzers begrenzt wurden, was zu Verlusten von ca. 35.000 USD führte. Die Einlösungslogik muss alle abhängigen Werte nach jeder Begrenzung oder Anpassung neu berechnen, um die Invariante "Anteile zu zugrunde liegendem Wert" zu bewahren. Compound V2-Forks sollten diesen Pfad sorgfältig überprüfen, da ähnliche Fehler auch in anderen Derivaten bestehen könnten.

5. ShiMama-Vorfall

Kurze Zusammenfassung

Am 18. März 2026 wurde ShiMama, ein deflationäres Token-Protokoll auf der BNB Chain, um ca. 35.000 USD manipuliert. Die Ursache war ein Mangel an Zugriffskontrolle für die Funktion executePairBurn(), was es jedem Benutzer ermöglichte, die Auszahlung der Paarreserven und deren Verbrennung auszulösen, was Preismanipulationen ermöglichte.

Hintergrund

Das ShiMama-Protokoll beinhaltet einen On-Chain-Deflationsmechanismus, der darauf abzielt, Token aus dem AMM-Paar zu ziehen und zu verbrennen. Dieser Mechanismus ist im ShiMama-Protokoll und dem 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 einer Verbrennung der abgezogenen Token.

Schwachstellenanalyse

Die Ursache ist eine fehlende Zugriffskontrolle für executePairBurn() im Kontrakt ShiMamaProtocol (0x5049...0b49a). Die Funktion ist ohne Einschränkung extern aufrufbar, sodass jeder Benutzer privilegierten Reserven-Abzug und Paar-Sync auslösen kann. referenceIn wird ebenfalls vom Aufrufer kontrolliert und ist an keinen realen Verkaufsbetrag gebunden. In ShiMamaToken.forcePullFromPair() kann das Protokoll direkt Guthaben aus dem Pancake-Paar ohne Einschränkungen bewegen, was willkürliche Reserveentfernungen plus unmittelbare Synchronisierung und damit Spot-Preis-Manipulation ermöglicht.

Angriffsanalyse

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

• Schritt 1: Leih WBNB von Moolah FlashLoan.

• Schritt 2: Übertrage 30,78e18 ShiMama, die in einer früheren Transaktion bezogen wurden, in den Angriffskontrakt. Da direkte ShiMama-Käufe über das Pancake-Paar deaktiviert waren, beschaffte der Angreifer ShiMama durch Bereitstellung und Abhebung von Liquidität im ShiMama-Protokoll vor dem Angriff.

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

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

• Schritt 5: Zahle das Flash-Loan zurück, wobei 52,98 WBNB als Nettogewinn übrig blieben.

Fazit

Dieser Vorfall wurde durch einen Mangel an Zugriffskontrolle für executePairBurn() verursacht, was einen unautorisierten Pfad zur Veränderung von Pool-Reserven eröffnete. Jede Funktion, die Reserven mutieren kann, ist ökonomisch sensibel und muss streng berechtigt sein. Vom Aufrufer kontrollierte Eingaben müssen an vom Protokoll abgeleitete Werte gebunden sein, um eine Verstärkung der Reserveextraktion zu verhindern.

6. BlindBox-Vorfall

Kurze Zusammenfassung

Am 19. März 2026 wurde BlindBox, ein GameFi-Wettprotokoll auf der BNB Chain, um ca. 99.000 USD manipuliert. Die Ursache war schwache Zufälligkeit, die es dem Angreifer ermöglichte, den Ausgang vorherzusagen und eine Gewinnrate von 100 % zu erzielen. Zudem stützte sich getTwapPrice() auf manipulierbare Spot-Preise statt auf einen echten zeigewichteten Durchschnitt, was es dem Angreifer ermöglichte, den Pool-Preis vorab aufzublähen und Wetten zu platzieren, die über den vorgesehenen Limits des Protokolls lagen.

Hintergrund

BlindBox ist ein GameFi-Protokoll, bei dem Benutzer durch Übertragen von ATM-Token an die tote Adresse (Dead Address) Wetten platzieren können. Das Protokoll bestimmt das Ergebnis basierend auf der Parität eines späteren Blockhashs. Gewinnt die Wette, zahlt BlindBox das 1,95-fache des ursprünglichen ATM-Betrags aus dem Bankroll der toten Adresse aus. Das Protokoll verwendet getTwapPrice(), um die Höhe jeder Wette zu begrenzen.

Schwachstellenanalyse

Der BlindBox-Kontrakt (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 Zufallswerte zurück, die von block.prevrandao, betId und block.timestamp abgeleitet sind. Da diese Eingaben Off-Chain simuliert werden können, bevor die Transaktion eingereicht wird, konnte der Angreifer settle() nur dann aufrufen, wenn das berechnete Ergebnis günstig war, was einen deterministischen Gewinn ermöglichte.

2. Manipulierbares Preislimit: Das Protokoll verwendet getTwapPrice(), um die Wettgröße einzuschränken. Diese Funktion implementiert jedoch keine echten zeigewichteten Durchschnittspreise; stattdessen liest sie den Spot-Preis im ATM/USDT-Pool. Dies ermöglicht Angreifern, das Limit durch Manipulation des Pool-Preises vor Platzierung ihrer Wette zu umgehen.

Angriffsanalyse

Die folgenden Schritte veranschaulichen das Angriffsmuster. Schritt 2 und 3 bildeten eine paarweise Sequenz (z.B. betId=5.284), und der Angreifer wiederholte dieses Paar mehrfach, um Gewinn anzuhäufen.

• Schritt 1: Manipuliere den ATM/USDT-Pool und blähe den ATM-Spot-Preis so auf, dass getTwapPrice() eine größere Wettgröße im nächsten Schritt erlauben würde.

• Schritt 2: Platziere eine große Wette durch Übertragung des aufgeblähten ATM-Betrags an die tote Adresse (z. B. 0x4be049...3af12c).

• Schritt 3: Warte, bis mehr als 256 Blöcke vergangen sind, sodass blockhash Null zurückgab und der Fallback-Pfad aktiviert wurde. Der Angreifer simulierte dann die Ergebnisse Off-Chain und rief settle() nur zu einem Block auf, in dem das berechnete Ergebnis günstig war (z. B. 0x68eedc...718ce8).

Fazit

Dieser Vorfall wurde durch vorhersehbare Zufälligkeit in Kombination mit einem manipulierbaren Spot-Preis als TWAP-Eingabe verursacht, was zu Verlusten von ca. 99.000 USD führte. Um ähnliche Risiken zu reduzieren, sollte das Protokoll jeden Abwicklungspfad entfernen, der nach Ablauf des blockhash-Fensters vorhersehbar wird, und getTwapPrice() durch eine Preisquelle ersetzen, die gegenüber kurzfristigen Reservemanipulationen resistent ist.

7. Resolv-Vorfall

Kurze Zusammenfassung

Am 22. März 2026 erlebte Resolv, ein Stablecoin-Protokoll auf Ethereum, eine Kompromittierung des Infrastruktur-Schlüssels, die eine unautorisierte Ausführung der privilegierten Swap-Finalisierungslogik ermöglichte. Bei diesem Vorfall missbrauchte der Angreifer die privilegierte Funktion, um über 80 Mio. nicht besicherte USR zu minten. Die Auswirkungen gingen über das direkte Minting-Ereignis hinaus, da das resultierende USR-Depeg eine breitere Ansteckung über Lending-Protokolle hinweg auslöste, bei denen Resolv-Vermögenswerte als Sicherheiten verwendet wurden.

Hintergrund

Resolv ist ein Stablecoin-Protokoll, bei dem die Ausgabe von USR von der Abwicklung durch Sicherheiten abhängt. Sein Swap-Abschlusspipeline, completeSwap() -> mint(), beeinflusst direkt das zirkulierende Angebot von USR und hängt daher sowohl von der Integrität der Autorisierung als auch von der Integrität der Sicherheiten ab. Im Normalbetrieb ist completeSwap() im Resolv-Kontrakt (0xa27a...5861) nur durch einen privilegierten Infrastruktur-Schlüssel (im Code als SERVICE_ROLE bezeichnet) aufrufbar, nachdem die entsprechende Sicherheitenhinterlegung verifiziert wurde.

Schwachstellenanalyse

Der Vorfall beruhte auf einem kompromittierten privilegierten Schlüssel, der die vertrauenswürdige Abwicklungslogik aufrief und den USR-Mint-Pfad ohne äquivalenten Sicherheitenzufluss erreichte. Sobald der Angreifer die Kontrolle über die privilegierte Signierinstanz erlangte, bot der completeSwap()-Pfad keinerlei On-Chain-Mint-Vorbedingungs-Durchsetzung; die Sicherheitenverifizierung war vollständig von Off-Chain-Autorisierung abhängig. Dies wandelte eine Kompromittierung der Kontrollebene direkt in ein Versagen der Versorgungsintegrität um.

Angriffsanalyse

• Schritt 1: Vor dem Exploit reichte der Angreifer einen Swap-Antrag in der Transaktion 0x590b5c...de732c89 ein, um den notwendigen Zustand für den anschließenden bösartigen Swap-Abschluss vorzubereiten.

• Schritt 2: Mit dem kompromittierten privilegierten Schlüssel rief der Angreifer completeSwap() auf, um über 80.000.000 USR über drei Transaktionen zu minten: 0xfe37f2...dc33743, 0x41b6b9...db1f18f und 0x7f9143...53a931d.

Fazit

Dieser Vorfall unterstreicht, dass die Sicherheit von Stablecoins von harten On-Chain-Mint-Vorbedingungen abhängt, nicht nur von vertrauenswürdigen Betreiberrollen. Bemerkenswert ist, dass die Auswirkungen dieses Vorfalls weit über die 80 Mio. USD an unautorisiertem USR-Minting hinausgingen. Da Resolv-Vermögenswerte weit verbreitet als Sicherheiten über mehrere Lending-Protokolle hinweg genutzt wurden, löste das Depeg eine breitere Ansteckung aus. Wie von Chaos Labs berichtet, fehlten On-Chain-Kuratoren, die automatisierte ertragsorientierte Zuweisungen nutzten, Echtzeit-Risikokontrollen, und sie lenkten weiterhin frisches Kapital in bereits beeinträchtigte Märkte. Was als lokaler Exploit begann, eskalierte schnell zu einem protokollübergreifenden Ansteckungsereignis und hinterließ Lending-Protokolle mit Millionen an faulen Schulden.

Über BlockSec

BlockSec ist ein Full-Stack Blockchain-Sicherheits- und Krypto-Compliance-Anbieter. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchain und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, unerlaubte Gelder nachzuverfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg zu erfüllen.

BlockSec hat mehrere Blockchain-Sicherheitsbeiträge auf renommierten Konferenzen veröffentlicht, über mehrere Zero-Day-Angriffe auf DeFi-Anwendungen berichtet, zahlreiche Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Milliarden an Kryptowährungen abgesichert.

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

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

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance