Verfasst von: imToken
Eine Hardware-Wallet mit intakten Original-Chips, echter Firmware und sogar der Fähigkeit, den offiziellen Genuine Check erfolgreich zu bestehen – könnten die darin befindlichen Vermögenswerte dennoch von Hackern gestohlen werden?
Der jüngste Ledger-Sicherheitsvorfall hat genau dieses scheinbar unmögliche Risiko offengelegt.
Den anschließend vom Ledger-Sicherheitsteam offengelegten Untersuchungsergebnissen zufolge hat der Angreifer im Inneren des betroffenen Geräts eine zusätzliche bösartige Schaltung implantiert, die in der Lage war, die auf dem Bildschirm angezeigte Mnemonic-Phrase abzufangen und über Mobilfunknetze an den Angreifer zu senden.
Mit anderen Worten: Der ursprüngliche Sicherheitschip wurde nicht kompromittiert, aber die Mnemonic-Phrase könnte bereits beim ersten Anzeigen auf dem Bildschirm in die Hände des Hackers gefallen sein.
Darüber hinaus ist dies nicht der einzige Sicherheitsvorfall, der in letzter Zeit Beachtung verdient.
Seit September – von Bitget, das auf die Ausnutzung einer Schwachstelle in einem Sicherheitsprodukt eines Drittanbieters stieß, über Trezors E-Mail-Dienstleister Brevo, der kompromittiert wurde, bis hin zu Sicherheitsproblemen in einigen Infrastrukturen von MetaMask – erinnert uns eine Reihe von Vorfällen daran, dass mit der zunehmenden Komplexität von Crypto-Produkten Sicherheit nicht mehr nur den Schutz privater Schlüssel und die Vermeidung von Smart-Contract-Schwachstellen bedeutet.
Die in der Gerätezirkulation, bei Drittanbieterdiensten, bei internen Berechtigungen und in der Nutzerkommunikation verborgenen Risiken können ebenso zu Einstiegspunkten werden, die Angreifer suchen.
I. Der neue Alarm zur „Supply-Chain-Sicherheit“, den Ledger ausgelöst hat
Zerlegen wir zunächst, was diesmal bei Ledger passiert ist.
Beim Kauf einer Hardware-Wallet sind Menschen normalerweise vor zwei Dingen auf der Hut: ein Fälschung zu kaufen oder ein Gerät zu erhalten, das von jemand anderem vorab initialisiert wurde.
Der in den frühen Jahren häufigste Trick bestand darin, dass bösartige Zwischenhändler zuerst eine Mnemonic-Phrase generierten, sie auf eine Rubbelkarte druckten und wieder in die Verpackung steckten – in der Hoffnung, dass unerfahrene Nutzer die Regeln nicht verstehen und direkt Guthaben darauf einzahlen würden.
Obwohl dieser Betrug gefährlich ist, ist die Verteidigungslogik sehr klar – legitime Kanäle nutzen, den Gerätestatus prüfen, darauf achten, dass das Gerät selbst eine neue Mnemonic-Phrase generiert, und niemals eine fertige Mnemonic-Phrase aus der Box verwenden.
Doch dieser Angriff gegen Ledger hat die Methoden eindeutig eskaliert. Der Hacker stopfte im Inneren des Gehäuses ein zusätzliches elektronisches Modul mit Mikrocontroller, eSIM und Mobilfunkkommunikationsfähigkeiten hinein. Wenn Nutzer die Wallet zum ersten Mal initialisieren, müssen sie letztendlich die Mnemonic-Phrase vom Bildschirm ablesen und aufschreiben.
Mit anderen Worten: Die implantierte bösartige Schaltung greift überhaupt nicht in den Prozess der Mnemonic-Generierung ein; sie überwacht lediglich die Mnemonic-Phrase und überträgt sie direkt weg. Das ist auch der Grund, warum „der private Schlüssel wurde nicht direkt aus dem Sicherheitschip extrahiert“ nicht bedeutet, dass die Wiederherstellungsinformationen der Wallet des Nutzers noch sicher sind.
Erschwerend kommt hinzu, dass selbst wenn das Gerät den offiziellen Genuine Check besteht, es diese zusätzliche Hardware möglicherweise nicht identifizieren kann, da die Echtheitsprüfung hauptsächlich die Identität des Sicherheitschips und die Vertrauenswürdigkeit der Firmware bestätigt.
Dieser Vorfall hat also tatsächlich ein ernstes „Supply-Chain-Risiko“ offengelegt, das im Alltag leicht übersehen wird: Die Sicherheit einer Hardware-Wallet hängt nicht nur von Chip und Firmware ab, sondern auch vom gesamten Lieferprozess vom Originalwerk bis in die Hände des Nutzers.
Schließlich kann ein Gerät mehrere Glieder wie regionale Distributoren, Drittanbieter-Lager, Logistik und Einzelhändler durchlaufen. Jeder Beteiligte, der die Möglichkeit hat, physisch auf das Gerät zuzugreifen, kann zu einem Risikopunkt werden, der zusätzlicher Bewertung bedarf.
II. Von Trezor zu Bitget: Wie umgehen Angreifer die zentralen Sicherheitsverteidigungen?
Nachdem wir Ledgers Problem verstanden haben, werden wir, wenn wir uns dann die Sicherheitsvorfälle ansehen, auf die Bitget und Trezor kürzlich nacheinander gestoßen sind, feststellen, dass die zugrunde liegende Logik verblüffend ähnlich ist: Auch die Angreifer vermieden die stärkste frontale Verteidigungslinie und drangen stattdessen über die peripheren „Drittanbieterdienste“ ein.
Schauen wir zuerst auf Trezor.
Anfang September erhielten einige Trezor-Nutzer eine E-Mail mit dem Betreff „Kritische Sicherheitswarnung: STM32-Entropie-Schwachstelle“, in der behauptet wurde, die Hardware-Wallet habe eine schwerwiegende Sicherheitslücke und es sei sofortiges Handeln erforderlich.
Solche E-Mails machen Nutzer leicht nervös. Schließlich möchte niemand, wenn es um Hardware-Wallets und Sicherheitslücken geht, dass seine Vermögenswerte dadurch Verluste erleiden.
Genau das ist passiert: Der Angreifer nutzte Brevo, die von Trezor verwendete E-Mail-Marketing-Plattform eines Drittanbieters, aus, damit schädliche Inhalte über die normale E-Mail-Versandinfrastruktur in die Posteingänge der Nutzer gelangen konnten.
Laut dem späteren Vorfallbericht von Brevo nutzte der Angreifer Berechtigungsgrenzfehler in seinem Single-Sign-on-System aus, um unbefugten Zugriff auf andere Kundenkonten zu erlangen, was letztlich 138 Kundenkonten betraf, von denen einige zur Versendung von Phishing-E-Mails oder zum Export von Kontaktdaten verwendet wurden.
Trezor bestätigte anschließend, dass bei dem Vorfall 347.149 Kontaktadressen für Marketing-E-Mails exportiert wurden und die Angriffs-E-Mails versuchten, Nutzer zum Herunterladen schädlicher Anwendungen und zur Eingabe von Wallet-Backup-Informationen zu verleiten.
Es sei darauf hingewiesen, dass es in diesem Vorfall keine Hinweise darauf gibt, dass die Hardware-Wallets oder die Private-Key-Schutzsysteme von Trezor kompromittiert wurden. Was der Angreifer zuerst erlangte, waren Nutzerinformationen und die Fähigkeit, offizielle Kommunikationskanäle zu missbrauchen.
Doch für gewöhnliche Nutzer, die die E-Mails erhielten, wurde es noch schwieriger, das Risiko zu erkennen, denn die E-Mails konnten von einer vertrauten offiziellen Domain stammen und auch normale E-Mail-Authentifizierungsprüfungen bestehen, während der Inhalt bereits vom Angreifer durch Phishing-Informationen ersetzt worden war.
Wenn Nutzer deshalb freiwillig ihre Mnemonic-Phrase eingeben, könnte sich ein ursprünglich nur auf einen Drittanbieter-E-Mail-Dienst beschränktes Problem weiter zu echten Vermögensverlusten entwickeln.
Schauen wir uns nun Bitget an.
Am 24. September kam es in einigen Hot Wallets und Warm Wallets von Bitget zu unbefugten Vermögenstransfers, die sich letztlich auf etwa 388 Millionen US-Dollar beliefen.
Den von Bitget offiziell bekannt gegebenen Untersuchungsergebnissen zufolge nutzte der Angreifer eine Schwachstelle in einem Sicherheitsprodukt eines Drittanbieters aus, um hochprivilegierte Anmeldedaten innerhalb der Börse zu erlangen, drang dann in walletbezogene Backend-Systeme ein, fälschte Auszahlungsanweisungen, umging ursprüngliche Risikokontrollprüfungen und bewirkte, dass abnormale Transfers in den normalen Ausführungsprozess gelangten.
Bitget erklärte, dass bei diesem Vorfall keine Private-Key-Leckage festgestellt wurde und Cold Wallets nicht betroffen waren. Das klingt etwas widersprüchlich: Wenn die Private Keys nicht gestohlen wurden, warum konnte das Geld dennoch abgezogen werden?
Eigentlich ist das nicht schwer zu verstehen.
Bei Verwahrplattformen wie Börsen ist es nach der Auslösung einer Auszahlung durch einen Nutzer nicht so, dass jedes Mal eine Person jede Transaktion manuell mit einem Private Key signiert. Stattdessen muss sie eine ganze Reihe interner Prozesse wie Kontoverifizierung, Risikokontrollprüfung, Transaktionserstellung und Wallet-Signierung durchlaufen.
Das ist wie ein Banktresor. Selbst wenn der Tresorschlüssel sehr streng verwahrt wird, können Gelder im Tresor dennoch irrtümlich abtransferiert werden, wenn jemand eine interne hochprivilegierte Identität vortäuschen und eine genehmigungsfähige Überweisungsanweisung fälschen kann.
Was Bitget diesmal offengelegt hat, ist genau, wie sich das Risiko weiter auf das Asset-Ausführungssystem ausbreitet, nachdem vorgelagerte Berechtigungen und die Anweisungsverifizierung versagt haben. Daher sind „der Private Key wurde nicht geleakt“ und „Gelder werden nicht illegal abtransferiert“ tatsächlich zwei verschiedene Dinge.
Was den Ende September von MetaMask offengelegten Sicherheitsvorfall in der Infrastruktur betrifft, so stellte er eine weitere Dimension des operationellen Risikos dar.
Zu diesem Zeitpunkt ergriff MetaMask vorbeugende Maßnahmen und zog sich proaktiv aus einigen betroffenen Staking-Validatoren zurück. Laut dem offiziellen Untersuchungsupdate vom 1. Oktober wurden keine Anzeichen dafür gefunden, dass MetaMask-Wallets oder Kundengelder betroffen waren, und das betreffende Staking-Geschäft verwaltet keine Auszahlungsschlüssel im Namen der Kunden.
Dies bedeutet jedoch nicht, dass Infrastrukturprobleme keine anderen Auswirkungen haben werden. Nicht-verwahrende Lösungen adressieren hauptsächlich das Problem der Vermögensverwaltung, können jedoch die operationellen Risiken externer Infrastruktur nicht automatisch beseitigen.
Wenn man diese Ereignisse zusammenfügt, ist der rote Faden tatsächlich sehr klar:
- Was Ledger offengelegt hat, ist das Risiko physischer Manipulation im Hardware-Umlaufprozess, das letztendlich zum Diebstahl von Mnemonic-Phrasen führen kann;
- Was Trezor / Brevo offengelegt hat, ist das Risiko der Offenlegung von Nutzerinformationen und des Missbrauchs offizieller Kommunikationskanäle, was nicht bedeutet, dass die Wallet selbst kompromittiert wurde;
- Was Bitget offengelegt hat, ist das Risiko, dass Schwachstellen in Drittanbieterprodukten auf interne Systeme mit hohen Privilegien übertragen werden, was die Ausführung von Geldern direkt beeinflussen kann;
- MetaMask wiederum erinnert uns daran, dass Vermögensverwaltung und Betriebsrisiko des Dienstes nicht dasselbe Konzept sind.
Insgesamt sind die Crypto-Produkte von heute keine isolierten Inseln mehr.
Wallets sind auf externe RPC-Knoten angewiesen, um On-Chain-Daten zu lesen, und auf Aggregationsschnittstellen, um Marktkurse abzurufen; Börsen können nicht ohne externe Sicherheitsüberwachung, KYC-Verifizierung und Risikokontrollkomponenten auskommen; weiter nach außen erstrecken sich auch Knotenbetreiber, Cloud-Anbieter, Kundendienst-Tickets und E-Mail-Systeme wie Brevo.
Diese externen Dienste lassen Produkte effizienter laufen und verbessern auch die Benutzererfahrung, aber gleichzeitig gewinnt das Produkt mit jeder neuen externen Abhängigkeit eine weitere Ebene von Vertrauensbeziehungen hinzu, die verwaltet werden müssen:
Worauf können Dritte zugreifen, über wie viel Befugnis verfügen sie, und wenn sie kompromittiert werden, wird das Risiko dann weiter auf andere Kernsysteme übertragen?
III. Wie sollten sich Produkte und Nutzer verteidigen?
Angesichts zunehmend komplexer Risiken durch Drittanbieter-Abhängigkeiten und ineinandergreifender Abhängigkeitsbeziehungen ist es offensichtlich unrealistisch zu erwarten, dass Produktteams in den Urzustand „sich auf keine externen Dienste zu verlassen“ zurückkehren, und es entspricht auch nicht den Marktregeln.
Was die Fähigkeit einer Sicherheitsarchitektur wirklich auf die Probe stellt, ist die Minimierung jeder möglichen Risikoexposition.
Warum sollte beispielsweise ein SaaS-Anbieter, der nur Marketing-E-Mails verarbeitet, die Kontaktdaten aller Nutzer langfristig aufbewahren? Warum können externe Sicherheitsüberwachungstools ohne unabhängige Mehrfachautorisierung auf die zentrale Produktionsumgebung zugreifen? Besonders bei sensiblen Aktionen, die Geldtransfers betreffen, dürfen interne Systeme niemals „Standardvertrauen“ übernehmen und müssen strikte Berechtigungsisolierung und unabhängige Gegenprüfung implementieren.
Das ist auch das, was in der Sicherheitsarchitektur oft als „Least Privilege“ und „Separation of Duties“ bezeichnet wird: Eine E-Mail-Versandplattform sollte nur über die zum Versenden von E-Mails erforderlichen Berechtigungen verfügen, Sicherheitsüberwachungstools sollten nicht nach Belieben Geldtransfers ausführen können, und eine große Auszahlung sollte nicht direkt allein auf der Grundlage einer von einem internen System übermittelten Anweisung genehmigt werden.
Der Ledger-Vorfall erinnert Hersteller von Hardware-Wallets zudem daran, dass das Sicherheitsmanagement sogar auf den physischen Umlaufprozess des Produkts ausgeweitet werden muss.
Von der Werksauslieferung über Lagerung und Logistik bis hin zur Lieferung durch Händler: Wie ein nachverfolgbarer Verwaltungsprozess aufgebaut wird, wie abnormales Zerlegen oder Austauschen von Geräten erkannt wird und wie betroffene Chargen und Nutzer nach einem Problem lokalisiert werden – all das sollte nicht als bloße Kanalverwaltungsarbeit betrachtet werden.
Denn für ein Hardware-Gerät, das private Schlüssel schützt, ist der Lieferprozess selbst Teil des Sicherheitssystems.
Für gewöhnliche Nutzer können wir natürlich weder die Software-Lieferkette einer Wallet prüfen noch jeden Lager- und Logistikschritt einer Hardware-Wallet einzeln untersuchen.
Aber das bedeutet nicht, dass wir das Risiko nur passiv tragen können. Zumindest gibt es einige Dinge, die es wert sind, im täglichen Gebrauch zu Gewohnheiten zu werden.
Erstens: Minimieren Sie unnötige Zwischenhändler beim Kauf von Hardware-Wallets.
Wenn die Umstände es zulassen, bestellen Sie vorzugsweise auf der offiziellen Website der Marke und lassen Sie die Lieferung direkt ab Werk oder aus dem offiziellen Lager erfolgen, was in der Regel die Wahrscheinlichkeit verringert, dass das Gerät nach Verlassen der Kontrolle des Herstellers von Dritten kontaktiert, zerlegt oder ausgetauscht wird.
Aus Sicht des Risikomanagements gilt: Je mehr unabhängige Parteien mit dem Gerät in Kontakt kommen, desto mehr Glieder erfordern zusätzliches Vertrauen; darüber hinaus sollten Sie nach Erhalt des Geräts dennoch auf Anomalien bei Verpackung und Aussehen achten, die Verifizierung mit offizieller Software abschließen und den Initialisierungsprozess strikt befolgen.
Zweitens: Es ist notwendig, neu zu verstehen, ob „offiziellen Nachrichten“ vertraut werden kann.
Der Trezor-Vorfall hat bereits gezeigt, dass selbst wenn eine E-Mail tatsächlich über die offiziell genutzte Serviceplattform versendet wurde, dies nicht bedeutet, dass die darin enthaltenen Links und Handlungsaufforderungen zwangsläufig sicher sind.
Insbesondere wenn es um sensible Vorgänge wie Wallet-Upgrades, Kontosperrungen, Asset-Migration und Schwachstellenbehebungen geht, sollten Sie am besten nicht direkt auf Links in der Nachricht klicken, sondern proaktiv über die von Ihnen gespeicherte offizielle Website-Adresse oder die bereits installierte offizielle App verifizieren.
Bei nicht-verwahrenden Wallets wie imToken müssen Nutzer ebenfalls offizielle Kanäle identifizieren, token.im als Grundlage für Download und Installation verwenden und bei anomalen Informationen vorrangig über offizielle Zugänge wie „Hilfe & Feedback“ in der App verifizieren.
Unabhängig davon, ob die Gegenseite behauptet, offizieller Kundenservice oder ein Sicherheitsteam zu sein, oder eine scheinbar sehr professionelle Schwachstellenerklärung liefert, sollten Sie ihr niemals Ihre Mnemonic-Phrase oder Ihren privaten Schlüssel offenlegen.
Schließlich ist es notwendig, die tatsächlichen Auswirkungen verschiedener Sicherheitsvorfälle auf Sie selbst zu unterscheiden.
Ein Leck einer E-Mail-Adresse bedeutet hauptsächlich, dass Sie künftig möglicherweise mit gezielterem Phishing konfrontiert werden; das Anklicken eines verdächtigen Links erfordert eine weitere Bestätigung, ob schädliche Programme heruntergeladen oder ausgeführt wurden; wenn eine Mnemonic-Phrase bereits eingegeben wurde, sollte dies sofort als Verlust der Wallet-Kontrolle behandelt werden.
Wenn verdächtige Transaktionen oder Autorisierungen signiert wurden, ist es ebenfalls erforderlich, die konkreten On-Chain-Vorgänge zu kombinieren, um festzustellen, ob ein fortbestehendes Vertragsautorisierungsrisiko besteht.
Bei Ausfällen von Drittanbieterdiensten oder Anomalien der Infrastruktur ist es eher erforderlich, den offiziell offengelegten Auswirkungsbereich heranzuziehen, um festzustellen, ob Ihre Vermögenswerte, die Dienstverfügbarkeit oder Renditen betroffen sind.
Sie können nicht allein deshalb, weil Sie von einem „Wallet-Sicherheitsvorfall“ hören, voreilig zu dem Schluss kommen, dass der private Schlüssel kompromittiert wurde, und Sie sollten erst recht nicht aufgrund sogenannter dringender Sicherheitsbenachrichtigungen voreilig Vermögenswerte an unbekannte Adressen übertragen.
Schließlich erwarten Angreifer in vielen Fällen nicht wirklich, die stärkste technische Verteidigungslinie zu durchbrechen, sondern vielmehr, dass Nutzer in Panik freiwillig den letzten Schritt vollziehen (Weiterlesen: „KI „fordert“ Kryptographie heraus? Web3 muss für schlechte Zeiten vorsorgen, darf aber niemals überstürzt migrieren“).
Abschließende Gedanken
In der Vergangenheit war der Satz, der in der Crypto-Branche am häufigsten betont wurde, „Not your keys, not your coins.“
Dieser Satz ist nach wie vor wichtig, denn die Kontrolle über den privaten Schlüssel bestimmt, ob Nutzer ihre Vermögenswerte wirklich unabhängig kontrollieren können.
Doch während Wallets, Börsen und On-Chain-Finanzprodukte allmählich ausgereift werden, müssen wir auch erkennen, dass der Schutz des privaten Schlüssels nur ein Teil des gesamten Sicherheitssystems ist.
Eine echte Hardware-Wallet kann während der Lieferung dennoch physisch manipuliert werden; eine Benachrichtigung, die tatsächlich aus einem offiziellen E-Mail-System versendet wurde, kann ebenfalls von Angreifern ausgenutzt werden; und eine Reihe von Drittanbieter-Tools, die ursprünglich zur Stärkung der Sicherheit gedacht waren, können sogar zu einem Einstiegstor in das Kernfondsystem werden.
Diese Fälle bedeuten nicht, dass wir das Vertrauen in alle Wallets und externen Dienste verlieren sollten. Im Gegenteil, sie erinnern die gesamte Branche daran, dass Sicherheit von einem einzelnen Produkt auf den gesamten Prozess der Lieferkette, der Berechtigungsverwaltung, der Nutzerkommunikation und der Notfallreaktion ausgeweitet werden muss.
Schließlich muss ein wirklich ausgereiftes Crypto-Sicherheitssystem nicht nur gewährleisten, dass private Schlüssel nicht leichtfertig preisgegeben werden, sondern auch so weit wie möglich sicherstellen, dass selbst wenn ein bestimmtes externes Glied schiefgeht, der gesamte Mechanismus das Risiko noch auf halbem Weg entschlossen stoppen und verhindern kann, dass es die letzte rote Linie zum Schutz der Nutzervermögenswerte überschreitet.
