Am 21. Februar 2025 verlor Bybit rund 1,5 Milliarden US-Dollar, nachdem ein Angreifer die Maschine eines Safe{Wallet}-Entwicklers mittels Social Engineering kompromittierte. Der Angreifer injizierte bösartigen JavaScript-Code in den AWS S3-Bucket von Safe{Wallet}, der speziell auf Bybit-Transaktionen abzielte. Der injizierte Code veränderte den Transaktionsinhalt während des Signierprozesses: Die Safe{Wallet}-Benutzeroberfläche zeigte eine legitime Transaktion an, während die tatsächlich an die Ledger-Geräte der Signierer gesendete Nutzlast den Safe-Vertrag von Bybit auf eine bösartige Implementierung aktualisierte und dem Angreifer so die volle Kontrolle gab. Nach der Signatur und Ausführung entzog der Angreifer alle Vermögenswerte aus dem Vertrag. Eine detaillierte technische Aufschlüsselung finden Sie in unserem früheren Bericht [1, 2].
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 Signierern erforderlich.
Jedes Safe-Wallet wird als Proxy-Vertrag bereitgestellt. Zwei Speicher variablen 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 überdelegatecallanmasterCopyweiter.threshold(Slot 4): Die Mindestanzahl der erforderlichen Signaturen (n). Für das Safe von Bybit waren dies 3.
Da der Proxy delegatecall verwendet, wird jede auf masterCopy aufgerufene Funktion im Speicher-Kontext des Proxys ausgeführt. Das bedeutet, dass ein delegatecall-Ziel masterCopy in Slot 0 direkt überschreiben und die gesamte Implementierung in einer einzigen Transaktion ersetzen kann.
Schwachstellenanalyse
Der Angriffspfad durchlief drei Ebenen des Systems, wobei jede eine strukturelle Bedingung bot, die der Angreifer ausnutzte:
Frontend-Serving-Modell. Das JavaScript-Frontend von Safe{Wallet} wurde aus einem AWS S3-Bucket bereitgestellt. In dieser Architektur kann jeder mit Schreibzugriff auf den Bucket den Code ändern, der Transaktionen für Signierer 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 keine Standardpraxis. Der Angreifer erlangte Schreibzugriff über die kompromittierte Entwicklermaschine und modifizierte stillschweigend das ausgelieferte JavaScript.
Lücke zwischen UI-Anzeige und Signier-Nutzlast. Das injizierte JavaScript zeigte eine legitim aussehende Transaktion in der Safe{Wallet}-Benutzeroberfläche 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 Benutzeroberfläche 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 in Slot 0. Das Überschreiben dieses Zeigers leitet den Proxy in einer einzigen Transaktion zu einer völlig anderen 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 wurde, kann sie die Implementierung selbst ändern. Wenn die neue Implementierung die Signaturprüfung entfernt, ist der Multisig-Schutz für alle nachfolgenden Transaktionen wirkungslos.
Angriffsanalyse
Der Angriff verlief in drei Schritten: Bösartige Code-Injektion, Implementierungsersetzung und Asset-Diebstahl.
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 Bybit CEO Ben Zhou [2] zeigte die Safe{Wallet}-Benutzeroberfläche eine legitime Transaktion an, während an die Ledger-Geräte der Signierer eine andere Nutzlast gesendet wurde. Die Signierer genehmigten die Transaktion, wie sie in der Benutzeroberfläche dargestellt wurde, und gaben dem Angreifer drei gültige Signaturen für die bösartige Nutzlast.
Schritt 2: Implementierungsersetzung
Der Angreifer reichte die bösartige Transaktion mit den drei gesammelten Signaturen ein. Der Safe-Proxy delegierte den Aufruf an masterCopy, 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 in 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: Asset-Diebstahl
Da masterCopy nun auf die Implementierung des Angreifers zeigte, galt die Multisig-Anforderung nicht mehr. Der Angreifer rief SweepERC20() und SweepETH() direkt auf dem Safe-Vertrag auf. Diese Funktionen, die im Implementierungsvertrag des Angreifers definiert sind, übertrugen alle gehaltenen Vermögenswerte ohne jegliche Signaturprüfung. Fünf Entnahme-Transaktionen wurden ausgeführt und führten zu Verlusten von rund 1,5 Milliarden US-Dollar.
Verwandte Verträge und Transaktionen
| 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 entzog 15.000 cmETH | 0x847b8403e8a4816a4de1e63db321705cdb6f998fb01ab58f653b863fda988647 |
| Transaktion | Tx entzog 90.375 stETH | 0xa284a1bc4c7e0379c924c73fcea1067068635507254b03ebbbd3f4e222c1fae0 |
| Transaktion | Tx entzog 8.000 mETH | 0xbcf316f5835362b7f1586215173cc8b294f5499c60c029a3de6318bf25ca7b20 |
| Transaktion | Tx entzog 401.346 ETH | 0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c |
| Transaktion | Tx entzog 90 USDT | 0x25800d105db4f21908d646a7a3db849343737c5fba0bc5701f782bf0e75217c9 |
Zusammenfassung
Dieser Vorfall zeigte, wie ein Kompromiss der Off-Chain-Infrastruktur zu katastrophalen On-Chain-Verlusten eskalieren kann. Der Angreifer reihte einen Web2-Einbruch, eine Frontend-Manipulation und ein Proxy-Upgrade zu einem einzigen Angriffspfad, der den Multisig-Schutz umging, ohne eine On-Chain-Schwachstelle auszunutzen.
Schlüssel-Lektionen:
- Frontend-Integrität verdient die gleiche Aufmerksamkeit wie On-Chain-Sicherheit. Die Angriffskette begann auf der Frontend-Serving-Ebene. Da dApps zunehmend Transaktionen mit hohem Wert 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 eigentliche Signier-Nutzlast anzeigen, aber die Interpretation komplexer Multisig-Transaktionsdaten auf einem kleinen Bildschirm ist eine bekannte Benutzerfreundlichkeits-Herausforderung. Die Verbesserung der Lesbarkeit von On-Device-Transaktionszusammenfassungen ist ein offenes Problem für das Wallet-Ökosystem.
- Proxy-Upgrade-Mechanismen sind Ziele mit hohem Einfluss. Die Safe-Proxy-Architektur leitet die gesamte Logik über einen einzigen upgradebaren Zeiger. Jeder Mechanismus, der eine einstufige Implementierungsersetzung ermöglicht, konzentriert das Risiko. Das Hinzufügen eines Timelocks, eines sekundären Bestätigungsschritts oder eines unabhängigen Wächters für Upgrades kann die Auswirkungen einer einzelnen kompromittierten Transaktion reduzieren.
Referenz
Über BlockSec
BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Code-Prüfung (einschließlich Smart Contracts, Blockchain und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Verfolgung illegaler Gelder und der Einhaltung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.
BlockSec hat zahlreiche Blockchain-Sicherheitsarbeiten auf angesehenen Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert und so mehr als 20 Millionen Dollar gerettet und Milliarden von Kryptowährungen gesichert.
-
Offizielle Website: https://blocksec.com/
-
Offizieller Twitter-Account: https://twitter.com/BlockSecTeam
