Wöchentliche Web3-Sicherheitsvorfall-Übersicht | 2. – 8. Feb. 2026

Im Laufe der letzten Woche (2. bis 8. Februar 2026) hat BlockSec sechs Angriffsereignisse erkannt und analysiert, mit geschätzten Gesamtschäden von rund 3,8 Mio. USD. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall finden Sie in den folgenden Unterabschnitten.

1. CrossCurve-Zwischenfall

Kurze Zusammenfassung

Am 2. Februar 2026 wurde das CrossCurve-Protokoll ausgenutzt, was zu einem Verlust von rund 2,8 Millionen US-Dollar führte. Die Hauptursache war, dass der ReceiverAxelar-Vertrag eine erlaubnisfreie Funktion expressExecute() exponierte, die den Standardvalidierungsprozess des Axelar Gateways umging. Der Empfänger führte lediglich Überprüfungen der Peer-Adresse auf Basis extern bereitgestellter Daten durch. Folglich konstruierte der Angreifer einen bösartigen Cross-Chain-Aufruf, um den Burn- und Entsperrmechanismus auszulösen, was zur unbefugten Freigabe von 999.787.453e18 EYWA-Tokens an den Angreifer führte.

Hintergrund

CrossCurve ist ein Cross-Chain-Bridge-Protokoll, das von Eywa.Fi entwickelt wurde und auf dem Axelar Cross-Chain-Messaging-Framework aufbaut.

Im beabsichtigten Sicherheitsmodell von Axelar werden Cross-Chain-Nachrichten vom Axelar Gateway weitergeleitet und müssen auf der Zielkette über validateContractCall() explizit validiert werden. Nur Nachrichten, die vom Gateway kryptografisch genehmigt wurden, dürfen zur Ausführung gelangen.

Um die Latenz zu reduzieren, bietet Axelar auch einen Express-Ausführungsmechanismus, bei dem ein Empfängervertrag eine Nachricht optimistisch ausführen kann, bevor das Gateway die Validierung abschließt. Dieses Design erfordert eine strenge Zugriffskontrolle, um sicherzustellen, dass nur vertrauenswürdige Ausführer Express-Ausführungspfade aufrufen können; andernfalls können unvalidierte Cross-Chain-Nachrichten vorzeitig verarbeitet werden.

Schwachstellenanalyse

Die Hauptursache war, dass ReceiverAxelar eine erlaubnisfreie Funktion expressExecute() exponierte, die direkt zum privilegierten _execute()-Pfad ohne Autorisierung durch das Axelar Gateway gelangen konnte.

Im korrekten Sicherheitsmodell von Axelar müssen Cross-Chain-Nachrichten zuerst vom Gateway durch beweisgestützte Ausführung genehmigt und dann auf der Zielkette über validateContractCall() validiert werden, was (commandId, sourceChain, sourceAddress, contractAddress, payloadHash) an eine einzelne autorisierte Ausführung bindet.

Der expressExecute()-Pfad übersprang diese Validierung jedoch vollständig. Er stützte sich lediglich auf eine Peer-Überprüfung unter Verwendung von sourceChain und sourceAddress, die beide vom Angreifer kontrolliert wurden und daher keine wirkliche Sicherheit boten. Dies ermöglichte es dem Angreifer, eine gefälschte Nachricht zu liefern, den receiveData-Zweig zu erzwingen und eine beliebige Nutzlast auszuführen, die schließlich unlock() auf dem Eywa CLP Portal auslöste, was zur unbefugten Freigabe von Cross-Chain-Assets führte.

Angriffsanalyse

• Schritt 1: Der Angreifer rief expressExecute() direkt auf und fälschte sourceChain, sourceAddress und payload. Da expressExecute() die Gateway-Validierung umgeht und direkt zu _execute() übergeht, war die einzige verbleibende Sicherheitsmaßnahme eine Whitelist-Prüfung der Peer-Adresse: require(peers[sourceChain] == sourceAddress.toAddress()). Diese Prüfung war unzureichend, da sowohl sourceChain als auch sourceAddress extern bereitgestellt wurden. Durch Angabe der korrekten freigegebenen Peer-Adresse umging der Angreifer sie.

