Sicherheitslücken von Hardware-Wallets: Die verborgene Bedrohung durch Lieferkettenangriffe

Die primären Sicherheitsbedrohungen, denen Hardware-Wallets ausgesetzt sind, stammen oft aus Manipulationen innerhalb der Lieferkette und nicht aus direkten Hackerangriffen. Benutzer kaufen Hardware-Wallets, um ihre privaten Schlüssel absolut offline zu speichern und so vor Zero-Day-Schwachstellen oder Trojanern geschützt zu sein. In der Realität ist die Wahrscheinlichkeit, dass ein Gerät aus der Ferne angegriffen wird, jedoch äußerst gering. Das eigentliche Risiko lauert im gesamten Ablauf von der Bestellung bis zur Transaktionssignatur.

Diese Bedrohung ist äußerst verborgen: Geräte können bereits vor der Auslieferung mit Malware versehen oder Komponenten ersetzt worden sein. Selbst wenn der Benutzer bemerkt, dass das Gerät "normal" funktioniert, könnte jede signierte Transaktion durch die vom Angreifer vorgegebene Logik kontrolliert werden.

Die Zerbrechlichkeit der Vertrauenskette

Der technologische Hauptvorteil von Hardware-Wallets besteht darin, eine vollständig isolierte Betriebsumgebung zu schaffen: Private Schlüssel werden offline generiert und gespeichert, und jede Transaktion muss physisch auf dem Gerätes Bildschirm bestätigt werden. Dieser Mechanismus stellt sicher, dass, selbst wenn der Host (wie ein Computer) mit Malware infiziert ist, der private Schlüssel nicht berührt werden kann, was die Hürde für Fernangriffe erheblich erhöht.

Dieses Sicherheitssystem beruht jedoch auf einem äußerst wichtigen Prinzip: Der Benutzer muss ein unverändertes Gerät, offizielle Firmware, legale Software und sichere Verbindungen erhalten. Sobald ein Glied dieser Lieferkette beschädigt wird, muss der Angreifer keine Rechenleistung aufwenden, um die grundlegenden Sicherheitschips zu knacken, sondern nur eine falsche Infrastruktur in der Anfangsphase bereitstellen. Wenn der Benutzer die gesamte Interaktionskette nicht effektiv verifizieren kann, bedeutet die sogenannte "Selbstverwahrung" eigentlich, die Kontrolle über die Vermögenswerte einem völlig unbekannten Risiko im blinden Lieferkettenbereich zu überlassen.

Analyse typischer Angriffsszenarien

Um die Funktionsweise dieser Risiken klarer zu verdeutlichen, folgt eine Zusammenfassung von fünf typischen Angriffsszenarien, die in der Branche tatsächlich vorgekommen sind:

Szenario 1: Gefälschte und manipulierte Geräte

Angreifer stellen häufig Verpackungen her, die mit denen der Originalhersteller identisch sind, um Geräte zu verkaufen, die mit vorinstallierten Hintertüren manipuliert wurden, und fügen im schlimmsten Fall gefälschte "offizielle Wiederherstellungscodekarten" hinzu. Sobald der Benutzer den Code gemäß der Karte importiert und Vermögenswerte transferiert, kann der Angreifer sofort die Kontrolle erlangen. Ein Team von Kaspersky hat eine Charge gefälschter Trezor-Hardware-Wallets zerlegt und analysiert und festgestellt, dass die internen Chips physisch ersetzt und die Firmware-Prüfmechanismen entfernt wurden. In solch einem Fall benutzt der Benutzer tatsächlich einen universellen Transparenzschlüssel für das gesamte Netzwerk.[1]

Demontage eines gefälschten Geräts

Szenario 2: Bösartige Firmware und gefälschte Updates

Einige Benutzer neigen dazu, nach dem Kauf eines Hardware-Wallets absolute Sicherheit anzunehmen. Angreifer nutzen dies oft aus, indem sie System-Upgrade-Hinweise fälschen und Benutzer zu gefälschten Update-Quellen führen, um modifizierte Firmware oder Kernkomponenten zu installieren. Zudem ist es eine gängige Praxis, Benutzer zur Rückstufung auf bekannte, anfällige Versionen zu verleiten. Das Hauptziel besteht darin, die angezeigten Inhalte des Geräts (wie Signaturhinweise, Empfangsadressen) vollständig zu kontrollieren oder vertrauliche Informationen des Benutzers zu stehlen.

Szenario 3: Frontend- und Abhängigkeitsbibliotheksvergiftung

