~$104,6 Mio. verloren: EchoProtocol, Verus & mehr | BlockSec Weekly

Während der letzten Woche (18.05.2026 - 24.05.2026) identifizierte BlockSec mehrere Angriffsereignisse in verschiedenen Blockchain-Ökosystemen. Die folgende Tabelle listet 5 bemerkenswerte Vorfälle mit geschätzten Gesamtverlusten von etwa 104,6 Mio. USD auf.

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

• Verus: Der Angreifer nutzte einen Typ-Validierungsfehler in der Verus-Ethereum-Bridge aus, indem er einen manipulierten ergänzenden Export-Output einreichte, den die Bridge fälschlicherweise als gültigen primären Export klassifizierte. Die Semantik der Cross-Chain-Nachrichten ist Teil der Angriffsfläche.
• RetoSwap: Ein Authentifizierungsfehler auf Protokollebene im P2P-Handelsfluss ermöglichte es einem Angreifer, die Schiedsrichterrolle durch das Senden einer gefälschten ACK-Nachricht zu übernehmen. Der Angreifer kompromittierte die Erstellung des Multisig-Wallets vollständig off-chain.

Wochen-Highlight: Verus

Dieser Vorfall wird hervorgehoben, da der Angreifer gezielt einen speziellen Cross-Chain-Exporttyp missbrauchte, was auf ein tiefes Verständnis des internen Designs der Verus-Chain hindeutet. Der Exploit zeigt, dass Cross-Chain-Nachrichtenformate, einschließlich ergänzender Datenfelder und Kodierungsgrenzen, Teil der Angriffsfläche sind und die gleiche Sorgfalt wie die Überprüfung kryptografischer Beweise erfordern.

Am 18. Mai 2026 wurde die Verus-Ethereum-Bridge, eine Cross-Chain-Bridge, die die Verus L1-Chain mit Ethereum verbindet, um etwa 11,7 Mio. USD in ETH, tBTC und USDC gebracht [1][2]. Die Ursache war ein Typ-Validierungsfehler im Importpfad aufseiten von Ethereum: Der Bridge-Vertrag akzeptierte einen handgefertigten ergänzenden Export-Output und klassifizierte ihn fälschlicherweise als gültigen primären Export, was es dem Angreifer ermöglichte, passende Transferdaten bereitzustellen und Gelder abzuziehen. Bis zum 23. Mai wurden etwa 75 % der gestohlenen Gelder zurückgegeben.

Hintergrund

Die Verus-Ethereum-Bridge gibt Vermögenswerte auf Ethereum frei, nachdem bewiesen wurde, dass ein qualifizierter Export auf der Verus-Seite unter einem notariell beglaubigten Verus-Status existiert. Ethereum beobachtet Verus-Transaktionen nicht direkt; es stützt sich auf eingereichte Beweisdaten sowie eine Notariatsbeglaubigung, die verankert, welchem Verus-Status vertraut wird.

Drei Bridge-Objekte sind für diesen Vorfall relevant: ein primärer Export, das Objekt, das Ethereum importiert und für Auszahlungen verwendet; ein ergänzender Export-Output, zusätzliche Daten, die an den primären Export angehängt sind und nicht als eigenständiger aktiver Export für Auszahlungszwecke gedacht sind; und eine Notariatsbeglaubigung, die es Ethereum ermöglicht zu beweisen, dass ein spezifisches Objekt auf Verus-Seite in einem finalisierten Bridge-Status existierte.

Schwachstellenanalyse

Die fehlerhaften Ethereum-Bridge-Verträge sind unter 0xa045...6fc87f und 0x08f0...d0107d bereitgestellt.

Die Ursache war ein Typ-Validierungsfehler im Ethereum-Importpfad. Die Bridge bewies, dass ein echtes Verus-Objekt existierte, überprüfte jedoch nicht, ob das nachgewiesene Objekt ein gültiger primärer Export war, bevor sie es zur Freigabe von Geldern verwendete. Stattdessen akzeptierte sie einen manuell erstellten ergänzenden Output und parste ihn, als wäre er ein normaler aktiver Export.

Auf hoher Ebene sieht der anfällige Ablauf wie folgt aus:

proveImports(...)
    -> Beweis verifizieren
    -> verifizieren keccak256(serializedTransfers) == committed transfer hash

processTransactions(...)
    -> Auszahlungen auf Ethereum ausführen

Keine Prüfung in diesem Ablauf weist Objekte mit gesetztem FLAG_SUPPLEMENTAL ab. Der Fix prüft explizit auf dieses Flag und macht den Vorgang rückgängig, wenn das nachgewiesene Objekt ergänzend ist:

Angriffsanalyse

Die folgende Analyse basiert auf der Ethereum-Transaktion 0x6990f0...87eb321 und der Verus-Transaktion f899e698...b9f5a733.

• Schritt 1: Am 17. Mai finanzierte der Angreifer die Ethereum-Adresse 0x5aBb...9D5777 mit 1 ETH über Tornado Cash. Am 18. Mai erhielt der Angreifer 0,02 VRSC aus dem Verus-Faucet für die Adresse RW9vEW...B3g6zd.

• Schritt 2: Der Angreifer reichte vier für Ethereum bestimmte Export-Transaktionen auf Verus ein, die manipulierte ergänzende Export-Outputs enthielten. Diese ergänzenden Outputs waren so kodiert, dass sie fehlerfrei geparst werden konnten, und enthielten einen hashReserveTransfers-Commitment, der den betrügerischen Auszahlungen entsprach, die der Angreifer später ausführen wollte.

• Schritt 3: Nachdem eine Cross-Chain-Notariatsbeglaubigung auf Ethereum weit genug fortgeschritten war, reichte der Angreifer eine gefälschte Import-Transaktion auf Ethereum ein. Das bewiesene Verus-Objekt war der ergänzende Output aus der obigen Verus-Transaktion.

• Schritt 4: Die Ethereum-Bridge akzeptierte den Beweis, wies das bewiesene Objekt jedoch nicht als ergänzende Daten ab. Stattdessen parste sie den manipulierten Output, als wäre er ein gültiger aktiver Export. Da der Angreifer auch serializedTransfers lieferte, deren Hash mit dem zugesagten hashReserveTransfers-Wert übereinstimmte, fuhr die Bridge mit dem Import-Ablauf fort.

• Schritt 5: Da der ergänzende Output falsch als gültiger Export interpretiert wurde, bestanden die betrügerischen Transfers die Prüfungen auf Ethereum-Seite. Der Angreifer zog etwa 11,7 Mio. USD in ETH, tBTC und USDC ab.

• Schritt 6: Kurz nachdem der böswillige Import erfolgreich war, stießen Verus-Knoten auf eine Assertion über einen ungültigen Status, verursacht durch die Koexistenz des betrügerischen Export-Threads und eines echten Export-Threads, was das weitere Fortschreiten der Bridge stoppte und eine weitere Ausnutzung begrenzte.

Fazit

Der Vorfall wurde durch einen Typ-Validierungsfehler in der Verus-Ethereum-Bridge verursacht: Der Ethereum-Vertrag akzeptierte einen echten kryptografischen Beweis, aber das bewiesene Objekt war ein ergänzender Export-Output und kein gültiger primärer Export für Auszahlungen.

Cross-Chain-Nachrichtenformate sind Teil der Angriffsfläche. Ergänzende Daten, optionale Felder, kompakte Kodierungen und Parser-Offsets sollten mit der gleichen Sorgfalt behandelt werden wie Signatur- oder Merkle-Proof-Prüfungen. Wenn ein Objekt nicht dem für die ausgeführte Aktion erwarteten Typ entspricht, sollte die Bridge es sofort ablehnen, anstatt zu versuchen, es zu parsen.

Referenzen

• [1] BlockSec Phalcon Alert
• [2] Verus offizieller Post-Mortem-Bericht

Weitere Vorfälle diese Woche

RetoSwap

Am 20. Mai 2026 wurde RetoSwap, eine dezentrale P2P-Börse auf Monero, die vom Haveno-Protokoll geforkt wurde, um etwa 2,7 Mio. USD (7.000 XMR) gebracht [1]. Die Ursache war ein Authentifizierungsfehler auf Protokollebene: Der Client akzeptierte eine gefälschte, außer der Reihe gesendete ACK-Nachricht und überschrieb die gespeicherte Tor-Adresse des Schiedsrichters mit einer vom Angreifer kontrollierten, ohne den Absender anhand des bekannten öffentlichen Schlüssels des Schiedsrichters zu verifizieren. Dies ermöglichte es dem Angreifer, die Multisig-Wallet-Erstellung zu kapern und Gelder zu stehlen, sobald sie eingezahlt wurden.

Hintergrund

RetoSwap ist eine dezentrale P2P-Börse auf Monero, die vom Haveno-Protokoll geforkt wurde. Ihr Handelsprotokoll stützt sich auf ein 2-von-3-Schiedsrichter-Multisig-Modell, um Trades abzusichern und koordiniert Trades off-chain über Tor.

Ein normaler Handel läuft in drei Phasen ab: Erstens führen Käufer, Verkäufer und Schiedsrichter einen Off-Chain-Nachrichtenaustausch durch, um eine Multisig-Wallet zu erstellen; zweitens werden Gelder erst in der Multisig-Wallet gesperrt, nachdem diese vollständig erstellt wurde; drittens signieren Käufer und Verkäufer gemeinsam eine Auszahlungstransaktion zur Abwicklung, oder der Schiedsrichter greift ein, um Streitigkeiten zu lösen. Die gesamte Kommunikation läuft über Tor, und jeder Knoten ist ausschließlich durch seine .onion-Adresse identifiziert.

Schwachstellenanalyse

Am 20. Mai eröffnete das Haveno-Projekt einen Pull-Request mit dem Titel "core: refuse to update node address before multisig created" [2]. Zu diesem Zeitpunkt war RetoSwap bereits Gegenstand des Angriffs.

Der Patch enthüllte eine Schwachstelle in TradeProtocol.java:onAckMessageAux(...). Der Client identifizierte Peers unter Verwendung einer in der Nachricht gelieferten senderNodeAddress, ohne kryptografisch zu verifizieren, dass der Absender dem erwarteten öffentlichen Schlüssel des Schiedsrichters entsprach. Ein Angreifer konnte eine gefälschte ACK-Nachricht mit einer vom Angreifer kontrollierten .onion-Adresse senden, woraufhin der Client die gespeicherte Schiedsrichteradresse damit überschrieb.

)

Da dies während Phase 1 geschah (vor der Erstellung der Multisig-Wallet), ersetzte die Adresse des Angreifers die des echten Schiedsrichters. Der Angreifer besaß daher sowohl den Schlüssel des Händlers als auch den des Schiedsrichters der Multisig-Wallet, was den Diebstahl des gesamten Guthabens ermöglichte, sobald Gelder eingezahlt wurden.

Der Fix adressiert dies auf zwei Arten: Er verifiziert den Absender anhand des bekannten öffentlichen Schlüssels des Peers und lehnt Nachrichten von nicht verifizierten Peers ab; zudem werden Adressaktualisierungen hinter trade.isDepositRequested() geschaltet, was Überschreibungen verhindert, bevor die Multisig-Wallet erstellt wurde.

Angriffsanalyse

Für diesen Vorfall wurde keine On-Chain-Angriffstransaktion identifiziert. RetoSwap arbeitet vollständig über Tor mit Off-Chain-Nachrichtenabwicklung, sodass die kritischen Aktionen außerhalb des öffentlichen Ledgers stattfinden. Die folgende Rekonstruktion basiert auf dem öffentlich verfügbaren Patch und offiziellen Mitteilungen.

• Schritt 1: Der Angreifer schloss sich einem bestehenden Handel als Käufer oder Verkäufer an.

• Schritt 2: Der Angreifer sendete eine gefälschte, außer der Reihe gesendete ACK-Nachricht, die so aussah, als käme sie vom Schiedsrichter, und enthielt eine vom Angreifer kontrollierte .onion-Adresse als senderNodeAddress.

• Schritt 3: Der Client des Opfers akzeptierte die Nachricht und überschrieb die gespeicherte Adresse des Schiedsrichters, ohne den Absender anhand des bekannten öffentlichen Schlüssels des Schiedsrichters zu überprüfen.

• Schritt 4: Die gesamte nachfolgende Kommunikation, die für den Schiedsrichter bestimmt war, einschließlich der Erstellung der Multisig-Wallet, wurde an den Angreifer weitergeleitet, der so den dritten Multisig-Schlüssel erhielt.

• Schritt 5: Sobald Käufer und Verkäufer Gelder in die kompromittierte Multisig-Wallet einzahlten, stahl der Angreifer den gesamten Inhalt der Wallet. Der Gesamtgewinn belief sich auf etwa 7.000 XMR (~2,7 Mio. USD).

Fazit

Der Vorfall war kein kryptografischer Fehler, sondern ein Authentifizierungsfehler auf Protokollebene: Die Nachrichten wurden als wohlgeformt validiert, aber der Absender war vor dem Anwenden von Adressänderungen nicht kryptografisch an einen bekannten öffentlichen Schlüssel gebunden. Infolgedessen behandelte der Client eine nicht verifizierte senderNodeAddress aus einer gefälschten ACK-Nachricht als den neuen Kontaktpunkt des Schiedsrichters, bevor die Multisig-Wallet erstellt wurde, was es dem Angreifer ermöglichte, die Schiedsrichterrolle zu kapern.

Die wichtigsten Lehren sind: (1) Jede Nachricht, die die Identität eines Peers aktualisiert, muss kryptografisch anhand des bekannten öffentlichen Schlüssels des Peers verifiziert werden, bevor die Aktualisierung angewendet wird, und (2) identitätskritischer Status wie Gegenpartei-Adressen sollte unveränderlich sein, sobald die sicherheitssensible Phase (z. B. die Erstellung einer Multisig-Wallet) begonnen hat.

Referenzen

• [1] RetoSwap Post-Incident-Stellungnahme
• [2] Haveno Fix Pull Request

Ü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 zu erfüllen.

BlockSec hat zahlreiche Blockchain-Sicherheitspapiere 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