Die Bybit-Börse wurde am 21. Februar 2025 gegen 14:00 Uhr UTC gehackt, was zu Verlusten von nahezu 1,5 Milliarden führte – dem bislang größten Sicherheitsvorfall in der Geschichte der Kryptowährungen. Im Gegensatz zu früheren Sicherheitsverletzungen wurde dieser Diebstahl nicht durch Probleme mit Smart-Contract-Berechtigungen verursacht, sondern durch ein bösartiges Upgrade der Safe-Multisig-Wallet, die von Bybit verwendet wurde. Der Angreifer täuschte mehrere Betreiber der Safe-Wallet, indem er sie dazu brachte, eine Wallet-Upgrade-Transaktion zu signieren, und erlangte so erfolgreich die Kontrolle über die Safe-Wallet. Sobald er die Kontrolle hatte, räumte der Angreifer das Guthaben ab.
Wir haben festgestellt, dass dieser Angriff eine akribisch geplante Operation gegen Bybit war, bei der der Angreifer den Angriffs-Contract zwei Tage vor dem endgültigen Angriff on-chain bereitgestellt und getestet hatte. In diesem Blogbeitrag beginnen wir mit einer Einführung in die Safe-Wallet, analysieren den gesamten Angriffsprozess und bieten abschließend einige Sicherheitsempfehlungen an.
Was ist eine Safe Multisig Wallet
Eine Safe Multisig Wallet ist eine Art Smart-Contract-Wallet, deren Kernmerkmal die Verwendung mehrerer Schlüssel zur Autorisierung von Transaktionen ist. Diese Wallet erfordert, dass mehrere Benutzer (in der Regel vorab festgelegte Schlüsselhalter) eine Transaktion signieren, bevor eine Überweisung oder ein anderer Vorgang ausgeführt werden kann. Dies erhöht die Sicherheit und verhindert einen "Single Point of Failure" oder die Kompromittierung eines einzelnen Schlüssels.
Wenn die Wallet erstellt wird, werden mehrere Schlüssel eingerichtet (meist unter Verwendung eines "n-von-m"-Modells), was bedeutet, dass unter den mehreren Schlüsselhaltern eine bestimmte Anzahl von Signaturen erforderlich ist, damit eine Transaktion ausgeführt werden kann. Eine "3-von-5"-Multisig-Wallet bedeutet beispielsweise, dass von fünf Schlüsselhaltern mindestens drei Signaturen benötigt werden, damit die Transaktion gültig ist.
Obwohl es Methoden gibt, Transaktionen zu erstellen, ohne sich auf die offizielle Safe-Website zu verlassen, entscheiden sich die meisten Benutzer aus Gründen der Benutzerfreundlichkeit dafür, Transaktionen über die Safe-Website zu erstellen und zu signieren. Normalerweise besuchen Benutzer https://app.safe.global, um Transaktionen aufzubauen. Wenn Benutzer eine Safe-Wallet zum Erstellen und Signieren einer Transaktion verwenden, simulieren sie die Transaktion zunächst, um das potenzielle Ergebnis nach der On-Chain-Ausführung zu verstehen und zu überprüfen, ob es ihren Erwartungen entspricht. Nur wenn das Ergebnis wie erwartet ausfällt, fährt der Betreiber mit dem Signiervorgang fort.
Unten sehen Sie einen Screenshot der Transaktionskonstruktionsschnittstelle in der Safe-Wallet. Da die Safe-Website derzeit vorübergehend nicht verfügbar ist, stammt der folgende Screenshot aus dem Internet (Quelle: https://milkroad.com/reviews/safe-wallet/).
In der Realität bestehen bei der Verwendung einer Safe-Wallet folgende Sicherheitsrisiken:
-
Lange Sicherheitskette: Benutzer müssen der offiziellen Safe-Website, der App und den Backend-Diensten sowie ihrem eigenen Computer, dem Browser und schließlich der zum Signieren verwendeten Wallet (ob Browsererweiterung oder Hardware-Wallet) vertrauen. Wenn eine dieser Komponenten von einem Angreifer kompromittiert wird, erhält der Betreiber möglicherweise falsche Informationen (Sie könnten beispielsweise eine Upgrade-Transaktion signieren, während die Benutzeroberfläche eine normale Überweisungstransaktion anzeigt).
-
Fehlende Transaktionsanalyse in Hardware-Wallets: Hardware-Wallets verfügen im Allgemeinen nicht über die Fähigkeit, Safe-Transaktionen zu analysieren. Dies bedeutet, dass Benutzer, wenn sie durch die Safe-Schnittstelle in die Irre geführt werden, keine Möglichkeit haben, während des letzten Signiervorgangs eine Gegenprüfung durchzuführen, was als "Blind Signing" bezeichnet wird.
Angriffsprozess
Vor dem Start des endgültigen Angriffs hatte der Angreifer den Angriffs-Contract bereits on-chain bereitgestellt und getestet. Mehrere verschiedene Adressen waren am gesamten Angriffsprozess beteiligt.
Schritt 1: Beschaffung von Mitteln
Der Angreifer musste zunächst die anfänglichen Mittel für den Angriff beschaffen. Normalerweise erhalten Angreifer Gelder über Mixing-Plattformen (z. B. Tornado Cash), um ihre Spuren zu verwischen. In diesem Fall stammten die Gelder des Angreifers jedoch von Binance. Wir glauben, dass dies eine Methode des Angreifers sein könnte, um seine Identität zu verschleiern, da Gelder und Adressen von Mixing-Diensten normalerweise von Sicherheitsfirmen genau überwacht werden, während Gelder von Börsen weniger streng überwacht werden. Obwohl die Gelder von einer Börse stammten, ist es möglich, dass das Börsenkonto kein KYC-Verfahren durchlaufen hat oder dass seine KYC-Informationen gefälscht waren.
Schritt 2: Bereitstellung und Testen des Contracts
Bevor der eigentliche Angriff gestartet wurde, führte der Angreifer eine Reihe von Tests durch. Diese Tests umfassten die Bereitstellung einer Safe-Wallet, die Bereitstellung des Angriffs-Contracts und die Verwendung der selbst bereitgestellten Safe-Wallet zur Durchführung eines Upgrade-Vorgangs sowie zum Abheben von Geldern aus der modernisierten Safe-Wallet. Darüber hinaus experimentierte der Angreifer während der Tests nur mit einer begrenzten Auswahl an Vermögenswerten – solchen, die mit denen in der Wallet übereinstimmten, die schließlich bei Bybit geleert wurde. Dies deutet darauf hin, dass der Angreifer gezielt die Safe-Wallet von Bybit ins Visier nahm.
Der Angreifer erstellte eine Safe-Wallet zu Testzwecken; eine der Test-Safe-Wallet-Adressen lautete:
0x509b1eDa8e9FFed34287ccE11f6dE70BFf5fEF55
Der Angreifer testete das Upgrade des Safe-Contracts. Wir können die relevanten Informationen über den Phalcon Explorer unter folgendem Link einsehen:
Nach dem Testen des Upgrades fuhr der Angreifer mit dem Test des Auszahlungsprozesses fort. Sie zogen stETH-Vermögenswerte direkt aus dem aktualisierten Safe-Contract an der Adresse ab:
0x509b1eda8e9ffed34287cce11f6de70bff5fef55
Schritt 3: Täuschung der Benutzer beim Erstellen und Signieren der Upgrade-Transaktion
Nach Abschluss der Tests musste der Angreifer Benutzer dazu bringen, die Safe-Contract-Upgrade-Transaktion zu erstellen und zu signieren. Da die Tests zwei Tage zuvor durchgeführt wurden, fand die Täuschung wahrscheinlich innerhalb der zwei Tage nach den Tests statt. Es ist noch nicht öffentlich bestätigt, ob dies durch einen Angriff auf die Safe-Server oder die Computer der Wallet-Betreiber erreicht wurde.
Schritt 4: Starten des Angriffs
Sobald der Angreifer eine ausreichende Anzahl von Signaturen erhalten hatte, reichte er die Transaktion on-chain ein und führte das Contract-Upgrade erfolgreich aus. Nach dem Upgrade zog der Angreifer die Gelder ab. Wir stellten fest, dass die bösartige Upgrade-Transaktion identisch mit der vorherigen Test-Transaktion war.
Lehren und Erkenntnisse
Tatsächlich ereigneten sich im letzten Jahr bereits zweimal ähnliche Angriffe – darunter die Diebstähle von Radiant und der indischen Börse WazirX (mit Verlusten von über 200 Millionen US-Dollar) – die alle auf bösartige Transaktionen zurückzuführen waren, die mit Safe-Wallets signiert wurden. Der Unterschied bei diesem Vorfall besteht darin, dass es sich bei der signierten Transaktion diesmal um eine Contract-Upgrade-Transaktion handelte. Daher bleibt das Ziehen von Lehren aus diesen Sicherheitsvorfällen und das Verhindern zukünftiger Angriffe eine Herausforderung, die Börsen und Projektteams, die große Mengen an digitalen Vermögenswerten halten, angehen müssen. Dies kann durch die Verbesserung der täglichen Abläufe, des internen Prozessmanagements, der Sicherheitsprotokolle für sensible Vorgänge und der Dezentralisierungseinstellungen erreicht werden, um das Risiko eines Angriffs zu verringern.
Zweitens bleibt die Frage, wie Wallets besser am Sicherheitsprozess während der Transaktionssignierung teilnehmen können, ungelöst. Derzeit mangelt es insbesondere Hardware-Wallets in der Regel an der Fähigkeit, komplexe Transaktionen zu analysieren. Da Hardware-Wallets zudem nicht direkt mit dem Internet verbunden sind, bleibt die Durchführung von Transaktionssimulationen (und die verständliche Präsentation der Ergebnisse für den Benutzer), um "blindes Signieren" zu vermeiden, eine Herausforderung.
Darüber hinaus ist es notwendig, mehrere Sicherheitsmaßnahmen zu implementieren, wie beispielsweise den Einsatz von Sicherheitsüberwachungsplattformen wie BlockSec Phalcon, um Safe-Wallets zu überwachen und sicherzustellen, dass jedes anormale Verhalten umgehend erkannt und behoben wird. Phalcon verfügt bereits über die Fähigkeit, Safe-Wallets zu überwachen, und wir werden unsere Produkte weiter verbessern, sodass diese Überwachung in Zukunft automatisch konfiguriert werden kann, um Benutzern bei der Verwendung von Safe zur Verwaltung großer Vermögenswerte zu helfen, Risiken zu vermeiden. Obwohl dieser Vorfall durch die Verwendung einer Safe-Wallet verursacht wurde, besteht kein Grund zur Angst vor "Safe"; es bleibt der De-facto-Standard für Multisig-Wallets, dessen Contract-Sicherheit sich im Laufe der Zeit bewährt hat.
Abschließend müssen wir betonen, dass die Sicherheitsabwehr niemals ein Schlachtfeld für Einzeldurchbrüche ist und es kein Allheilmittel gibt, das ein für alle Mal funktioniert. Während sie die Betriebs- und Geschäftssicherheit gewährleisten, können Branchenteilnehmer BlockSec Phalcon als letzte Verteidigungslinie nutzen, um ihre Vermögenswerte zu schützen.