• Schritt 2: Die gefälschte payload wurde dann an den Receiver.receiveData()-Zweig weitergeleitet. Die Funktion resume() führte die Cross-Chain-Operation PortalV2.unlock() basierend auf der bösartigen Nutzlast aus, was zur unbefugten Entsperrung von Geldern zugunsten des Angreifers führte.

Schlussfolgerung

Dieser Vorfall wurde im Wesentlichen durch unzureichende Zugriffskontrolle auf einem beschleunigten Ausführungspfad innerhalb eines Cross-Chain-Empfängervertrags verursacht. Durch die Freigabe von expressExecute() als erlaubnisfreie Funktion und die ausschließliche Abhängigkeit von extern bereitgestellten Peer-Informationen ermöglichte CrossCurve Angreifern effektiv, die Sicherheitsgarantien des Axelar Gateways zu umgehen und beliebige Cross-Chain-Nutzlasten auszuführen.

Um ähnliche Risiken in Zukunft zu mindern, sollten Cross-Chain-Protokolle, die Express- oder optimistische Ausführungsmechanismen integrieren:

• Strikte Aufrufer-Authentifizierung für Schnellpfad-Ausführungsfunktionen erzwingen, um sicherzustellen, dass nur vertrauenswürdige Relayer oder Gateways diese aufrufen können.

• Vermeiden Sie die Abhängigkeit von vom Angreifer kontrollierten Metadaten (wie Quellkette oder Adresse) als alleinige Grundlage für die Autorisierung.

• Betrachten Sie die Express-Ausführung als eine privilegierte Operation und wenden Sie Defense-in-Depth-Prüfungen an, die denen für standardmäßige validierte Ausführungspfade entsprechen.

Die sorgfältige Einhaltung dieser Grundsätze ist entscheidend bei der Gestaltung von Cross-Chain-Systemen, bei denen eine einzelne Umgehung der Validierung zu systemischen Asset-Verlusten über mehrere Netzwerke hinweg führen kann.

2. GYD-Zwischenfall

Kurze Zusammenfassung

Am 3. Februar 2026 wurde das GYD-Protokoll ausgenutzt, was zu Verlusten von rund 700.000 USD führte. Die Hauptursache war, dass der CCIP-Empfänger des Protokolls vom Angreifer kontrollierte Nachrichtendaten als Ausführungskontext vertraute. Der Exploit wurde durch eine von Arbitrum gesendete CCIP-Nachricht ausgelöst, die auf der Messaging-Ebene korrekt authentifiziert wurde, deren dekodierte Nutzlast jedoch später verwendet wurde, um in _ccipReceive() willkürliche externe Aufrufe durchzuführen. Durch Setzen des dekodierten Empfängers auf den GYD-Token-Vertrag und Angabe von Calldata für approve(attacker, type(uint256).max) gewährte das Treuhandkonto unbeabsichtigt eine unbegrenzte Genehmigung über sein GYD-Guthaben. Der Angreifer zog anschließend die Gelder über transferFrom() ab.

Hintergrund

Der GydL1CCipEscrow-Vertrag ist ein Cross-Chain-Asset-Treuhandvertrag, der auf dem Chainlink CCIP-Standard aufbaut. Benutzer sperren GYD-Tokens in diesem Vertrag auf L1, der dann über CCIP eine Cross-Chain-Nachricht an die Zielkette sendet. Umgekehrt, wenn eine Cross-Chain-Nachricht im Treuhandkonto eingeht, validiert CCIP deren Authentizität und löst _ccipReceive() aus. Diese Funktion analysiert die eingehenden Calldata, um tx.recipient und data zu extrahieren, führt GYD-Übertragungs- oder Entsperrlogik basierend auf den analysierten Parametern (Betrag und Empfänger) aus und führt, wenn data nicht leer ist, einen willkürlichen externen Aufruf über recipient.functionCall(data) durch.

Schwachstellenanalyse

Die Kernschwachstelle ist, dass GydL1CCipEscrow die aus Cross-Chain-Nachrichten dekodierte tx.recipient-Adresse nicht validiert. Ein Angreifer kann tx.recipient auf die GYD-Token-Vertragsadresse setzen und data als approve(attacker, type(uint256).max) gestalten. Da der Treuhandvertrag über eine große Menge gesperrter GYD-Tokens verfügt, führt dieser uneingeschränkte externe Aufruf dazu, dass das Treuhandkonto die volle Genehmigung seiner GYD-Tokens an den Angreifer erteilt, der dann alle Gelder über transferFrom() abziehen kann.

