#2 Bybit-Vorfall: Web2-Datenleck ermöglicht größten Krypto-Hack aller Zeiten

Am 21. Februar 2025 verlor Bybit rund 1,5 Milliarden US-Dollar, nachdem ein Angreifer die Maschine eines Safe{Wallet}-Entwicklers per Social Engineering kompromittierte. Der Angreifer injizierte bösartigen JavaScript-Code in den AWS S3-Bucket von Safe{Wallet}, der gezielt Bybits Transaktionen ins Visier nahm. Der injizierte Code veränderte den Transaktionsinhalt während des Signaturprozesses: Die Safe{Wallet}-Benutzeroberfläche zeigte eine legitime Transaktion an, während die tatsächlich an die Ledger-Geräte der Unterzeichner gesendete Nutzlast den Safe-Vertrag von Bybit auf eine bösartige Implementierung aktualisierte, wodurch der Angreifer die volle Kontrolle erlangte. Nach der Unterzeichnung und Ausführung hob der Angreifer alle Vermögenswerte aus dem Vertrag ab. Eine detaillierte technische Aufschlüsselung ist in unserem früheren Bericht verfügbar [1].

Hintergrund

Safe{Wallet} (auch bekannt als GnosisSafe) ist eine Multisig-Wallet-Infrastruktur, die ein n-von-m-Modell verwendet: Zur Ausführung einer Transaktion sind mindestens n Signaturen von insgesamt m Unterzeichnern erforderlich.

Jede Safe-Wallet wird als Proxy-Vertrag bereitgestellt. Zwei Speichervariablen sind für diesen Vorfall von zentraler Bedeutung:

masterCopy (Slot 0): Die Adresse des Implementierungsvertrags. Dieser Vertrag enthält die gesamte Ausführungslogik, einschließlich Signaturprüfung und Upgrade-Mechanismen. Der Proxy leitet alle Aufrufe per delegatecall an masterCopy weiter.
threshold (Slot 4): Die Mindestanzahl der erforderlichen Signaturen (n). Für Bybits Safe lag diese bei 3.

Da der Proxy delegatecall verwendet, wird jede Funktion, die auf masterCopy aufgerufen wird, im Speicher-Kontext des Proxys ausgeführt. Das bedeutet, dass ein delegatecall-Ziel masterCopy an Slot 0 direkt überschreiben und die gesamte Implementierung in einer einzigen Transaktion ersetzen kann.

Schwachstellenanalyse

Der Angriffsvektor durchlief drei Systemebenen, wobei jede eine strukturelle Bedingung darstellte, die der Angreifer ausnutzte:

Frontend-Serving-Modell. Das JavaScript-Frontend von Safe{Wallet} wurde aus einem AWS S3-Bucket bereitgestellt. Bei dieser Architektur kann jeder mit Schreibzugriff auf den Bucket den Code ändern, der die Transaktionen für Unterzeichner erstellt. Integritätsprüfungsmechanismen wie Subresource Integrity (SRI)-Hashes oder Code-Signierung können dieses Risiko mindern, sind aber für die meisten dApp-Frontends noch kein Standard. Der Angreifer erhielt Schreibzugriff über die kompromittierte Entwicklermaschine und modifizierte stillschweigend das bereitgestellte JavaScript.

Lücke zwischen UI-Anzeige und Signier-Payload. Das injizierte JavaScript zeigte eine legitim aussehende Transaktion in der Safe{Wallet}-UI an, während es eine andere Nutzlast an die Ledger-Hardware-Wallets sendete. Die auf dem Ledger-Bildschirm angezeigten Transaktionsdetails hätten sich von der UI unterschieden, aber die Interpretation von Rohdaten auf dem Bildschirm einer Hardware-Wallet ist nicht einfach, insbesondere bei komplexen Multisig-Operationen. Diese Lücke ermöglichte es dem Angreifer, drei gültige Signaturen für die bösartige Nutzlast zu sammeln.

Proxy-Upgrade-Modell. Wie im Hintergrund beschrieben, führt delegatecall den Code des Ziels im Speicher-Kontext des Proxys aus. Die Safe-Proxy-Architektur leitet alle Aufrufe über einen einzigen masterCopy-Zeiger an Slot 0. Das Überschreiben dieses Zeigers leitet den Proxy in einer einzigen Transaktion auf eine völlig andere Implementierung um, einschließlich ihrer Signaturprüfungslogik. Das n-von-m-Modell regelt, wer eine Transaktion initiieren kann, aber sobald eine Transaktion genehmigt und ausgeführt wird, kann sie die Implementierung selbst ändern. Wenn die neue Implementierung die Signaturprüfung entfernt, ist der Multisig-Schutz für alle nachfolgenden Transaktionen praktisch aufgehoben.

Angriffsanalyse

Der Angriff erfolgte in drei Schritten: Bösartige Code-Injektion, Implementierungswechsel und Vermögensdiebstahl.

Schritt 1: Bösartige Code-Injektion

Der Angreifer kompromittierte die Maschine eines Safe{Wallet}-Entwicklers und injizierte bösartigen JavaScript-Code in den AWS S3-Bucket, der das Frontend bereitstellte. Der injizierte Code zielte speziell auf Transaktionen von der Safe-Adresse von Bybit ab. Laut Bybits CEO Ben Zhou [2] zeigte die Safe{Wallet}-UI eine legitime Transaktion an, während eine andere Nutzlast an die Ledger-Geräte der Unterzeichner gesendet wurde. Die Unterzeichner genehmigten die Transaktion, wie sie in der UI präsentiert wurde, und gaben dem Angreifer damit drei gültige Signaturen für die bösartige Nutzlast.

Schritt 2: Implementierungswechsel

Der Angreifer reichte die bösartige Transaktion mit den drei gesammelten Signaturen ein. Der Safe-Proxy leitete den Aufruf an masterCopy weiter, dessen execTransaction() die Signaturen validierte und dann die Transaktionsnutzlast ausführte: einen delegatecall an den Vertrag des Angreifers (0x962214...5c7242). Da dieser delegatecall im Speicher-Kontext des Proxys ausgeführt wird, überschrieb die transfer()-Funktion des Angreifers den Wert von masterCopy an Slot 0 mit der Adresse einer bösartigen Implementierung (0xbDd077...9516). Von diesem Zeitpunkt an wurden alle Aufrufe an den Safe-Vertrag an den Code des Angreifers delegiert.

Schritt 3: Vermögensdiebstahl

Da masterCopy nun auf die Implementierung des Angreifers zeigte, galt die Multisig-Anforderung nicht mehr. Der Angreifer rief direkt SweepERC20() und SweepETH() auf dem Safe-Vertrag auf. Diese Funktionen, die im Implementierungsvertrag des Angreifers definiert sind, transferierten alle gehaltenen Vermögenswerte ohne jegliche Signaturprüfung. Fünf Abhebungs-Transaktionen wurden ausgeführt und beliefen sich auf insgesamt rund 1,5 Milliarden US-Dollar an Verlusten.

Typ	Beschreibung	Adresse / Hash
Vertrag	Bybits Safe-Vertrag	0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4
Vertrag	Der ursprüngliche masterCopy-Vertrag	0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F
Vertrag	Der bösartige masterCopy-Vertrag	0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516
Vertrag	Der Vertrag des Angreifers (d.h. transfer())	0x96221423681A6d52E184D440a8eFCEbB105C7242
Transaktion	Tx ersetzte den masterCopy-Vertrag	0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
Transaktion	Tx hob 15.000 cmETH ab	0x847b8403e8a4816a4de1e63db321705cdb6f998fb01ab58f653b863fda988647
Transaktion	Tx hob 90.375 stETH ab	0xa284a1bc4c7e0379c924c73fcea1067068635507254b03ebbbd3f4e222c1fae0
Transaktion	Tx hob 8.000 mETH ab	0xbcf316f5835362b7f1586215173cc8b294f5499c60c029a3de6318bf25ca7b20
Transaktion	Tx hob 401.346 ETH ab	0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c
Transaktion	Tx hob 90 USDT ab	0x25800d105db4f21908d646a7a3db849343737c5fba0bc5701f782bf0e75217c9

Zusammenfassung

Dieser Vorfall zeigte, wie ein Kompromittieren von Off-Chain-Infrastruktur zu katastrophalen On-Chain-Verlusten eskalieren kann. Der Angreifer verband einen Web2-Einbruch, eine Frontend-Manipulation und ein Proxy-Upgrade zu einem einzigen Angriffsvektor, der den Multisig-Schutz umging, ohne eine On-Chain-Schwachstelle auszunutzen.

Wichtige Lektionen:

Frontend-Integrität verdient die gleiche Aufmerksamkeit wie On-Chain-Sicherheit. Die Angriffskette begann auf der Frontend-Serving-Ebene. Da dApps zunehmend hochvolumige Transaktionen vermitteln, wird der Schutz von Frontend-Code mit Integritätsprüfungen (SRI, Code-Signierung, reproduzierbare Builds) und die Überwachung auf unbefugte Änderungen zu einer grundlegenden Anforderung.
Hardware-Wallet-Verifizierung bleibt in der Praxis schwierig. Hardware-Wallets können die tatsächliche Signier-Payload anzeigen, aber die Interpretation komplexer Multisig-Transaktionsdaten auf einem kleinen Bildschirm ist eine bekannte Benutzerfreundlichkeitsherausforderung. Die Verbesserung der Lesbarkeit von On-Device-Transaktionszusammenfassungen ist ein offenes Problem für das Wallet-Ökosystem.
Proxy-Upgrade-Mechanismen sind Ziele mit hohem Hebelwirkung. Die Safe-Proxy-Architektur leitet die gesamte Logik über einen einzigen aufrüstbaren Zeiger. Jeder Mechanismus, der einen einstufigen Implementierungswechsel ermöglicht, konzentriert das Risiko. Das Hinzufügen eines Timelocks, eines sekundären Bestätigungsschritts oder eines unabhängigen Guardians für Upgrades kann die Auswirkungen einer einzelnen kompromittierten Transaktion reduzieren.

Referenzen

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden helfen, Code-Audits (einschließlich Smart Contracts, Blockchain und Wallets) durchzuführen, Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zu verfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen zu erfüllen.

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