~15,9 Mio. $ Verlust: Trusted Volumes, Wasabi & mehr | BlockSec Weekly

Während der letzten zwei Wochen (27.04.2026 - 10.05.2026) hat BlockSec mehrere Angriffsereignisse in verschiedenen Blockchain-Ökosystemen identifiziert. Die folgende Tabelle listet 11 bemerkenswerte Vorfälle mit geschätzten Gesamtverlusten von etwa 15,9 Mio. $ auf.

Drei Vorfälle wurden aufgrund der Neuartigkeit des Angriffs, der finanziellen Auswirkungen und der Sicherheitsimplikationen für eine eingehende Analyse ausgewählt:

• Aftermath Finance: ein realer Exploit auf einer Perpetual-DEX, bei dem eine subtile semantische Nichtübereinstimmung (signed/unsigned) bei der Gebührenvalidierung zur vollständigen Entleerung der Protokollgelder führte.
• Trusted Volumes: signifikante finanzielle Auswirkungen (~5,87 Mio. $) und eine klare Demonstration einer Autorisierungs-Nichtübereinstimmung in der RFQ-Abwicklungslogik.
• Wasabi Protocol: eine Kompromittierung von der Infrastruktur bis zur Vertragskontrolle, eine Art von Angriff, der zunehmend häufiger vorkommt, aber in Audit-Umfängen unterrepräsentiert ist.

Wochen-Highlight: Aftermath Finance

Dieser Vorfall wird hervorgehoben, da die semantische Diskrepanz zwischen vorzeichenbehafteten (signed) und vorzeichenlosen (unsigned) Werten eine subtile Schwachstellenklasse darstellt, die über einzelne Protokolle hinausgeht. Jedes DeFi-Protokoll, das eine Bibliothek für vorzeichenbehaftete Festkommazahlen zur Validierung von vorzeichenlosen Gebühren oder Preiswerten verwendet, ist anfällig für dasselbe Angriffsmuster, was diesen Exploit für Entwickler und Auditoren gleichermaßen lehrreich macht.

Am 29. April 2026 wurde Aftermath Perpetuals, eine On-Chain-Börse für unbefristete Futures auf Sui, um etwa 1,14 Mio. USDC gebracht [1]. Die Ursache war eine semantische Nichtübereinstimmung bei der Validierung der Builder-Gebühren: die Vergleichsfunktion für Gebühren führte vorzeichenbehaftete Arithmetik auf vorzeichenlosen Werten durch, was es einem Angreifer ermöglichte, einen Gebührenwert zu übermitteln, der bei vorzeichenbehafteter Interpretation negativ erschien. Während der Abwicklung wurde die negative Gebühr in eine positive Sicherheitengutschrift umgewandelt, wodurch der Angreifer aufgeblähte Gelder aus dem Protokoll-Vault abheben konnte.

Hintergrund

Aftermath Perpetuals ist eine On-Chain-Börse für unbefristete Futures auf Sui [2]. Das Protokoll ermöglicht es externen Integratoren, Handelsgebühren zu verdienen, indem sie Front-End-Schnittstellen erstellen. Jeder Integrator legt einen Gebührensatz (taker_fee) fest, der den Händlern in Rechnung gestellt wird, die ihre Schnittstelle nutzen [3]. Als Schutzmaßnahme können Händler Integratoren genehmigen, indem sie eine Obergrenze für den Gebührensatz (maxTakerFee) konfigurieren, die begrenzt, wie viel Gebühr ein Integrator erheben darf.

Bei der Ausführung einer Market-Order vergleicht das Protokoll zuerst die taker_fee mit der maxTakerFee, um sicherzustellen, dass die Gebühr innerhalb der vom Händler genehmigten Grenze bleibt, zieht dann die berechnete Gebühr vom Collateral des Takers ab und schreibt sie den Aufzeichnungen des Integrators gut.

Die Arithmetik des Protokolls basiert auf einer Bibliothek für vorzeichenbehaftete Festkommazahlen (ifixed), die Werte als u256-Ganzzahlen darstellt, sie aber bei Vergleichs- und arithmetischen Operationen gemäß der Zweierkomplement-Semantik interpretiert.