Angriffsanalyse

• Schritt 1: Der Angreifer initiierte eine bösartige CCIP-Nachricht auf Arbitrum, die tx.recipient als GYD-Token-Vertragsadresse auf Ethereum und tx.data als die kodierte Calldata für approve(attacker, type(uint256).max) angab.

• Schritt 2: Als die Nachricht auf Ethereum verarbeitet wurde, führte die _ccipReceive()-Funktion des GydL1CCipEscrow-Vertrags die Genehmigung auf dem GYD-Token-Vertrag aus, ohne tx.recipient zu validieren. Der Angreifer rief dann transferFrom() auf dem GYD-Token auf, um alle treuhänderisch verwalteten Gelder abzuziehen.

Schlussfolgerung

Die Hauptursache dieses Vorfalls war, dass der GydL1CCipEscrow-Vertrag die dekodierte Nutzlast bei der Verarbeitung von Cross-Chain-Nachrichten nicht validierte, was es einem Angreifer ermöglichte, einen bösartigen Cross-Chain-Aufruf zu konstruieren. Für Cross-Chain-Bridge-Nachrichten sollten Entwickler:

• Direkte Aufrufe an Token-Verträge vom Treuhandkonto verbieten: Stellen Sie sicher, dass die Nutzlasten von Cross-Chain-Nachrichten keine Aufrufe an den treuhänderisch verwalteten Token-Vertrag auslösen können.

• Eine Whitelist für Ausführungsziele implementieren: Beschränken Sie tx.recipient (oder tx.target) auf eine klar definierte Liste vertrauenswürdiger Adressen.

3. SOFI-Token-Zwischenfall

Kurze Zusammenfassung

Am 5. Februar 2026 wurde der SOFI-Token auf der BNB-Kette ausgenutzt, was zu Verlusten von rund 29.600 USD führte.

Die Hauptursache war ein fehlerhafter Burn-Mechanismus, der innerhalb der überschriebenen _transfer()-Funktion des Tokens implementiert war. Durch den Missbrauch der verzögerten Burn-Logik, die Tokens direkt aus dem PancakeSwap-Liquiditätspool entfernte und einen anschließenden sync() auslöste, konnte der Angreifer den SOFI-Preis künstlich aufblähen. Durch wiederholte Überweisungen und Swaps zog der Angreifer überschüssige USDT-Liquidität aus dem Pool ab und beglich den Flash-Loan mit Gewinn.

Hintergrund

SOFI ist ein benutzerdefinierter ERC-20-Token, der auf der BNB-Kette bereitgestellt wird. Im Gegensatz zu einer Standard-ERC-20-Implementierung überschreibt der SOFI-Token die interne _transfer()-Funktion, um zusätzliche Logik für das Verbrennen von Token während Verkaufsoperationen einzubetten.

Der Token wird in einem PancakeSwap-ähnlichen Constant-Product-AMM-Pool (SOFI–USDT) gehandelt. In solchen Pools wird der Token-Preis aus dem Verhältnis der Token-Reserven abgeleitet. Jede unerwartete Änderung der Pool-Salden, insbesondere solche, die nicht durch Swaps verursacht wurden, kann den Preis direkt manipulieren.

Bei diesem Design interagiert der Token-Vertrag selbst während der Überweisungen mit dem Liquiditätspool, wodurch die Reservenbuchhaltung des Pools von der Logik auf Token-Seite abhängt und nicht ausschließlich von AMM-Mechanismen.

Schwachstellenanalyse

Die Schwachstelle liegt im Burn-Mechanismus von SOFI in Verbindung mit der Pool-Interaktion innerhalb von _transfer().

Wenn SOFI-Token an die Adresse des Liquiditätspools übertragen werden, interpretiert der Vertrag die Übertragung als Verkauf und erhöht eine interne Akkumulatorvariable waitBurnTokenAmount. Der angesammelte Betrag wird jedoch nicht sofort verbrannt. Stattdessen wird er aus dem Pool-Saldo bei einer anschließenden Übertragung an den Pool verbrannt, woraufhin die sync()-Funktion des Pools aufgerufen wird.

Dieses Design führt zu zwei kritischen Problemen:

