Am 21. Februar 2025 verlor Bybit etwa 1,5 Milliarden US-Dollar, nachdem ein Angreifer durch Social Engineering den Computer eines Safe{Wallet}-Entwicklers kompromittiert hatte. Der Angreifer schleuste schädlichen JavaScript-Code in den AWS S3-Bucket von Safe{Wallet} ein und zielte dabei gezielt auf die Transaktionen von Bybit ab. Der eingeschleuste Code veränderte den Inhalt der Transaktion während des Signiervorgangs: Die Benutzeroberfläche von Safe{Wallet} zeigte eine legitime Transaktion an, während die tatsächliche Nutzlast (Payload), die an die Ledger-Geräte der Unterzeichner gesendet wurde, den Safe-Vertrag von Bybit auf eine bösartige Implementierung aktualisierte und dem Angreifer die volle Kontrolle übertrug. Sobald die Transaktion signiert und ausgeführt wurde, räumte der Angreifer alle Vermögenswerte aus dem Vertrag ab. Eine detaillierte technische Analyse finden Sie in unserem früheren Bericht [1].
Hintergrund
Safe{Wallet} (auch bekannt als GnosisSafe) ist eine Multisig-Wallet-Infrastruktur, die ein n-von-m-Modell verwendet: Für die 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 zentral:
masterCopy(Slot 0): die Adresse des Implementierungsvertrags. Dieser Vertrag enthält die gesamte Ausführungslogik, einschließlich der Signaturprüfung und der Upgrade-Mechanismen. Der Proxy delegiert alle Aufrufe viadelegatecallan diemasterCopy.threshold(Slot 4): die erforderliche Mindestanzahl an Signaturen (n). Bei Bybits Safe lag dieser Wert bei 3.
Da der Proxy delegatecall verwendet, wird jede Funktion, die auf der masterCopy aufgerufen wird, im Speicherkontext des Proxys ausgeführt. Das bedeutet, dass ein delegatecall-Ziel die masterCopy an Slot 0 direkt überschreiben und damit 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-Bereitstellungsmodell. Das JavaScript des Safe{Wallet}-Frontends wurde von einem AWS S3-Bucket bereitgestellt. In dieser Architektur kann jeder mit Schreibzugriff auf den Bucket den Code verändern, der Transaktionen für Unterzeichner erstellt. Mechanismen zur Integritätsprüfung wie Subresource Integrity (SRI)-Hashes oder Code-Signierung können dieses Risiko mindern, sind jedoch für die meisten dApp-Frontends noch kein Standard. Der Angreifer erlangte durch den kompromittierten Entwickler-Computer Schreibzugriff und änderte im Stillen das bereitgestellte JavaScript.
Diskrepanz zwischen UI-Anzeige und Signatur-Payload. Das eingeschleuste JavaScript zeigte eine legitim aussehende Transaktion auf der Safe{Wallet}-Benutzeroberfläche an, während gleichzeitig eine andere Nutzlast an die Ledger-Hardware-Wallets gesendet wurde. Die auf dem Ledger-Bildschirm angezeigten Transaktionsdetails unterschieden sich von denen in der UI, doch die Interpretation von rohen Transaktionsdaten auf einem Hardware-Wallet-Bildschirm ist nicht trivial, insbesondere bei komplexen Multisig-Vorgängen. 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 Speicherkontext 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 deren Signaturprüfungslogik. Das n-von-m-Modell regelt, wer eine Transaktion einleiten darf, 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 effektiv aufgehoben.
Angriffsanalyse
Der Angriff verlief in drei Schritten: Schleusen von schädlichem Code, Austausch der Implementierung und Diebstahl von Vermögenswerten.
Schritt 1: Einschleusen von schädlichem Code
Der Angreifer kompromittierte den Computer eines Safe{Wallet}-Entwicklers und schleuste schädliches JavaScript in den AWS S3-Bucket ein, der das Frontend bereitstellt. Der injizierte Code zielte speziell auf Transaktionen von Bybits Safe-Adresse ab. Laut dem CEO von Bybit, 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 in der UI angezeigt und gaben dem Angreifer so drei gültige Signaturen für die bösartige Nutzlast.
Schritt 2: Austausch der Implementierung
Der Angreifer reichte die bösartige Transaktion mit den drei gesammelten Signaturen ein. Der Safe-Proxy delegierte den Aufruf an die masterCopy, deren execTransaction() die Signaturen validierte und dann die Transaktions-Payload ausführte: ein delegatecall an den Vertrag des Angreifers (0x962214...5c7242). Da dieser delegatecall im Speicherkontext des Proxys läuft, überschrieb die transfer()-Funktion des Angreifers den Wert von masterCopy an Slot 0 mit einer bösartigen Implementierungsadresse (0xbDd077...9516). Von diesem Zeitpunkt an wurden alle Aufrufe an den Safe-Vertrag an den Code des Angreifers delegiert.
Schritt 3: Diebstahl von Vermögenswerten
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 waren, transferierten alle gehaltenen Vermögenswerte ohne jegliche Signaturprüfung. Es wurden fünf Abzugstransaktionen durchgeführt, die sich auf insgesamt ca. 1,5 Milliarden US-Dollar beliefen.
Zugehörige Verträge und Transaktionen
Zusammenfassung
Dieser Vorfall hat gezeigt, wie eine Kompromittierung der Off-Chain-Infrastruktur zu katastrophalen On-Chain-Verlusten führen kann. Der Angreifer verknüpfte einen Web2-Einbruch, eine Frontend-Manipulation und ein Proxy-Upgrade zu einer einzigen Angriffskette, die den Multisig-Schutz umging, ohne dabei eine On-Chain-Schwachstelle auszunutzen.
Wichtige Erkenntnisse:
- Die Integrität des Frontends verdient die gleiche Aufmerksamkeit wie die On-Chain-Sicherheit. Die Angriffskette begann auf der Ebene der Frontend-Bereitstellung. Da dApps zunehmend hochwertige Transaktionen vermitteln, wird der Schutz von Frontend-Code durch Integritätsprüfungen (SRI, Code-Signing, reproduzierbare Builds) und die Überwachung auf unbefugte Änderungen zu einer grundlegenden Anforderung.
- Die Überprüfung durch Hardware-Wallets bleibt in der Praxis schwierig. Hardware-Wallets können zwar die tatsächliche Signatur-Nutzlast anzeigen, aber die Interpretation komplexer Multisig-Transaktionsdaten auf einem kleinen Bildschirm ist eine bekannte Herausforderung für die Benutzerfreundlichkeit. Die Verbesserung der Lesbarkeit von Transaktionszusammenfassungen auf dem Gerät ist ein ungelöstes Problem für das Wallet-Ökosystem.
- Proxy-Upgrade-Mechanismen sind Ziele mit hoher Hebelwirkung. Die Safe-Proxy-Architektur leitet die gesamte Logik über einen einzigen aufrüstbaren Zeiger. Jeder Mechanismus, der einen einstufigen Implementierungsaustausch ermöglicht, konzentriert das Risiko. Das Hinzufügen einer Zeitsperre (Timelock), eines zweiten Bestätigungsschritts oder eines unabhängigen Vormunds für Upgrades kann die Auswirkungen einer einzelnen kompromittierten Transaktion verringern.
Referenz
Über BlockSec
BlockSec ist ein Full-Stack Blockchain-Sicherheits- und Crypto-Compliance-Anbieter. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchain und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zurückzuverfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg zu erfüllen.
BlockSec hat mehrere Blockchain-Sicherheitspapiere auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, 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