Schwachstellenanalyse

Die fehlerhaften Verträge umfassen das Schnittstellenmodul (0x9e2080...25d136) und das Clearing-House-Modul (0x21d001...7c5068).

Die Schwachstelle liegt in der Funktion calculate_taker_fees(), die ifixed::less_than_eq() verwendet, um die taker_fee des Integrators mit der maxTakerFee des Händlers zu vergleichen:

assert!(
    ifixed::less_than_eq(
        v5.taker_fee,
        account::get_integrator_max_taker_fee(
            account::get_integrator_config(arg1, v5.integrator_address)
        )
    ),
    errors::invalid_integrator_taker_fee()
);

Sowohl taker_fee als auch maxTakerFee sind semantisch nicht-negative Gebührensätze. ifixed::less_than_eq() führt jedoch einen vorzeichenbehafteten Vergleich über u256 durch. Wenn maxTakerFee auf 0 gesetzt ist, wird ein Wert wie 2^256 - 10^16 unter vorzeichenbehafteter Semantik als -10^16 interpretiert. Da -10^16 <= 0 gilt, wird die Prüfung bestanden.

Der Exploit-Pfad wird weiter begünstigt, da create_integrator_info() öffentlich aufrufbar ist und keine Berechtigungs- oder Gebührenbegrenzungsvalidierung für die bereitgestellte taker_fee erzwingt:

public fun create_integrator_info(arg0: address, arg1: u256): Option<IntegratorInfo> {
    let v0 = IntegratorInfo {
        integrator_address : arg0,
        taker_fee          : arg1,
    };
    option::some<IntegratorInfo>(v0)
}

Die negative Gebühr wird nicht nur akzeptiert; sie wird während der Abwicklung in eine direkte positive Sicherheitengutschrift umgewandelt. Im Abwicklungspfad wird die Sicherheit als collateral += pnl - taker_fee - builder_fee aktualisiert. Wenn die builder_fee negativ ist, wird das Subtrahieren zur Addition:

position::add_to_collateral_usd(
    arg0,
    ifixed::sub(v6, ifixed::add(v7, v8)),
    arg2
);

Weder die Gebührenvalidierung noch die Abwicklungsarithmetik erzwingen, dass Gebührenwerte nicht-negativ sein müssen, sodass sich die zwei fehlenden Prüfungen summieren: Der vorzeichenbehaftete Vergleich lässt den negativen Wert zu, und die vorzeichenbehaftete Arithmetik wandelt ihn in eine Sicherheitengutschrift um.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 4pGQdf...wVD8.

• Schritt 1: Der Angreifer teilte 100e6 USDC in zwei neue Perpetual-Konten auf, 1227 und 1228. Dies schuf isolierte Kontexte, sodass der Angreifer sowohl als Maker (Konto 1227) als auch als Taker (Konto 1228) agieren konnte.

• Schritt 2: Der Angreifer zahlte 100e6 USDC als Sicherheit in Konto 1227 ein und eröffnete eine Marktposition, wodurch ein Kontrahent für die bevorstehende Taker-Order etabliert wurde.

• Schritt 3: Der Angreifer erstellte einen Integrator-Vault und fügte dann eine Konfiguration zu Konto 1228 mit maxTakerFee = 0 hinzu. Das Setzen des Caps auf Null war wesentlich: Es bewirkte, dass der vorzeichenbehaftete Vergleich taker_fee <= 0 jeden Wert akzeptierte, der unter Zweierkomplement negativ erscheint.

• Schritt 4: Der Angreifer startete eine Sitzung von Konto 1227 aus und platzierte eine Limit-Order mit order_size = 100e6, wodurch die Liquidität bereitgestellt wurde, gegen die Konto 1228 handeln würde.

• Schritt 5: Der Angreifer rief create_integrator_info() mit taker_fee = 2^256 - 100e6 auf, einem Wert, der unter vorzeichenbehafteter ifixed-Semantik -100e6 darstellt. Da die Funktion öffentlich ist und keine Validierung durchführt, war der Aufruf erfolgreich.