1. Direkte Manipulation des Pool-Guthabens Das Verbrennen von Token direkt aus dem Pool reduziert die SOFI-Reserve ohne entsprechenden USDT-Abfluss, verstößt gegen die AMM-Invarianten und erhöht künstlich den SOFI-Preis.

2. Verzögerte und vom Angreifer kontrollierbare Ausführung Da der Burn erst bei einer zukünftigen Übertragung erfolgt, kann ein Angreifer präzise steuern, wann der Burn und sync() stattfinden, was ihm ermöglicht, sich so zu positionieren, dass er von der Preisverzerrung profitiert.

Infolgedessen spiegelt der Pool-Preis nicht mehr die echten Angebots-Nachfrage-Dynamiken wider, was eine extrahierbare Arbitrage ermöglicht.

Angriffsanalyse

• Schritt 1: Leihen Sie USDT über einen Flash-Loan.

• Schritt 2: Swap USDT gegen SOFI im SOFI–USDT-Pool.

• Schritt 3: Übertragen Sie SOFI in den Pool und rufen Sie skim() auf, um waitBurnTokenAmount mit minimalem Verlust zu erhöhen.

• Schritt 4: Übertragen Sie erneut SOFI an den Pool, um Burn + sync() auszulösen, den SOFI-Preis zu erhöhen, und tauschen Sie dann SOFI gegen USDT.

• Schritt 5: Wiederholen Sie Schritt 4. Der neu angesammelte waitBurnTokenAmount wird erst bei der nächsten Übertragung verbrannt, daher sind mehrere Iterationen erforderlich.

• Schritt 6: Ziehen Sie USDT aus dem Pool ab, begleichen Sie dann den Flash-Loan.

Schlussfolgerung

Dieser Vorfall wurde letztendlich durch einen unsicheren Token-seitigen Burn-Mechanismus verursacht, der AMM-Pool-Guthaben direkt manipulierte. Durch die Einbettung verzögerter Burn-Logik in _transfer() und die Ausführung von Burns aus dem Liquiditätspool selbst brach der SOFI-Token die fundamentalen Annahmen von Constant-Product-AMMs und ermöglichte eine deterministische Preismanipulation.

Für ERC-20-Token, die _transfer() überschreiben, sollten Entwickler besonders darauf achten, Folgendes zu vermeiden:

• Token direkt aus Liquiditätspools verbrennen

• Verzögerte oder zustandsbasierte Mechanismen einführen, die Pool-Reserven beeinflussen

• Token-Logik zu eng mit AMM-Interna koppeln

Im Allgemeinen sollte Tokenomics-bezogene Logik niemals willkürliche Änderungen an Pool-Guthaben zulassen, da selbst kleine Abweichungen wiederholt ausgenutzt werden können, um Liquidität abzuziehen.

4. Unbekanntes Staking-Protokoll-Zwischenfall (5. Feb. 2026)

Kurze Zusammenfassung

Am 5. Februar 2026 wurde das Unbekannte Staking-Protokoll auf Ethereum ausgenutzt, was zu Verlusten von rund 71.600 USD führte.

Die Hauptursache war die Abhängigkeit des Protokolls von nicht verifizierten, vom Benutzer bereitgestellten Eingabedaten bei Auszahlungen. Insbesondere leitete das Protokoll vom Angreifer kontrollierte routerCalldata und LP-Beträge an den Pendle Router weiter, ohne diese zu validieren. Durch die Gestaltung von Calldata, die die gesamte LP-Position des Protokolls entfernte und sich selbst als Empfänger festlegte, konnte der Angreifer alle vom Tresor gehaltenen Vermögenswerte abziehen.

Hintergrund

Das Unbekannte Staking-Protokoll ist ein einfacher Yield-Tresor, der auf Pendle Finance aufbaut. Benutzer hinterlegen Vermögenswerte im Tresor, der diese dann über den Pendle Router leitet, um ertragsbringende Positionen zu prägen. Intern werden Einlagen in SY umgewandelt, in PT und YT aufgeteilt und zu Pendle LP-Token kombiniert.

Das Protokoll verwahrt alle LP-Token und führt interne Buchführungen über den hinterlegten Basisbetrag jedes Benutzers. Wenn Benutzer abheben, löst der Tresor LP-Token über den Pendle Router ein und gibt die entsprechenden Vermögenswerte an den Benutzer zurück.

Schwachstellenanalyse

Die Hauptursache sind unvalidierte Eingabedaten. Die Funktion withdrawWithCalldataMultiToken() nimmt vier Parameter entgegen: das zugrundeliegende Token, den zugrundeliegenden Betrag, den LP-Betrag und routerCalldata. Sie prüft nur, ob das vom Benutzer aufgezeichnete zugrundeliegende Guthaben ausreicht, validiert aber nicht den LP-Betrag oder den Inhalt von routerCalldata. Beim Entfernen von Liquidität über den Pendle Router verlässt sich der Vertrag vollständig auf Parameter, die in routerCalldata eingebettet sind. Folglich konnte ein Angreifer den gesamten LP-Bestand des Protokolls übergeben und sich selbst als Empfänger festlegen, wodurch alle vom Protokoll gehaltenen Vermögenswerte abgezogen wurden.

Angriffsanalyse

• Schritt 1: Nehmen Sie einen USDC-Flash-Loan auf.

• Schritt 2: Hinterlegen Sie einen kleinen Betrag USDC im Protokoll, das Gelder über den Pendle Router leitet, um Liquidität hinzuzufügen und LP zu prägen.

• Schritt 3: Rufen Sie withdrawWithCalldataMultiToken() mit einer konstruierten routerCalldata auf, die den receiver auf den Angreifer und den lpAmount auf den gesamten LP-Bestand des Protokolls setzt.

• Schritt 4: Das Protokoll entfernt Liquidität über den Pendle Router unter Verwendung der vom Angreifer kontrollierten Parameter und sendet alle Vermögenswerte an den Angreifer.

• Schritt 5: Tauschen Sie die erhaltenen Vermögenswerte zurück in USDC, begleichen Sie den Flash-Loan und behalten Sie den Rest als Gewinn.

Schlussfolgerung

Dieser Vorfall wurde letztendlich durch blinden Glauben an vom Angreifer kontrollierte externe Eingaben in einem kritischen Auszahlungspfad verursacht. Durch die Weiterleitung beliebiger LP-Beträge und Calldata an einen externen Router ohne Validierung ermöglichte das Protokoll den Benutzern, Auszahlungen durchzuführen, die weit über ihren berechtigten Anteil hinausgingen, was zum vollständigen Abzug der Pendle-Position des Tresors führte.

Für Produktions-Tresore und Yield-Strategien, insbesondere solche, die komplexe externe Router integrieren, sollten Entwickler:

• Alle vom Benutzer bereitgestellten Eingaben, einschließlich Calldata, als unzuverlässig behandeln und sie rigoros validieren.

• Sensible Parameter (wie LP-Beträge und Empfänger) intern ableiten, anstatt sie von Benutzern entgegenzunehmen.

• Defense-in-Depth anwenden, indem die Konsistenz zwischen interner Buchhaltung und externen Ausführungsergebnissen sichergestellt wird.

Die Nichteinhaltung dieser Grundsätze kann dazu führen, dass ein einziger Auszahlungsaufruf alle vom Protokoll gehaltenen Vermögenswerte gefährdet.

5. LZMultiCall-Protokoll-Zwischenfall

Kurze Zusammenfassung

Am 7. Februar 2026 führte der LZMultiCall-Zwischenfall zu Verlusten von rund 142.000 USD auf Ethereum.

Der Zwischenfall wurde nicht durch eine Schwachstelle im LZMultiCall-Vertrag selbst verursacht, sondern durch Fehlgebrauch seitens der Benutzer. LZMultiCall ist ein zustandsloser Batch-Ausführungsvertrag, der nicht für die Verwahrung von Vermögenswerten oder das Halten von ERC-20-Genehmigungen ausgelegt ist. Einige Benutzer erteilten dem Vertrag jedoch versehentlich Token-Genehmigungen. Ein Angreifer nutzte diese verbleibenden Genehmigungen anschließend aus, indem er execute() mit konstruierter Calldata aufrief, um transferFrom() aufzurufen und so Token von den betroffenen Benutzern abzuziehen.

Hintergrund

LZMultiCall ist ein generelles Dienstprogramm für die Batch-Ausführung. Sein beabsichtigter Zweck ist es, Benutzern zu ermöglichen, mehrere Aufrufe zu einer einzigen Transaktion zu bündeln und vom Benutzer bereitgestellte Calldata an Zielverträge weiterzuleiten.

Entscheidend ist, dass LZMultiCall so konzipiert ist, dass es zustandslos und nicht verwahrend ist. Es ist nicht dazu bestimmt, Vermögenswerte zu halten, noch sollten Benutzer ihm jemals ERC-20-Genehmigungen erteilen. Jegliche an LZMultiCall erteilten Token-Genehmigungen verstoßen gegen seine expliziten Nutzungsannahmen und setzen Benutzer Risiken aus, da der Vertrag im Namen des Aufrufers beliebige Aufrufe weiterleiten kann.

Schwachstellenanalyse

Obwohl LZMultiCall wie vorgesehen funktionierte, wurde seine erlaubnisfreie execute()-Funktion ausnutzbar, sobald Benutzer ihm versehentlich ERC-20-Genehmigungen erteilten. Da der Vertrag beliebige Calldata an ein beliebiges Ziel weiterleitet, konnte ein Angreifer execute() mit Calldata aufrufen, die transferFrom(victim, attacker, amount) auf Token-Verträgen kodiert und so alle ausstehenden Genehmigungen effektiv abzog.

Angriffsanalyse

• Der Angreifer rief execute() mit konstruierter Calldata auf, die auf den Token-Vertrag zielte, und verwendete transferFrom(), um Token von Benutzern zu übertragen, die versehentlich Genehmigungen an LZMultiCall erteilt hatten.

Schlussfolgerung

Dieser Vorfall wurde letztendlich durch die Verletzung der expliziten Nutzungsannahmen eines zustandslosen Batch-Ausführungsvertrags verursacht. LZMultiCall war niemals dazu gedacht, Gelder zu verwahren oder ERC-20-Genehmigungen zu halten. Sobald Benutzer versehentlich Genehmigungen erteilten, ermöglichte das erlaubnisfreie Ausführungsmodell des Vertrags jedem Aufrufer, diese Genehmigungen durch beliebige weitergeleitete Aufrufe abzuziehen.

Für Benutzer und Integratoren, die mit Batch-Ausführungs- oder Multicall-ähnlichen Verträgen interagieren:

• Erteilen Sie niemals ERC-20-Genehmigungen an Verträge, die nicht explizit für die Verwahrung von Vermögenswerten ausgelegt sind.

• Behandeln Sie generische Call-Forwarding-Verträge als unzuverlässige Ausführungsoberflächen.

• Bevorzugen Sie nach Möglichkeit Transaktionsgenehmigungen oder genehmigungsfreie Designs (z. B. permit).

Selbst in Abwesenheit einer Protokollschwachstelle kann ein Missverständnis des Vertrauensmodells eines Vertrags zu erheblichen und irreversiblen Verlusten führen.

6. Unbekanntes Protokoll-Zwischenfall (8. Feb. 2026)

Kurze Zusammenfassung

Am 8. Februar 2026 wurde das Unbekannte Protokoll auf Ethereum ausgenutzt, was zu Verlusten von rund 63.000 USD führte.

Die Hauptursache war eine nicht verifizierte, vom Angreifer kontrollierte Eingabe in einem Gnosis Safe-Modul-Ausführungspfad. Ein als SafeModule registrierter Dienstprogrammvertrag (0xF5E4) exponierte einen Flashloan-Callback, der beliebige vom Benutzer bereitgestellte Daten dekodierte und GnosisSafe.execTransactionFromModule() direkt aufrief. Da Modul-originierte Aufrufe naturgemäß die Signaturprüfung umgehen, konnte der Angreifer beliebige Safe-autorisierte Transaktionen ausführen, die Aave V3-Schulden des Safe beglichen und alle Sicherheiten an vom Angreifer kontrollierte Adressen abzogen.

Hintergrund

Die Protokollarchitektur konzentriert sich auf einen Gnosis Safe, der eine gehebelte Position auf Aave V3 verwaltet. Gnosis Safe unterstützt ein modulares Ausführungsmodell, bei dem bestimmte SafeModules Transaktionen im Namen des Safe ausführen dürfen, ohne dass dafür Besitzerunterschriften erforderlich sind. Dieses Design ist für die Unterstützung von Automatisierung, Integrationen und fortgeschrittenen Strategien vorgesehen.