Bei der Interaktion mit dem Blockchain-Netzwerk müssen Hardware-Wallets häufig eine Verbindung zu verschiedenen dApps herstellen. Die Frontend-Codes der dApps, Drittanbieter-Skripte und die zugrunde liegenden Abhängigkeitsbibliotheken sind ebenfalls wesentliche Bestandteile der Lieferkette. In der Branche gab es gravierende Fälle von Abhängigkeitsvergiftung: Angreifer griffen die Software-Vertriebskanäle an und schufen bösartigen Code in weit verbreitete Verbindungslibraries ein. Dadurch wurden mehrere Seiten, die diese Bibliotheken verwendeten, mit schädlichen Logiken dynamisch angereichert, um die Benutzer zur Unterzeichnung von Transaktionen zur Vermögensübertragung zu verleiten.[2] In solchen Fällen wurde das Hardware-Gerät selbst nicht kompromittiert, der Angreifer implementierte jedoch allein durch die Kontaminierung der Software-Lieferkette die Vermögensübernahme.

Bibliotheksvergiftung

Szenario 4: Leck von physischen Adressen und Bestellinformationen

Datenlecks stellen eine oft schwer unterschätzte Bedrohung für Benutzer von Hardware-Wallets dar. Wenn Angreifer Zugriff auf den Namen, die Telefonnummer, die Lieferadresse und Bestelldetails eines Benutzers erhalten, können sie zielgerichtete Social-Engineering-Angriffe durchführen. So könnte beispielsweise mit genauen Modellen und Bestellzeiten präzise Phishing-Angriffe durchgeführt werden; als offizielles Sicherheitsteam getarnt, um Benutzer zur dringenden Verifizierung aufzufordern; oder sogar an die physische Adresse des Benutzers Geräte mit Trojanern oder Phishing-Schutzkarten zu senden. In der Vergangenheit gab es bereits massive Datenlecks von Benutzer-Datenbanken durch Hardware-Wallet-Hersteller und deren Drittanbieter-Partner, die viele Bestelldaten mit physischen Adressangaben offenlegten und die Erfolgschancen zielgerichteter Betrugsversuche dramatisch steigerten.[3][4]

Datenleck

Szenario 5: Social Engineering und gefälschter Kundendienst

Das ultimative Ziel von Lieferkettenangriffen ist es oft, den Benutzer zu verleiten, Kerngeheimnisse preiszugeben oder bösartige Transaktionen zu unterzeichnen. Angreifer tarnen sich häufig mit scheinbar legitimen Prozessen, z.B. indem sie behaupten, dass das Gerät gefährdet sei und der Wiederherstellungscode zur Überprüfungszweck eingegeben werden muss, den Benutzer auffordern, den Code in ein Webtool zur sicheren Migration einzugeben, die Installation eines dringenden Sicherheitspatches anzuraten oder den Benutzer zur Signatur einer scheinbar harmlosen Transaktion (Permit) zu verleiten. Obwohl Hardware den privaten Schlüssel isolieren kann, kann sie menschliche psychologische Schwächen nicht ausschließen, insbesondere wenn der Angreifer über reale Bestellinformationen des Benutzers verfügt, was diese Art von Betrug erheblich überzeugender macht.

Die oben genannten fünf Szenarien zeigen spezifische Risiken im Bereich der Krypto-Assets, doch es ist wichtig zu erkennen, dass Sicherheitsprobleme in der Lieferkette keineswegs eine Besonderheit in diesem Bereich sind. Solche Angriffe sind auch in der konventionellen Technologiebranche weit verbreitet. Ein bekanntes Beispiel ist der SolarWinds-Fall, in dem Angreifer Update-Kanäle manipulierten, um Hintertüren in offizielle Update-Pakete zu einfügen; im Codecov-Fall manipulierten Angreifer offizielle Upload-Tools, um sensible Umgebungsvariablen aus kontinuierlichen Integrationsumgebungen zu stehlen; im CCleaner-Fall wurde bösartiger Code in legale Software-Updates integriert. Diese Sicherheitsvorfälle in bekannten Unternehmen zeigen, dass Angreifer dazu neigen, die schwächsten Stellen wie offizielle Updates, reguläre Downloadkanäle und signierte Installationspakete zu ins Visier zu nehmen.

OneKey-Verifikationssystem und Betriebsprinzipien

In Anbetracht der oben genannten Bedrohungen betrachtet das OneKey-Systemdesign das Risiko der Lieferkette als ständige Bedrohung und implementiert einen Sicherheitsmechanismus, der auf der Nutzerabhängigen Verifikation basiert:

• Authentizitätsverifizierungsmechanismus für Geräte: Bereitstellung einer Fälschungsprüfung über die OneKey-App, um die Integrität der Hardware nach dem Verlassen der Fabrik sicherzustellen.
• Firmware-Konsistenzprüfung: Unterstützung, die Nutzer bei der Prüfung von Firmware-Verifikationen, um die Konsistenz zwischen Geräte-Firmware und OneKey-Open-Source-Firmware sicherzustellen und Vorbeugung bösartiger Code-Injektionen.
• Open-Source- und Selbstverifikationsprozess: Bereitstellung von Anleitungen zu Prüfsummen und Signaturen, um den Nutzern die Fähigkeit zur eigenständigen Überprüfung von Code und Firmware zu geben und technische Blackboxes zu durchbrechen.
• Externe Sicherheitsüberprüfungen: Regelmäßige Einbeziehung von Drittanbieter-Sicherheitsfirmen wie SlowMist, um Code zu prüfen und die Berichte öffentlich offenzulegen.

Um das Risiko der Lieferkette weiter zu minimieren, sollten die Nutzer im täglichen Betrieb folgende Kernverifikationsprinzipien befolgen:

• Kauf- und Lieferkanäle: Beschränken Sie den Kauf von Geräten nur auf offizielle oder autorisierte Kanäle, und seien Sie bei Geräten aus privaten Verkäufen oder zu außergewöhnlich niedrigen Preisen äußerst vorsichtig. Nach dem Empfang des Geräts sollten physische Anti-Fälschungs-Siegel überprüft werden, diese aber nicht als einziges Echtheitsmerkmal betrachten.
• Initialisierungseinstellungen: Erzeugen und notieren Sie den Wiederherstellungscode unbedingt persönlich auf dem Bildschirm des Hardware-Geräts. Alle vorab gedruckten Wiederherstellungskarten oder Importanforderungen über QR-Codes sollten als Betrug betrachtet werden. Nach Abschluss der Initialisierung sollten sofort Geräteverifizierung und Firmware-Prüfung durchgeführt werden.
• Systemupdate-Routen: Holen Sie Firmware- und Softwareupdates ausschließlich über die offizielle Website oder die offizielle App ein. Klicken Sie nicht auf Links in privaten Nachrichten oder auf Upgrade-Pakete in Gruppen-Nachrichten und lehnen Sie Anfragen auf Downgrades oder Eingaben des Wiederherstellungscodes zur Sicherheitsüberprüfung ab.
• Tägliche Nutzung und Signaturprüfungen: Überprüfen Sie vor der Unterzeichnung irgendeiner Transaktion unbedingt die Zieladresse, die Transaktionssumme, das Netzwerk und die Smart-Contract-Daten auf dem Bildschirm des Hardware-Geräts. Jede unverständliche unbegrenzte Bearbeitung sollte abgelehnt werden. Bei Aufforderungen wegen "Notfällen" oder "Zeitbegrenzter Aktionen" sollte standardmäßig von einem hohen Betrugsrisiko ausgegangen werden.
• Schutz gegen Social Engineering: Geben Sie den Wiederherstellungscode oder die PIN niemals an Dritte weiter. Wenn offizielle Supportansprüche geltend gemacht werden, sollten Benutzer ruhig bleiben und die Richtigkeit eigenständig über die offiziellen Kanäle überprüfen.

OneKey Verifikationssystem

Schlussfolgerung

Hardware-Wallets bieten physische Isolation für private Schlüssel, was die Grundlage für die Sicherheit von Vermögenswerten bildet. Dennoch zeigen wiederholte Sicherheitsvorfälle in der Lieferkette, dass externe physische und soziale Ingenieursrisiken gleichermaßen tödlich sein können. Der Schutz von digitalen Vermögenswerten sollte nicht auf blindem Vertrauen beruhen, sondern auf strengen Gegenprüfungsmechanismen. Die Umsetzung des Grundsatzes "Keine Verifizierung, kein Vertrauen" ist der einzige effektive Weg, um komplizierte Lieferkettenbedrohungen zu begegnen.

Referenzlinks

[1] Kaspersky - Analyse eines gefälschten Trezor-Hardware-Wallets: https://usa.kaspersky.com/blog/fake-trezor-hardware-crypto-wallet/28299/

[2] Ledger - Sicherheitsvorfallbericht (Connect Kit Abhängigkeitsvergiftung): https://www.ledger.com/blog/security-incident-report

[3] Ledger - Update zum Vorfall mit dem Benutzer-Datenschutz: https://www.ledger.com/blog/update-efforts-to-protect-your-data-and-prosecute-the-scammers

[4] Cointelegraph - Bericht über den Ledger-Drittanbieter-E-Commerce-Datenleak: https://cointelegraph.com/news/ledger-data-incident-global-e-not-platform-breach