• Schritt 6: Der Angreifer führte eine Market-Order von Konto 1228 aus, indem er die bösartigen Integrator-Informationen verwendete. Der vorzeichenbehaftete Gebührenvergleich wurde bestanden (-100e6 <= 0), und während der Abwicklung wurde die negative Gebühr von der Sicherheit abgezogen, wodurch Konto 1228 effektiv 100e6 als freie Sicherheit gutgeschrieben wurde.

• Schritt 7: Der Angreifer hob die aufgeblähte Sicherheit von Konto 1228 ab und erhielt 79.610 USDC. Der Angreifer wiederholte dieses Muster über mehrere Transaktionen hinweg, um insgesamt etwa 1,14 Mio. $ anzuhäufen.

Fazit

Dieser Vorfall wurde durch eine semantische Nichtübereinstimmung (signed/unsigned) bei der Validierung der Builder-Gebühren bei Aftermath Perpetuals verursacht. Das Kernproblem ist, dass die Gebührenvergleichsfunktion (ifixed::less_than_eq) vorzeichenlose Gebührenwerte unter vorzeichenbehafteter Semantik interpretiert. In Kombination mit einer öffentlich aufrufbaren Funktion zum Festlegen von Gebühren, die keine Begrenzungsvalidierung durchführt, kann ein Angreifer einen Wert einschleusen, der den vorzeichenbehafteten Vergleich als "negativ" besteht und dann während der Abwicklung in eine positive Sicherheit gutgeschrieben wird.

Das breitere Muster ist bemerkenswert: Jedes Protokoll, das eine Bibliothek für vorzeichenbehaftete Festkommazahlen zur Validierung inhärent nicht-negativer Werte (Gebühren, Preise, Beträge) verwendet, ist anfällig für dieselbe Angriffsart. Abhilfemaßnahmen sollten umfassen: (1) sicherstellen, dass Gebührenwerte vor jedem Vergleich nicht-negativ sind (assert!(taker_fee >= 0)), (2) Einschränkung von create_integrator_info() auf autorisierte Aufrufer und (3) Verwendung von vorzeichenlosen Vergleichsfunktionen für Werte, die semantisch vorzeichenlos sind.

Referenzen

• [1] Aftermath Finance Post-Incident Statement
• [2] Aftermath Perpetuals Documentation
• [3] Builder Codes / Front-End Fee

Weitere Vorfälle in diesem Zeitraum

Trusted Volumes

Am 7. Mai 2026 wurde ein benutzerdefinierter RFQ-Proxy-Vertrag (Request-For-Quote) auf Ethereum angegriffen, wodurch etwa 5,87 Mio. $ vom Market Maker TrustedVolumes abgezogen wurden. Die Ursache war eine Autorisierungs-Nichtübereinstimmung in der Order-Erfüllungsfunktion des RFQ-Implementierungsvertrags: Die Suche nach der Unterzeichnerberechtigung und der Token-Transfervorgang bezogen sich auf unterschiedliche Felder der Order, sodass die Autorisierungsprüfung für eine Adresse bestanden wurde, während Gelder von einer anderen abgebucht wurden. Der Angreifer entzog etwa 1.291 WETH, 206 Tsd. USDT, 16,94 WBTC und 1,27 Mio. USDC.

Hintergrund

TrustedVolumes agiert als Market Maker im RFQ-Protokoll, das auf Ethereum bereitgestellt ist. Market Maker generieren kontinuierlich signierte Preisangebote außerhalb der Kette (off-chain); Taker (normalerweise Händler oder Aggregator-Router) übermitteln ein gewähltes Angebot auf der Kette (on-chain), und der Protokollvertrag verifiziert die Signatur und wickelt den Handel atomar ab, indem er Token zwischen Maker und Taker über transferFrom verschiebt. Das Protokoll folgt einem No-Vault-Design: Es verwahrt niemals Gelder. Jeder Maker gewährt dem Protokollvertrag vorab eine ERC-20-Freigabe für jeden Token, in dem er anbieten möchte, und das Protokoll zieht Token zum Zeitpunkt der Erfüllung direkt aus der Wallet des Makers.