In diesem Setup wurde der Vertrag 0xF5E4 als SafeModule des Gnosis Safe konfiguriert. Der Vertrag scheint ein Helfer-Dienstprogramm zu sein, das zur Unterstützung der Flashloan-basierten Positionsverwaltung konzipiert ist. Er implementiert einen Flashloan-Callback, receiveFlashLoan(), der von externen Liquiditätsanbietern während der Flashloan-Ausführung aufgerufen wird.

Da Modulaufrufe die Signaturprüfung umgehen, ist die Korrektheit und Sicherheit der Modullogik entscheidend: Jede Schwachstelle gewährt effektiv uneingeschränkte Kontrolle über den Safe.

Schwachstellenanalyse

Das SafeModule 0xF5E4 exponiert einen Flashloan-Callback receiveFlashLoan(), der extern bereitgestellte userData dekodiert und sie direkt verwendet, um GnosisSafe.execTransactionFromModule() aufzurufen. Da 0xF5E4 als SafeModule registriert ist, umgehen Aufrufe von ihm die Signaturprüfung. receiveFlashLoan() authentifiziert jedoch nicht den Aufrufer oder validiert die dekodierten Parameter (z. B. Zieladresse, Wert, Calldata oder Operationstyp). Folglich kann ein Angreifer eine konstruierte userData bereitstellen, um das Modul beliebige Transaktionen über den Safe ausführen zu lassen, was es ihm ermöglicht, die Aave V3-Schulden des Safe zu begleichen, alle Sicherheiten abzuziehen und die Position zur Gewinnerzielung zu leeren.

Angriffsanalyse

• Schritt 1: Der Angreifer nahm einen Flashloan über Uniswap V4 auf und übertrug die Gelder an den GnosisSafe.

• Schritt 2: Der Angreifer rief Balancers flashLoan() mit konstruierter userData auf, lieh keine tatsächlichen Vermögenswerte und setzte den recipient auf 0xF5E4.

• Schritt 3: In 0xF5E4.receiveFlashLoan() dekodierte der Vertrag die vom Angreifer bereitgestellte userData. Da 0xF5E4 als Safe-Modul registriert ist, umging es die Signaturprüfungen und rief execTransactionFromModule() auf, um beliebige Aufrufe gemäß den in userData eingebetteten Parametern auszuführen.

• Schritt 4: Mit dieser Fähigkeit beglich der Angreifer die Schulden des GnosisSafe auf Aave V3 und zog die gesamte Sicherheit ab, wodurch er Gewinn realisierte.

Schlussfolgerung

Dieser Vorfall wurde letztendlich durch unsicheren Einsatz von modulbasierter Ausführung in Kombination mit unvalidierten externen Eingaben verursacht. Durch die Weiterleitung beliebiger, vom Angreifer bereitgestellter userData an execTransactionFromModule() exponierte das SafeModule 0xF5E4 effektiv uneingeschränkte Kontrolle über den Gnosis Safe. Da Safe-Module naturgemäß die Signaturprüfung umgehen, ermöglichte dieser Fehler eine vollständige Kompromittierung der Aave V3-Position des Safe.

Für Systeme, die auf Gnosis Safe-Module oder ähnliche privilegierte Ausführungsframeworks angewiesen sind, sollten Entwickler:

• Alle externen Eingaben, einschließlich Flashloan userData, als unzuverlässig behandeln und rigoros validieren.

• Modulausführung auf eine klar definierte Reihe von Aktionen, Zielen und Selektoren beschränken.

• Generische "Utility"-Module vermeiden, die beliebige Calldata an privilegierte Ausführungsfunktionen weiterleiten.

Die Nichteinhaltung dieser Schutzmaßnahmen kann dazu führen, dass ein einzelner Hilfsvertrag zu einer vollständigen administrativen Backdoor wird.

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Code-Auditierung (einschließlich Smart Contracts, Blockchain und Wallets), Echtzeit-Angriffsabfangen, Vorfallanalyse, Rückverfolgung von illegalen Geldern und Erfüllung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.

BlockSec hat zahlreiche Blockchain-Sicherheitsarbeiten auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Kryptowährungen im Wert von Milliarden gesichert.

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

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

• 🔗 BlockSec Auditierungsdienst : Anfrage senden

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance