~$16 Mio. Verlust: DxSale, SquidRouterModule & mehr | BlockSec Weekly

In der vergangenen Woche (27.05.2026 - 30.05.2026) identifizierte BlockSec mehrere Angriffsereignisse in verschiedenen Blockchain-Ökosystemen. Die folgende Tabelle listet 5 bemerkenswerte Vorfälle mit geschätzten Gesamtverlusten von etwa 16 Mio. USD auf.

*Zusätzliche Anmerkungen:

• Beim Stake DAO-Vorfall kompromittierte der Angreifer den privaten Schlüssel des Deployers und nutzte ihn, um den LayerZero v2 OFT-Peer auf dem vsdCRV-Vertrag auf Arbitrum neu zu konfigurieren, was die Minting-Funktion für 5,4 Billionen vsdCRV freischaltete. Aufgrund der begrenzten DEX-Liquidität konnten nur ca. 91.000 USD abgezogen werden, bevor die Pools leer waren.
• Beim Alephium-Vorfall wurden nicht nur ca. 300.000 USD an Bridge-Verwahrmitteln (USDT, USDC, WETH, WBTC auf Ethereum sowie USDT, WBNB auf BNB Chain) abgezogen, sondern der Angreifer mintete auch 13,7 Mio. unbesicherte wALPH auf Ethereum. Die Bridge wurde abgeschaltet, wodurch der Angreifer daran gehindert wurde, diese Token über die Alephium-Bridge einzulösen oder zurückzubridgen.

Zwei Vorfälle wurden für eine eingehende Analyse ausgewählt:

• The SquidRouterModule Contract: Ähnlich wie beim CrossCurveFi-Exploit wurde derselbe Fehler der Integration wiederholt. Dies verdeutlicht, wie das Forken von Cross-Chain-Logik ohne tiefgreifendes Verständnis und strenge Sicherheitsüberprüfung vererbte Komplexität schnell in vererbtes Risiko verwandeln kann.
• DxSale: Sein langer Angriffszeitraum zeigt, dass ungenutzte Legacy-Verträge nicht zwangsläufig sicher sind und dass Protokolle ruhende Infrastrukturen kontinuierlich prüfen, privilegierte Zugriffe minimieren und jahrelanges Schweigen niemals als Beweis für Sicherheit missverstehen dürfen.

Wöchentliches Highlight: DxSale

Dieser Vorfall wurde als Wochen-Highlight ausgewählt, da die Kombination aus einem jahrelang ungepatchten Locker-Vertrag und einem kompromittierten Deployer-Schlüssel ein wiederkehrendes Muster illustriert: Protokolle, die bei der Bereitstellung erstellten Code als dauerhaft sicher behandeln, ohne kontinuierliche Prüfungen oder eine Rotation der Privilegien, tragen verborgene Risiken, die jederzeit ausgenutzt werden können.

Am 29. Mai 2026 wurde DxSale, eine Plattform für Token-Verkäufe und Liquiditäts-Sperren auf der BNB Chain, für ca. 7,3 Mio. USD exploitet [1]. Die Token-Auszahlungsfunktion enthielt drei fehlende Status-Updates, die es jedem Benutzer mit einer gültigen Sperrposition ermöglichten, wiederholt den gesamten gemeinsamen Pool abzuheben und zu leeren, ohne dass Eigentümerprivilegien erforderlich waren. Eine separate Kompromittierung des DxSale-Deployer-Schlüssels via EIP-7702-Delegation war keine Voraussetzung für den Exploit, verstärkte jedoch die Effizienz des Angreifers, indem sie Gebührenmanipulationen ermöglichte und andere Benutzer daran hinderte, neue Sperren zu erstellen.

Hintergrund

DxSale ist eine Plattform für Token-Verkäufe und Liquiditäts-Sperren auf der BNB Chain. Die DxLock-Komponente ermöglicht es Projektentwicklern, LP-Token in zeitlich gesperrten Tresoren zu verwahren, um Investoren Sicherheit zu bieten, dass die Liquidität nicht durch "Rug-Pulls" abgezogen werden kann.

Der Kernmechanismus der Sperrung funktioniert wie folgt: Ein Benutzer zahlt Token in den Locker-Vertrag ein und erstellt einen Sperrdatensatz, der durch eine Kombination aus der Adresse des Aufrufers und einer Token-ID indiziert wird. Jeder Datensatz speichert, ob die Sperre existiert, ob Token aktuell gesperrt sind, den gesperrten Betrag, den Zeitstempel für die Freigabe und die Token-Adresse. Wenn die Sperrfrist abläuft, ruft der Benutzer unlockToken(tokenId) auf, um seine Token abzuheben.