Um es Makern zu ermöglichen, den Signiervorgang an eine Hot Wallet zu delegieren, führt der Protokollvertrag ein Unterzeichnerregister pro Maker. Ein Maker kann registerAllowedOrderSigner(signer, allowed) aufrufen, um einen Hot-Key auf die Whitelist zu setzen, und jede nachfolgende Order, die mit diesem Schlüssel signiert wird, wird so akzeptiert, als wäre sie vom Maker selbst signiert worden.

Schwachstellenanalyse

Der RFQ-Proxy-Vertrag ist unter 0xeEeEEe...051756 bereitgestellt, und der Implementierungsvertrag befindet sich unter 0x88eb28...2760d8.

Die Order-Erfüllungsfunktion 0x4112e1c2() im RFQ-Implementierungsvertrag stellt den Unterzeichner mittels ecrecover() wieder her und prüft das Mapping allowedOrderSigner, um zu entscheiden, ob die Signatur akzeptiert wird. Der Suchschlüssel für diese Prüfung ist varg4, die Taker-Seite-Adresse der Order. Der nachfolgende transferFrom, der die Gelder abbucht, verwendet jedoch varg5, das Maker-Feld der Order. Da varg4 und varg5 unabhängige Felder der Order-Struktur sind, beziehen sich die Autorisierungsprüfung und der Geldtransfervorgang auf unterschiedliche Akteure. Keine Prüfung stellt sicher, dass die autorisierte Unterzeichnerdomäne mit der Adresse übereinstimmt, von der tatsächlich Token abgebucht werden.

Die Funktion registerAllowedOrderSigner schreibt die Whitelist unter msg.sender als äußeren Schlüssel, während der Erfüllungspfad unter varg4 als äußeren Schlüssel liest. Solange der Aufrufer unter varg4 sich zuvor selbst via registerAllowedOrderSigner registriert hat, ist die Autorisierungsprüfung erfolgreich, unabhängig davon, welche Drittanbieter-Maker-Adresse unter varg5 erscheint.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xc5c61b...990513.

• Schritt 1: Der Angreifer stellte einen Angriffsvertrag bereit und rief registerAllowedOrderSigner darüber auf, wodurch der EOA des Angreifers in die Whitelist für erlaubte Unterzeichner eingetragen wurde. Dies stellte sicher, dass Order, die vom Angreifer signiert wurden, die Signier-Autorisierungsprüfung des Protokolls bestehen würden.

• Schritt 2: Der Angriffsvertrag zog 4 Wei an USDC vom EOA des Angreifers ab und genehmigte 4 Wei für das RFQ-Protokoll, womit der Angriffsvertrag mit der minimalen Gegenleistung ausgestattet war, die als Taker erforderlich ist.

• Schritt 3: Der Angreifer fälschte vier Order, die jeweils vom EOA des Angreifers signiert waren und TrustedVolumes als Maker nannten. Da die Unterzeichnerprüfung nach varg4 (dem Vertrag des Angreifers) suchte, während transferFrom varg5 (TrustedVolumes) belastete, entzog jede Order Gelder von TrustedVolumes. Die vier Order tauschten jeweils 1 Wei USDC gegen 1.291 WETH, 206.282 USDT, 16,939 WBTC bzw. 1.268.771 USDC, was einen Gesamtgewinn von etwa 5,87 Mio. $ ergab.

Fazit

Der Kernfehler ist eine Autorisierungs-Nichtübereinstimmung in der Order-Erfüllungsfunktion: Die für die Unterzeichner-Berechtigungsprüfung verwendete Adresse unterscheidet sich von der Adresse, die tatsächlich zahlt. Insbesondere schreibt registerAllowedOrderSigner die Whitelist unter msg.sender, der Erfüllungspfad liest unter dem Taker-Feld (varg4), und transferFrom bucht vom Maker-Feld (varg5) ab. Da sich diese drei Vorgänge auf unterschiedliche Akteure beziehen, kann jeder Angreifer, der seinen eigenen Unterzeichner registriert, Order fälschen, die einen Drittanbieter-Maker entleeren. Autorisierungsprüfungen, die die Vermögensbewegung regeln, müssen auf die Adresse eingestellt sein, die tatsächlich zahlen wird, und der Schreib- und Lesepfad müssen denselben Schlüssel verwenden.

Wasabi Protocol

Am 30. April 2026 erlitt das Wasabi Protocol, ein Protokoll für Optionen und unbefristete Futures, das über mehrere EVM-Ketten verteilt ist, einen Sicherheitsvorfall, der zu Verlusten von etwa 5,7 Mio. $ führte (4,8 Mio. $ an Nutzergeldern, 900 Tsd. $ aus der Wasabi-Treasury) [1][2]. Der Angriff ging von einer Infrastrukturkompromittierung aus: Ein offener Analyse-Endpunkt auf einem öffentlichen Server leckte Anmeldeinformationen, die letztendlich zum Diebstahl privater Schlüssel führten, die die EVM-Smart-Contracts des Protokolls kontrollierten. Unter Verwendung dieser Schlüssel führte der Angreifer unbefugte Abhebungen aus mehreren Wasabi-Vaults auf Ethereum, Base, Blast und Berachain durch.

Hintergrund

Das Wasabi Protocol betreibt Bereitstellungen über EVM-Ketten (Ethereum, Base, Blast, Berachain) und Solana. Dieser Vorfall war auf die EVM-Seite des Protokolls beschränkt; Solana-Bereitstellungen und der Prop AMM waren nicht betroffen.

Die EVM-Verträge von Wasabi (WasabiLongPool, WasabiShortPool, WasabiVault) werden über privilegierte Schlüssel verwaltet. Das Protokoll betreibt auch eine Off-Chain-Infrastruktur, einschließlich Analyse- und Überwachungsdiensten, die auf Spring Boot basieren.

Angriffsanalyse

Der Vorfall folgte einer Kompromittierungskette von der Infrastruktur zur Vertragskontrolle:

• Schritt 1: Der Angreifer entdeckte, dass Spring Boot Actuator auf einem öffentlich zugänglichen Wasabi-Server installiert war. Actuator-Heap-Dumps sind normalerweise passwortgeschützt, aber dieser Server verwendete eine andere Spring-Framework-Variante, die nicht mit dem standardmäßigen Passwortschutzmechanismus kompatibel war, wodurch der Heap-Dump-Endpunkt offengelegt wurde.

• Schritt 2: Der Angreifer rief den Heap-Dump ab, der Anmeldeinformationen für einen separaten internen Server enthielt.

• Schritt 3: Unter Verwendung der geleckten Anmeldeinformationen wechselte der Angreifer auf den internen Server und erlangte private Schlüssel, die die EVM-Smart-Contracts von Wasabi kontrollierten.

• Schritt 4: Mit privilegierten Schlüsseln in der Hand führte der Angreifer unbefugte Abhebungsvorgänge gegen die Verträge WasabiLongPool, WasabiShortPool und WasabiVault auf Ethereum, Base, Blast und Berachain durch und entleerte insgesamt etwa 5,7 Mio. $.

Fazit

Dieser Vorfall zeigt, dass Smart-Contract-Sicherheit nicht auf Code-Ebene endet. Der Exploit erforderte keine On-Chain-Schwachstelle; der Angreifer erlangte die Kontrolle rein durch Infrastruktur-Exponierung. Die wichtigsten Lektionen sind: (1) Debugging- und Analyse-Oberflächen (Heap-Dumps, Profiling-Endpunkte, Log-Exporteure) dürfen niemals auf öffentlicher Infrastruktur zugänglich sein, (2) Anmeldeinformationen für Produktionssysteme müssen streng von Analyse- und Überwachungsumgebungen getrennt sein, und (3) Smart-Contract-Verwaltungsschlüssel sollten mit Defense-in-Depth-Kontrollen geschützt werden, einschließlich Multisig-Verwahrung, hardwaregestütztem Signieren, Rollentrennung, Echtzeitüberwachung und Notfall-Pausenverfahren.

Referenzen

• [1] BlockSec Phalcon Alert
• [2] Wasabi Protocol Post-Incident Statement

Ü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, unerlaubte Gelder nachzuverfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg einzuhalten.

BlockSec hat zahlreiche Blockchain-Sicherheitspapiere 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 Milliarden an Kryptowährungen gesichert.

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

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

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance