Wormhole Bridge Hack: Technische Analyse des $326M Exploits

Am 2. Februar 2022 verlor die Wormhole Token-Bridge 120.000 wETH — ungefähr $326 Millionen zum Zeitpunkt des Angriffs — in einem der größten Smart-Contract-Exploits in der DeFi-Geschichte. Der Angriff erforderte keine gestohlenen Schlüssel, kein Social Engineering oder die Mehrheitskontrolle über das Guardian-Validator-Netzwerk. Es war nur eine Sache notwendig: eine veraltete Solana-Programmschnittstelle, die nicht überprüfte, von welchem Konto sie Daten las.

Das Verständnis dieses Exploits ist essenziell für jedes Team, das auf Solana entwickelt, jedes Protokoll, das auf Cross-Chain-Messaging vertraut, und jeden Auditor, der Solana-Programme prüft. Die Ursache lag in einer Verifikationslücke im Wormhole Solana-Bridge-Programm — nicht in einem Schlüsselkompromiss oder einem Ausfall des Guardian-Netzwerks. Die Guardian-Schlüssel wurden nie berührt. Der Bridge-eigene Code gewährte dem Angreifer eine Autorisierung, die er niemals hätte erteilen dürfen.

Was war die primäre technische Schwachstelle im Wormhole-Hack?

Die Schwachstelle lag in der Instruction verify_signatures im Solana-Bridge-Programm von Wormhole (bridge.so). Diese Funktion war verantwortlich dafür, sicherzustellen, dass ein SignatureSet-Konto — das Ed25519- oder Secp256k1-Signaturen der Guardian-Knoten enthält — echten Konsens repräsentiert, bevor eine Verifiable Action Approval (VAA) autorisiert wird.

Der Fehler: verify_signatures nutzte die veraltete Funktion solana_program::sysvar::instructions::load_instruction_at, um zu prüfen, ob eine Secp256k1-Pre-Verification Instruction zuvor in derselben Transaktion aufgerufen wurde. Die veraltete Variante validiert jedoch nicht, ob das Konto, das ihr übergeben wird, tatsächlich den Solana Instructions Sysvar (Sysvar1nstructions1111111111111111111111111) darstellt. Sie liest von jedem beliebigen Konto an dem genannten Index — einschließlich eines komplett vom Anrufer kontrollierten Kontos.

Ein Angreifer kann daher ein gefälschtes Konto übergeben, das das Layout des Instructions Sysvar nachahmt und mit angreiferkontrollierten Signaturdaten über eine angreifergewählte Nutzlast vorbefüllt ist. Die Funktion liest die falschen Daten, erkennt den Secp256k1-Aufruf als „vorhanden“ (in einem völlig anderen Kontext), kennzeichnet das VAA als Guardian-bewilligt und gibt Erfolg zurück.

Mit einem betrügerisch genehmigten VAA in der Hand rief der Angreifer complete_wrapped auf, das die Autorisierung für das Minten von Wrapped Assets auf Solana basierend auf der VAA-Bewilligung vertraut. Das Ergebnis: 120.000 wETH wurden ohne entsprechendes ETH-Locking auf Ethereum gemintet.

Ein Fix — der load_instruction_at durch load_instruction_at_checked ersetzt, das sicherstellt, dass das Konto tatsächlich der Instructions Sysvar ist — war vor dem Exploit bereits im Wormhole GitHub-Repository committed, aber noch nicht im Mainnet ausgerollt.

Wie unterscheidet sich der Wormhole-Hack von anderen Bridge-Angriffen wie Ronin?

Der Ronin Bridge Hack (März 2022, ~$625M) wird oft zusammen mit Wormhole genannt, wenn es um Bridge-Sicherheitsausfälle geht. Sie sind jedoch grundlegend verschiedene Ausfallmodi.

Wormhole war ein Smart Contract-Verifikationsfehler im Solana Bridge-Programm. Das Guardian-Netzwerk — ein 19-Knoten-Threshold-Signatursystem — wurde nie kompromittiert. Der Angreifer umging es vollständig, indem er ausnutzte, dass verify_signatures nie überprüfte, welches Konto tatsächlich gelesen wurde. Die Guardian-Schlüssel waren unversehrt, das Netzwerk funktionierte, aber das war irrelevant: der Code fragte nie den echten Guardian-Konsens ab.

Ronin war operativer Schlüssel-Diebstahl. Sky Mavis betrieb fünf der neun Validator-Knoten von Ronin. Im November 2021 delegierte Axie DAO vorübergehend die Signaturautorität an Sky Mavis zur Lastenverteilung. Diese Delegation wurde beim Ablauf nicht widerrufen. Ein Angreifer — später dem Lazarus Group zugeschrieben — kompromittierte interne Systeme von Sky Mavis und erlangte Zugriff auf vier Validator-Schlüssel. Unter Verwendung der noch aktiven Axie DAO-Delegation holten sie über einen gasfreien Sky Mavis RPC-Knoten die fünfte Signatur. Mit fünf von neun gültigen Signaturen reichten sie legitime Auszahlungsnachrichten beim Ronin-Bridge-Contract ein. Es wurde kein Smart-Contract-Bug ausgenutzt. Die Bridge fungierte genau wie entworfen bei Vorlage von fünf echten Validator-Signaturen — sie autorisierte die Auszahlungen.

Schritt-für-Schritt: Ausführung des Wormhole-Exploits

1. Konto-Spoofing. Der Angreifer kreierte ein Solana-Konto, das das für SignatureSet erwartete Layout in den Instruction-Daten des Wormhole Bridge-Programms nachahmte. Dieses Konto enthielt angreiferkontrollierte Signaturen — gültige Ed25519/Secp256k1-Signaturen, jedoch über eine vom Angreifer gewählte VAA-Nutzlast, die das Minten von 120.000 wETH an die Solana-Adresse des Angreifers autorisierte.

2. Bypass über veraltete sysvar-API. Der Angreifer sendete eine Transaktion mit Aufruf von verify_signatures im Wormhole Solana-Bridge-Programm. Das Programm rief load_instruction_at auf — die veraltete, nicht geprüfte Variante — um zu bestätigen, dass eine Secp256k1-Instruction in derselben Transaktion zuvor aufgerufen wurde. load_instruction_at liest ungeprüft vom Konto am genannten Index, ohne zu validieren, ob es sich um das echte Instructions Sysvar handelt.

3. Gefälschter Nachweis akzeptiert. verify_signatures prüfte die Signaturen im angreiferkontrollierten Konto, fand sie kryptographisch gültig (der Angreifer hatte sie selbst über seine Nutzlast signiert) und markierte das VAA als Guardian-approve. Das Guardian-Netzwerk wurde nie konsultiert.

4. Minting autorisiert. Der Angreifer rief complete_wrapped mit dem nun genehmigten VAA auf. Das Bridge-Programm, das dem VAA-Verifizierungsstatus vertraut, mintete 120.000 wETH auf Solana an die Adresse des Angreifers.

5. Cross-Chain-Extraction. Der Angreifer transferierte die geminteten wETH über das legitime Wormhole Cross-Chain-Verfahren zurück zu Ethereum — die wETH existierten in der Solana-Wallet des Angreifers, also bearbeitete die Bridge die Abhebung wie eine normale Überweisung. Die $326M an nicht gedecktem wETH landeten auf Ethereum, wo der Angreifer sie in ETH und Stablecoins umwandelte und auszog. Jump Crypto, Mutterfirma von Wormhole, ersetzte die 120.000 ETH aus eigenen Reserven, um die Nutzer der Bridge zu entschädigen.

Die wichtigsten technischen Lektionen für Solana-Programme und Cross-Chain-Bridges

1. Jedes AccountInfo, das an ein Solana-Programm übergeben wird, ist bis zum Beweis des Gegenteils angreiferkontrolliert.

Das ist die fundamentale Regel für Solana-Programmsicherheit. Ein Programm muss owner, key und, wo relevant, executable und is_signer jedes Accounts validieren. Die veraltete Funktion load_instruction_at akzeptierte jedes Konto auf dem genannten Index ohne Prüfung. Die moderne Alternative load_instruction_at_checked stellt sicher, dass es sich tatsächlich um das Instructions Sysvar handelt, bevor gelesen wird. Sokens Audit-Methodik kennzeichnet jede Verwendung von nicht-_checked Sysvar APIs als kritisch, unabhängig vom Kontext.

2. Privilegientrennung zwischen Signaturverifikation und Asset-Minting.

Die Minting-Authority einer Bridge muss hinter einem Verifikationsmodul stehen, das Beweise aus kanonischem, programmgeführtem Zustand ableitet — nicht aus vom Anrufer gelieferten Accounts. Akzeptiert verify_signatures ein angreiferkontrolliertes Konto als Wahrheit, kollabiert die Trennung zwischen „Wurde vom Netzwerk genehmigt?“ und „Dürfen wir minten?“ vollständig. Die Mint-Instruction sollte Autorisierungen aus vom Programm selbst verifizierten Daten ableiten.

3. VAA-Replay-Schutz muss on-chain erzwungen werden.

Selbst wenn das SignatureSet authentisch gewesen wäre, sollte complete_wrapped VAAs ablehnen, deren Hash bereits verbraucht wurde. Wormhole ergänzte Replay-Schutz in späteren Versionen, aber im exploitierten Release fehlte diese Funktion, sodass dieselbe betrügerische VAA wiederholt genutzt werden konnte. Jede Bridge-Operation sollte an eine atomar aktualisierte Mapping-Struktur (processed_vaas: mapping[bytes32, bool]) zur VAA-Verbrauchsprüfung gebunden sein.

4. Die Nutzung veralteter APIs ist ein kritischer Audit-Befund.

Die Wormhole-Schwachstelle war als Deprecation bekannt. Das Solana SDK hatte load_instruction_at als veraltet markiert und die _checked-Variante vor dem Exploit bereitgestellt. Der fehlende Umstieg auf die neue API ist keine bloße Codequalitätsfrage — es ist ein sicherheitskritisches Defizit, nach dem Angreifer gezielt in Changelogs und nicht ausgerollten Commits suchen. Solana Audits müssen solana_program::sysvar::instructions::* systematisch nach nicht-_checked-Varianten durchsuchen und das als kritisch einstufen. Das ist seit 2022 Standard bei Ottersec, Halborn und Soken.

5. Nicht ausgerollte Sicherheitspatches sind öffentliche Angriffslandkarten.

Der Fix mit load_instruction_at_checked war vor dem Exploit im öffentlichen Wormhole-Repository commited. Ein versierter Angreifer, der Sicherheits-relevante Commits in Protokoll-Repositories überwacht — speziell den Austausch veralteter APIs gegen geprüfte Versionen — kann die Schwachstelle allein aus dem Diff rekonstruieren. Deployment-Pipelines für sicherheitsrelevante Programme müssen die Zeitspanne zwischen „Merge in main“ und „Deployment im Mainnet“ als aktive Angriffsfläche sehen. Notfall-Rollouts sollten diese Lücke in Stunden, nicht Tagen schließen.

6. Threshold-Multisig kompensiert keinen Fehler bei Account-Validierung.

Wormholes Guardian-Netzwerk bestand aus 19 unabhängigen Knoten, die ein Threshold-Signaturschema implementieren. Es war robust. Für diesen Angriff aber völlig irrelevant. Der Exploit umging die gesamte Konsens-Ebene, indem manipuliert wurde, von welchem Konto verify_signatures liest. Threshold-Signaturen schützen vor Kompromittierung von Guardian-Schlüsseln; sie bieten keinen Schutz gegen Bugs, die die Guardians nicht abfragen. Defense-in-depth verlangt, dass jede Sicherheitsschicht tatsächlich genutzt wird — ein umgangener Kontrollmechanismus ist gar kein Kontrollmechanismus.

Bedeutung für Bridge-Audits und Solana-Programmsicherheit

Der Wormhole-Exploit zeigt, dass Sicherheit von Cross-Chain-Bridges ein mehrschichtiges Problem ist. Das Guardian-Netzwerk mag kryptographisch einwandfrei sein, die ökonomischen Anreize korrekt gesetzt und die Protokollarchitektur sauber — und dennoch kann ein einziger veralteter Funktionsaufruf im On-Chain-Programm all dies neutralisieren.

Für Teams auf Solana generalisiert sich die Lektion der Konto-Validierung: Behandle jeden Parameter, der an dein Programm übergeben wird, als feindlichen Input. Validere Besitzer, Schlüssel, Discriminator und Datenlänge, bevor du mit einem Konto arbeitest. Nutze Framework-Wrapper wie Account<T> von Anchor oder Äquivalente, um diese Prüfungen typbasiert durchzusetzen statt durch manuelle Assertions.

Für Bridge-Architekten lautet die Lehre: Privilegientrennung und kanonische Statusankerung. Die Minting-Authority muss auf programmgeführten, validierten Status zurückführbar sein — nicht auf beweisgelieferte Daten vom Aufrufer, die das Programm unüberprüft akzeptiert.

Soken prüft bei jedem Solana-Audit auf Verwendung veralteter sysvar-APIs, fehlende Besitzerprüfungen und Lücken im VAA-Replay-Schutz als kritische Prioritäten. Das Wormhole-Muster — Umgehung eines Multisig-Thresholds durch Manipulation des Accounts, den eine Verifikationsfunktion liest — ist nun eine definierte Angriffs-Klasse in unserer Solana-Audit-Methodik. Wenn dein Protokoll Cross-Chain-Messaging oder Wrapping von Assets nutzt, kontaktiere uns unter soken.dev/services-it.html für eine Sicherheitsüberprüfung vor Deployment.