Da der Locker die Token vieler Benutzer gleichzeitig in einem gemeinsamen Saldo hält, müssen individuelle Zuweisungen durch separate Sperrdatensätze genau nachverfolgt werden. Die Sicherheit des gesamten Pools hängt davon ab, ob bei jeder Auszahlung der eigene Datensatz des Aufrufers korrekt validiert und nach der Übertragung aktualisiert wird.

Schwachstellenanalyse

Die unlockToken-Funktion im fehlerhaften Vertrag (0xeb3a...e449) enthielt drei sich gegenseitig verstärkende Defekte, bei denen jeweils eine Status-Aktualisierung oder Überprüfung fehlte:

function unlockToken(uint256 tokenId) public nonPayable {
    require(_increaseLockTime[msg.sender][tokenId].field0_0_0);  // locker existiert
    require(_increaseLockTime[msg.sender][tokenId].field0_1_1);  // Token sind gesperrt
    require(_increaseLockTime[msg.sender][tokenId].field2);       // Betrag > 0

    if (block.timestamp > _increaseLockTime[msg.sender][tokenId].field3) {
        _increaseLockTime[msg.sender][tokenId].field0_1_1 = 0;
    }

    v0, v1 = _increaseLockTime[msg.sender][tokenId].field5_0_19.balanceOf(this);
    require(v1 >= _increaseLockTime[msg.sender][tokenId].field2);
    v2, v3 = _increaseLockTime[msg.sender][tokenId].field5_0_19.transfer(
        msg.sender, _increaseLockTime[msg.sender][tokenId].field2
    );
}

1. Keine Durchsetzung der Sperrfrist. Die Sperrfrist wurde durch ein if-Statement statt durch ein require geschützt. Bei einem Aufruf vor dem Entsperr-Zeitstempel übersprang die Funktion einfach das Löschen des gesperrten Flags, anstatt den Vorgang abzubrechen (revert). Dies bedeutete, dass Token jederzeit abgehoben werden konnten, unabhängig von der Sperrfrist.

2. Gesperrter Betrag wurde nie auf Null gesetzt. Nach der Übertragung der Token an den Aufrufer setzte die Funktion field2 (den gesperrten Betrag) nicht auf Null. Bei jedem nachfolgenden Aufruf wurde derselbe ursprüngliche Wert gelesen und erneut abgehoben, was eine Endlosschleife an Auszahlungen erzeugte.

3. Überprüfung des Gesamtsaldos anstatt der individuellen Zuweisung. Der Aufruf von balanceOf(this) prüfte den gesamten Token-Bestand des Vertrags anstatt der individuellen Zuweisung des Aufrufers. Ein Aufrufer mit einer kleinen Sperrposition konnte den gesamten gemeinsamen Pool leeren, solange der Vertrag noch über genügend Gesamtbestände verfügte.

Zusammen genommen entzogen diese drei fehlenden Status-Aktualisierungen der Funktion jede Abbruchbedingung: Der Aufruf schlug nie vorzeitig fehl, der Auszahlungsbetrag verringerte sich nie, und die Saldo-Prüfung blockierte erst, wenn der Vertrag vollständig geleert war. Der Fehler war von jedem Benutzer ausnutzbar, der eine Sperrposition erstellt hatte; für die Kern-Leerung waren keine Eigentümerprivilegien erforderlich.

Angriffsanalyse

Das DxSale-Deployer-Konto (0x47bacf93), das via EIP-7702-Delegation agierte, zeigte seit dem 15.04.2026 anomale Aktivitäten, darunter Massenübertragungen von Eigentumsrechten, Gebührenänderungen und LP-Entsperroperationen über mehrere DxSale-Verträge hinweg. Am 26.05.2026 übertrug der Deployer das Eigentum des betroffenen Lockers (0xeb3a...e449) an den Angreifer-Vertrag (0xc457...fa69). Zwei Tage später führte der Angreifer einen fünfstufigen Leerungsvorgang durch.

Die folgende Analyse basiert auf einer repräsentativen Transaktion 0x437b26...c1b303.

• Schritt 1: Der Angreifer tauschte BNB gegen BNBC-Token auf PancakeSwap und stellte Liquidität bereit, um ein neues Cake-LP (BNBC/WBNB)-Paar zu erstellen; dabei erhielt er etwa 0,323 LP-Token.

• Schritt 2: Unter Nutzung der durch die vorherige Eigentumsübertragung erlangten Berechtigungen rief der Angreifer changeFees(1) auf, um die Gebühr für die Sperrerstellung auf 1 Wei festzusetzen, und rief dann createLocker auf, um die ca. 0,323 LP-Token in eine neue Sperrposition (tokenId=131) einzuzahlen. Unmittelbar danach rief der Angreifer changeFees(10^36) auf, um die Gebühr auf einen astronomischen Wert zu erhöhen und andere Benutzer daran zu hindern, neue Sperren zu erstellen.

• Schritt 3: Der Angreifer rief die Exploit-Funktion (0x11b432b4) auf, die wiederholte unlockToken-Aufrufe in einer einzigen Transaktion orchestrierte. Über mehrere Transaktionen hinweg leerte der Angreifer den Locker systematisch: 0x437b26...c1b303 leerte 161,4 LP-Token via TokenId=131, 0x82f541...a9fa73 und 0x5dd61f...4298aa leerten weitere Sperrpositionen, und 0xac8f5e...d36df9 leerte 260,3 LP-Token via TokenId=319 über 478 Aufrufe.

• Schritt 4: Der Angreifer rief removeLiquidity auf PancakeSwap auf, um die entleerten LP-Token wieder in ihre zugrunde liegenden Token (BNBC und WBNB) aufzubrechen.

• Schritt 5: Der Angreifer tauschte die zugrunde liegenden Token über PancakeSwap gegen WBNB und BUSD und übertrug den Erlös an externe Adressen. BSCScan verzeichnete für diesen Angreifer-Vertrag über 4 Tage (28.05.2026 bis 31.05.2026) hinweg 123.447 Transaktionen.

Fazit

Die Ursache dieses Vorfalls sind die drei fehlenden Status-Aktualisierungen in unlockToken. Für jede gibt es eine direkte Lösung: Sperrfristen mit require statt mit if durchsetzen, den gesperrten Betrag nach jeder Auszahlung auf Null setzen und die individuelle Zuweisung des Aufrufers anstatt des Gesamtsaldos des Vertrags prüfen. Diese Defekte allein reichten für die Ausnutzung aus; jeder Benutzer, der eine Sperrposition erstellt hatte, konnte den gesamten gemeinsamen Pool durch wiederholte Aufrufe leeren, ohne dass Eigentümerprivilegien erforderlich waren.

Die vorangegangene Kompromittierung des DxSale-Deployers via EIP-7702-Delegation war keine Voraussetzung für den Exploit, verstärkte jedoch die Effizienz des Angreifers. Durch die Übertragung des Eigentums und die Manipulation der Gebühren schuf der Angreifer Sperrpositionen mit nahezu Nullkosten und blockierte legitime Benutzer daran, konkurrierende Sperren zu erstellen. Auf operativer Ebene müssen Protokolle Legacy-Verträge kontinuierlich prüfen, insbesondere solche, die Benutzergelder halten, und die Verwaltung von Admin-Funktionen durch einen einzelnen Schlüssel vermeiden. Jahrelanger störungsfreier Betrieb validiert nicht die Sicherheit eines ungeprüften Codes.

Referenzen

• [1] DxSale-Ankündigung

Weitere Vorfälle diese Woche

The SquidRouterModule Contract

Am 27. Mai 2026 wurde ein unbekannter Vertrag namens SquidRouterModule auf Ethereum aufgrund unsachgemäßer Eingabevalidierung exploitet [1], was zu einem Verlust von ca. 3,2 Mio. USD führte. Die Ursache war eine missbräuchliche Nutzung der Axelar Bridge-Integration, ähnlich dem früheren CrossCurveFi-Angriffsmuster [2]. Der Vertrag validierte Cross-Chain-Nachrichten über das Axelar Gateway nicht korrekt, was es dem Angreifer ermöglichte, Payloads zu fälschen, die Token der Opfer autorisierten und in vordefinierte, schädliche Pools tauschten. Eine separate Angreifer-Adresse, die den gefälschten Token bereitgestellt und die Pools gesät hatte, zog später die Liquidität ab, um die echten Vermögenswerte zu extrahieren. Dieser Angriff betraf 86 Safe-Wallets. Trotz seines Namens wurde der SquidRouterModule nicht vom Squid-Protokoll-Team gebaut, bereitgestellt oder betrieben [3].

Hintergrund

Der Vertrag ist ein Modul für Cross-Chain-Austauschdienste, das für die Safe-Wallet konzipiert und auf dem Axelar Cross-Chain-Protokoll aufgebaut ist. Der Vertrag bietet die Funktion expressExecuteWithToken, die eine frühzeitige Ausführung von Transaktionen vor der Bestätigung der Cross-Chain-Nachricht unterstützt. Benutzer müssen vor Nutzung dieses Dienstes die APPROVE- und SWAP-Berechtigungen des Vertrags in ihrer Safe-Wallet vorab autorisieren. Wenn expressExecuteWithToken aufgerufen wird, dekodiert der Vertrag die Betriebsanweisungen im Payload und ruft execTransactionFromModule der Safe-Wallet auf, um die Token-Autorisierung und Austauschvorgänge auszuführen.

Schwachstellenanalyse

Die _executeWithToken-Funktion im verwundbaren Vertrag (0x1f1d...23ca) prüfte lediglich, ob srcAddress der Konstante squidRouter entsprach. Jedoch ist srcAddress ein vom Aufrufer bereitgestellter Parameter, während squidRouter eine unveränderliche Zeichenfolge ist, die jeder aus dem Vertrag lesen kann. Dies ermöglichte es dem Angreifer, die Prüfung trivial zu umgehen und die _processPayload-Funktion mit beliebigem Payload-Inhalt auszuführen.

Im Gegensatz dazu ruft die executeWithToken-Funktion des legitimen Squid Routers gateway.validateContractCallAndMint() auf und bricht mit NotApprovedByGateway() ab, falls das Axelar-Validator-Netzwerk die Transaktion nicht bestätigt hat.

Der verwundbare Vertrag setzte keinerlei dieser Gateway-Autorisierungen auf dem Pfad expressExecuteWithToken durch. In Kombination mit den APPROVE- und SWAP-Berechtigungen, die Safe-Wallet-Benutzer dem Modul vorab erteilt hatten, konnten gefälschte Payloads direkt auf die Gelder der Opfer zugreifen.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xd29d1c...3bb854.

Vor dem Angriff setzte eine separate Angreifer-Adresse einen gefälschten Token ein (0xe6Ff...3512) und erstellte mehrere Uniswap V3-Pools, die jeweils den gefälschten Token gegen verschiedene wertvolle Token paarten (z. B. USDC, ENA, USDT), wobei die Pools mit Liquidität aus dem gefälschten Token bestückt wurden.

• Schritt 1: Der Angreifer fälschte bösartige Calldata und rief die Funktion expressExecuteWithToken des verwundbaren Vertrags auf, wobei die bekannte squidRouter-Adresse als sourceAddress verwendet wurde, um die Validierungsprüfung zu umgehen. Durch die APPROVE- und SWAP-Berechtigungen, die das Opfer dem Modul vorab erteilt hatte, erzwang der gefälschte Payload Token-Genehmigungen von der Safe-Wallet des Opfers an den Uniswap-Pool.

• Schritt 2: Unter Verwendung dieser erzwungenen Genehmigungen tauschte der Payload die Token des Opfers durch den entsprechenden schädlichen Pool gegen den wertlosen gefälschten Token.

Der Angreifer wiederholte diese Methode über mehrere Transaktionen hinweg und zielte auf insgesamt 86 Safe-Wallets ab, die den verwundbaren Vertrag autorisiert hatten. Die separate Angreifer-Adresse, die den gefälschten Token bereitgestellt und die Pools gesät hatte, entfernte anschließend die Liquidität, um die echten Vermögenswerte zu extrahieren, was letztlich einen Gewinn von ca. 3,2 Mio. USD einbrachte.

Fazit

Dieser Vorfall wurde durch eine unsachgemäße Eingabevalidierung im Pfad der Cross-Chain-Nachrichtenverarbeitung verursacht. Die einzige Sicherheitsprüfung stützte sich auf einen durch den Aufrufer steuerbaren Parameter im Vergleich zu einer öffentlich lesbaren Konstante, was keinen wirklichen Schutz bot. In Kombination mit vorab autorisierten APPROVE- und SWAP-Berechtigungen von Safe-Wallet-Benutzern konnte der Angreifer Cross-Chain-Nachrichten fälschen und Benutzergelder stehlen.

Der Vorfall ist dem CrossCurveFi-Exploit [2] ähnlich: Beide beinhalten Axelar Bridge-Integrationen, die es versäumt haben, eingehende Cross-Chain-Nachrichten ordnungsgemäß zu validieren. Bei der Integration von Cross-Chain-Messaging-Infrastrukturen muss der Zielvertrag die Nachrichtenauthentizität unabhängig über den Autorisierungsmechanismus der Bridge validieren. Das Überspringen dieser Validierung und das Verlassen auf vom Angreifer steuerbare Eingaben macht die Integration zu einer offenen Angriffsfläche.

Referenzen

• [1] Phalcon Alert: SquidRouterModule Exploit
• [2] Phalcon Alert: CrossCurveFi Angriffsmuster
• [3] Squid Router Klarstellung

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei unterstützen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchain und Wallets), 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 zahlreiche Blockchain-Sicherheitsartikel auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, zahlreiche Hacks blockiert, um mehr als 20 Millionen US-Dollar zu retten, und Milliarden an Kryptowährungen abgesichert.

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

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

• 🔗 BlockSec Auditing Service : Eine Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance