Durchbrechen des Ledger-Sicherheitsmodells

In diesem Beitrag werde ich eine Schwachstelle besprechen, die ich in Ledger-Hardware-Geldbörsen entdeckt habe. Die Verwundbarkeit entstand durch die Verwendung einer benutzerdefinierten Architektur, um viele der Einschränkungen ihres Secure Elements zu umgehen.

Ein Angreifer kann diese Sicherheitsanfälligkeit ausnutzen, um das Gerät zu kompromittieren, bevor der Benutzer es erhält, oder um private Schlüssel von dem Gerät physisch oder in einigen Szenarien aus der Ferne zu stehlen.

Physischer Zugang vor dem Aufstellen des Saatgutes

Auch bekannt als “Supply-Chain-Angriff”, ist dies der Schwerpunkt dieses Artikels. Es erfordert weder Malware auf dem Zielrechner noch die Bestätigung von Transaktionen durch den Benutzer. Trotz anderer Behauptungen habe ich diesen Angriff auf ein echtes Ledger Nano S demonstriert. Außerdem habe ich den Quellcode vor einigen Monaten an Ledger geschickt, damit sie ihn reproduzieren konnten.

Wie Sie dem Video oben entnehmen können, ist es trivial, einen Supply-Chain-Angriff durchzuführen, der den erzeugten Recovery-Seed modifiziert. Da alle privaten Schlüssel aus dem Recovery Seed stammen, kann der Angreifer alle auf das Gerät geladenen Gelder stehlen.

Physischer Zugriff nach dem Setup

Dies wird gemeinhin als “Evil Maid Attacke” bezeichnet. Dieser Angriff würde es Ihnen ermöglichen, die PIN, den Wiederherstellungs-Samen und alle verwendeten BIP-39-Passphrasen zu extrahieren, vorausgesetzt, das Gerät wird mindestens einmal nach dem Angriff verwendet.

Dies erfordert nach wie vor weder Malware auf dem Computer noch die Bestätigung von Transaktionen durch den Benutzer. Ein Angreifer muss lediglich eine eigene MCU-Firmware installieren, die die privaten Schlüssel ohne das Wissen des Benutzers ausfiltern kann, wenn er sie das nächste Mal benutzt.

Malware (mit einem Hauch von Social Engineering)

Dieser Angriff würde eine Aktualisierung der MCU-Firmware auf einem infizierten Computer erfordern. Dies kann durch eine Fehlermeldung erreicht werden, die den Benutzer auffordert, das Gerät bei gedrückter linker Taste wieder anzuschließen (um in den MCU-Bootloader zu gelangen). Dann kann die Malware die MCU mit bösartigem Code aktualisieren, so dass die Malware die Kontrolle über die vertrauenswürdigen Anzeige- und Bestätigungstasten auf dem Gerät übernehmen kann.

Dieser Angriff wird unglaublich lukrativ, wenn ein legitimes Firmware-Update veröffentlicht wird, wie es vor zwei Wochen der Fall war.
Proof of Concept

Wer den Spaß am Selbstbau verpassen möchte, findet meinen Proof-of-Concept auf GitHub.

Wenn Sie den Anweisungen dort folgen und es auf einem Ledger Nano S mit Firmware 1.3.1 oder niedriger installieren, können Sie den Angriff im obigen Video nachvollziehen. Da dies jedoch nur zu pädagogischen Zwecken geschieht, habe ich den Angriff absichtlich etwas weniger zuverlässig gemacht.
Hinweis zur verantwortungsvollen Offenlegung

Bevor ich auf die Einzelheiten der Schwachstelle eingehe, möchte ich klarstellen, dass mir von Ledger kein Kopfgeld gezahlt wurde, weil mich die verantwortliche Offenlegungsvereinbarung daran gehindert hätte, diesen technischen Bericht zu veröffentlichen.

Ich habe mich dafür entschieden, diesen Bericht zu veröffentlichen, anstatt ein Kopfgeld von Ledger zu erhalten, hauptsächlich weil Eric Larchevêque, CEO von Ledger, einige Kommentare zu Reddit abgegeben hat, die mit technischen Ungenauigkeiten behaftet waren. Infolgedessen war ich besorgt, dass diese Schwachstelle den Kunden nicht richtig erklärt werden könnte.

Ich bespreche meine Interaktionen mit Ledger am Ende des Artikels.
Hintergrund zu Hardware-Geldbörsen

Krypto-Währungen, wie z.B. Bitcoin, verwenden Public-Key-Kryptographie, um Gelder zu schützen. Sie können das Geld nur ausgeben, wenn Sie den privaten Schlüssel haben.

Dadurch entsteht für den Benutzer ein Problem, wie er seinen privaten Schlüssel sichern soll. Menschen sind notorisch schrecklich im Sichern von Geheimnissen und Geräten; selbst Sicherheitsexperten sind nicht unfehlbar.

Um dieses Problem zu lösen, wurde eine Geräteklasse namens “Hardware Wallets” erfunden. Wie der Name schon sagt, sind dies Hardware-Geräte, die die privaten Schlüssel der Benutzer zum Schutz vor Malware speichern. Viele dieser Geräte werden über einen USB-Anschluss an einen PC angeschlossen, geben aber die privaten Schlüssel zum PC nicht preis, ähnlich einem Hardware-Sicherheitsmodul (HSM).

Der Erwerb der privaten Schlüssel ist jedoch nicht die einzige Möglichkeit, wie ein Angreifer Ihren geliebten Bitcoin stehlen kann. Ein Angreifer, der ein solches Gerät kompromittiert, könnte einfach den Empfänger der Transaktion und den auszugebenden Betrag ändern! Wenn dies heimlich geschieht, werden sich viele Benutzer dieses Angriffs nicht bewusst sein, bis es viel zu spät ist, um das Geld wiederzuerlangen.

Daher benötigt jede nutzbare Hardwaretasche wirklich die folgenden Eigenschaften, die sie von einem dummen HSM unterscheiden

Eine vertrauenswürdige Anzeige zur visuellen Überprüfung der Transaktionsinformationen
Schaltflächen auf dem Gerät, um Signaturvorgänge zu bestätigen oder abzulehnen.

Hardware-Geldbörsen müssen vor einer Vielzahl von Angriffen schützen, darunter:

Remote-Angriffe (wenn ein Angreifer Ihre privaten Schlüssel durch Malware auf Ihrem Computer stehlen kann)
Supply-Chain-Angriffe (wenn ein Angreifer das Gerät ändern kann, um Bad Things™ zu tun, bevor Sie es erhalten)
Unbefugter physischer Zugriff (wenn ein Angreifer das Gerät gefährden kann, wenn er physischen Zugriff erhält)

Wir können den letzten Angriffsvektor weiter in zwei Typen unterteilen: Diebstahl und “Böse Jungfrau-Angriffe”. Wenn ein Angreifer das Gerät stehlen kann, hat er eine längere Zeitspanne für einen Angriff und möglicherweise Zugriff auf teure Laborgeräte. Sie können jedoch dadurch vereitelt werden, dass Sie feststellen, dass Ihr Gerät fehlt und Ihr Geld auf neue private Schlüssel übertragen wird.

Sicherheitsfunktionen, wie z.B. Nötigungspassphrasen, die nicht auf dem Gerät gespeichert sind, können den Angreifer daran hindern, Ihr Geld in diesem Szenario zu stehlen, da das Gerät einfach nicht die notwendigen Informationen enthält, um die privaten Schlüssel wiederherzustellen.

Andererseits hat der Angreifer bei einem “Evil Maid-Angriff” möglicherweise nur eine begrenzte Zeit, um den Angriff durchzuführen, und es steht ihm kein teures Labor zur Verfügung. Diese Angriffe können aufgrund der Vielzahl von Szenarien, in denen sie eingesetzt werden können, weitaus gefährlicher sein:

Wie der Name schon sagt, könnte eine “böse Magd” Ihr Gerät kompromittieren, während sie Ihr Hotelzimmer reinigt.
Ihr Gerät könnte für kurze Zeit von Ihnen genommen werden, während Sie durch die Sicherheitskontrolle des Flughafens gehen.
Sie können Ihr Gerät einem Verwandten oder Anwalt anvertrauen.

Bei dieser Offenlegung werden wir uns vor allem auf den Fall von Supply-Chain-Angriffen konzentrieren. Das heißt: ob Sie Ihrer Hardwaretasche vertrauen können oder nicht, wenn Sie sie von einem Wiederverkäufer oder Dritten kaufen. Aber, wie ich am Anfang dieses Artikels kurz erläutere, können die hier beschriebenen Methoden auf die beiden anderen Angriffsvektoren angewendet werden.
Die Architektur durchbrechen

Im September 2014 veröffentlichte Ledger den HW.1. Diese Brieftasche basiert auf der ST23YT66, einer Smartcard mit USB-Unterstützung. Leider hatte dieses Design gravierende Einschränkungen: Es gab keine vertrauenswürdige Anzeige oder Schaltflächen. Das machte die Brieftasche gefährlich.

Fast forward to July 2016: Ledger kündigte ein neues Gerät namens Nano S an. Basierend auf dem ST31H320 Secure Element enthält das neue Produkt Bestätigungstasten und ein vertrauenswürdiges Display sowie eine USB-Verbindung.

Im November 2017 beschloss ich, die Sicherheit des Nano S unter die Lupe zu nehmen.

Obwohl ich keine Zeit hatte, einen Blick auf das neuere Ledger Blue zu werfen, funktioniert es identisch mit dem Nano S. Zum Zeitpunkt des Schreibens wurde kein Firmware-Update veröffentlicht, um die Schwachstelle im Ledger Blue zu beheben.

Dual-Chip-Architektur

Obwohl es für den ST31H320 kein öffentliches Datenblatt gibt, zeigt ein kurzer Blick auf das Datenblatt, dass dieses Secure Element keine Displays unterstützt! Tatsächlich unterstützt es nicht einmal USB. Die einzige Schnittstelle, die es unterstützt, ist ein UART mit niedrigem Durchsatz.

“Was für eine Art von Hexerei ist das?””, höre ich dich weinen.

Zufällig hat Ledger eine neue Architektur entwickelt, um dieses Problem zu lösen. Der Nano S fügt einen zweiten, nicht sicheren Mikrocontroller (STM32F042K6) hinzu, der als Proxy für das Secure Element fungiert. Dieser Prozessor steuert das Display, die Tasten und die USB-Schnittstelle. Es ist mit dem Secure Element verbunden, das die eigentlichen privaten Schlüssel speichert.

Ab diesem Zeitpunkt wird das ST31 Secure Element als SE und der STM32-Mikrocontroller als MCU bezeichnet. Ein Diagramm der Architektur sieht so aus:

TL;DR: Die SE kann nur direkt mit der MCU kommunizieren. Die MCU kann jedoch im Auftrag der SE mit Peripheriegeräten kommunizieren.

Ein wichtiges Merkmal des Secure Elements ist, dass wir kryptographische Bescheinigungen durchführen können, um festzustellen, ob es sich um eine echte Ledger-Firmware handelt. Dies ist eigentlich ein Verkaufsargument des Ledger-Designs: Tatsächlich argumentiert Ledger, dass dieses Sicherheitsmerkmal so mächtig ist, dass Ledger-Brieftaschen keine manipulationssichere Verpackung benötigen (archive.is / archive.org), wie in der Broschüre beschrieben, die mit allen Geräten geliefert wird.

Der CTO von Ledger geht sogar so weit, den Benutzern zu sagen, dass es völlig sicher ist, bei eBay zu kaufen (archive.is / archive.org).

Damit kommen wir zum Kernproblem. Während die Software auf der SE attestiert werden kann, ist die MCU ein nicht sicherer Chip und (wie wir unten zeigen) kann ihre Firmware durch einen Angreifer ersetzt werden.

Und hier liegt das Problem: Um die Sicherheitsgarantien von Ledger zu erreichen, muss die Vertrauenskette in der SE verankert werden. Dies bedeutet, dass die SE die Firmware auf der MCU überprüfen muss.
Hardware-Manipulation

Obwohl ich mich in diesem Artikel auf die Manipulation von Software konzentrieren werde, ist es wichtig zu beachten, dass Sie das Gerät durch Manipulationen an der Hardware kompromittieren können, wenn es keine Software-Schwachstelle gibt.

Es ist unglaublich wichtig zu beachten, dass Sie die physische Hardware vollständig überprüfen müssen, damit diese Geräte überhaupt sicher sind.

Da weder die Verpackung noch das eigentliche Gerät manipulationssicher sind, ist es für einen Angreifer trivial, das Gerät zu modifizieren. Ich kann das nicht genug wiederholen: Wenn Sie die physische Hardware nicht überprüfen, ist das Spiel vorbei.

Sie sollten die Hardware auch immer dann überprüfen, wenn jemand unbefugten Zugriff darauf gehabt haben könnte, andernfalls sind Sie anfällig für Angriffe von Evil Maid.

Ledger gibt dazu Anweisungen, aber ich werde zwei Punkte beachten.

Die Bilder sind von unterschiedlicher Qualität. Ledger muss hochauflösende Bilder liefern, die alle Komponenten übersichtlich darstellen.

Die Rückseite des Gerätes wird überhaupt nicht angezeigt!

Es ist wichtig, dass Sie die Rückseite des Gerätes überprüfen, zumal sich hier der JTAG-Header (eine Debugging-Schnittstelle) für die MCU befindet.

Selbst wenn diese beiden Probleme gelöst sind, würde ich mich fragen, wie teuer es ist, eine der MCUs mit zusätzlichem Flash-Speicher, aber identischer Pinbelegung, als STM32F042K6 umzubenennen.

Obwohl es wichtig ist, auf dieses Thema einzugehen, ist für den Angriff, den ich in diesem Artikel beschreiben werde, keine Manipulation der Hardware erforderlich.
Überprüfen der MCU-Firmware

Nehmen wir an, Sie haben die Hardware akribisch überprüft und sie ist definitiv unverändert. Was passiert, wenn der Angreifer einfach die Firmware der MCU ändert?

Ledger berücksichtigte diesen Angriff und um dies zu verhindern, wird die MCU-Firmware von der SE verifiziert.

Aber es stellt sich heraus, dass die Überprüfung der Firmware auf einem nicht sicheren Prozessor nicht so einfach ist. Die SE ist nichts anderes als eine verherrlichte Chipkarte, was bedeutet, dass die einzige Möglichkeit der Kommunikation mit der MCU über einen Low-Throughput UART besteht. Ohne direkten Zugriff auf das RAM oder Flash auf der MCU, wie kann die SE ihre Firmware überprüfen?

Der Ansatz von Ledger bestand darin, dass die SE die MCU auffordert, den gesamten Inhalt ihres Flash-Speichers zu übergeben, wie unten beschrieben.

Auf den ersten Blick erscheint dies problematisch. Grundsätzlich bitten wir eine (möglicherweise kompromittierte) MCU zu beweisen, dass sie mit der offiziellen Ledger-Firmware arbeitet. Aber wenn die MCU kompromittiert ist, was hindert sie daran, anderen Code zu senden – Code, der nicht wirklich läuft? Das ist die Herausforderung, der sich Ledger zu stellen versuchte.

Die von Ledger angewandte Theorie basiert auf der Tatsache, dass die MCU eine relativ begrenzte Menge an Flash hat. Um bösartige Firmware auszuführen, müsste ein Angreifer auch die offizielle Ledger-Firmware speichern, damit sie die SE befriedigen kann. Der Ansatz von Ledger bestand also darin, dies angesichts der Menge an Flash zu erschweren.

Insbesondere durch die Verifizierung des gesamten Flash (und das Füllen leerer Bereiche mit zufälligen Daten) versuchte Ledger, die Speicherung von bösartigem Code auf der MCU zu erschweren und auch die MCU-Verifizierung zu bestehen.

Das ist eine bemerkenswerte Idee, und vielleicht ist es möglich, sie richtig zu machen. Allerdings war ich von dieser Lösung völlig unbeeindruckt.
Angriffsart

Während es einige offensichtliche Methoden gibt, um dieses Design anzugreifen, wie z.B. die Bereitstellung des bösartigen Codes über USB von einem angeschlossenen PC aus, macht es viel mehr Spaß, einen eigenständigen Exploit zu versuchen (z.B. einen, der bei einem Supply-Chain-Angriff eingesetzt werden könnte).

Die von mir gewählte Methode war, den Code zu “komprimieren”. Die Verwendung eines Kompressionsalgorithmus wie DEFLATE oder LZMA wäre aufgrund der Kompromisse zwischen Ausführungszeit, Speicherverbrauch und Codegröße unmöglich. Ein Benutzer könnte es bemerken, wenn es zwanzig Sekunden dauert, um seine Brieftasche zu starten!

Ganz zu schweigen von den vielversprechenden Ergebnissen bei der Komprimierung des gesamten Flash, die nicht nur bei der MCU-Firmware der Fall war – und ich wollte den MCU-Bootloader, der auch im Flash vorhanden ist, nicht ersetzen. Dies liegt daran, dass es zwei Methoden gibt, um neue Firmware auf dem Gerät zu installieren:

Mit dem JTAG, einer Debugging-Schnittstelle, die von Embedded-Firmware-Entwicklern unter anderem zum Hochladen neuer Firmware verwendet wird.

Mit dem Bootloader, der von Ledger-Benutzern zum Installieren von Firmware-Updates verwendet wird. Das von Ledger zur Verfügung gestellte Python-Tool finden Sie auf GitHub.

Ich habe diese Methode benutzt, weil ich es nicht mag, Dinge zu löten. Wenn ich beim Flashen des neuen Bootloaders einen Fehler gemacht habe, würde diese Methode nicht mehr funktionieren und das Gerät würde gebrannt, wenn ich nicht die JTAG-Schnittstelle verwendet hätte.

Daher ist der Austausch des Bootloaders keine Option und wir müssen eine Komprimierung ausschließen.

Aber es gibt einen anderen Ansatz. Wenn Sie ein C-Programm kompilieren, wird die Toolchain (die Software-Suite, die Programme kompiliert) eine Reihe von Zaubertricks ausführen, damit alles funktioniert. Zum Beispiel haben viele Prozessoren keine Anweisungen, um sehr große Zahlen zu teilen. Der Compiler umgeht dies, indem er eine Software-Implementierung der Division-Operation einfügt. Ein weiteres Beispiel ist die Deklaration von Initialwerten für in Funktionen definierte Variablen. Wenn die Funktion aufgerufen wird, fügt der Compiler am Anfang zusätzlichen Code ein, um diese Daten auf den Stack zu kopieren.

Die zusätzlichen Funktionen, die der Compiler zur Ausführung dieser Aufgaben einfügt, werden “Compiler Intrinsics” genannt. Da die MCU sowohl über einen Bootloader als auch über eine Firmware verfügt und es sich dabei um völlig getrennte Programme handelt, erscheinen diese Intrinsics zweimal auf dem Flash (einmal in jedem Programm).

Das Ergebnis ist, dass wir unsere bösartigen Routinen anstelle einer redundanten Kopie der Compiler-Intriniscs-Routinen (insbesondere der Kopie in der Firmware) einfügen können. Damit haben wir eine intakte Kopie dieses Codes im Bootloader.

Da der Bootloader mit der Firmware identisch ist, können wir, wenn die SE die MCU nach ihrem Flash-Inhalt fragt, ein korrektes Image “zusammensetzen”, indem wir den bösartigen Code herausschneiden und ihm stattdessen den Code vom Bootloader senden. Wenn die Firmware das Intrinsic verwenden muss, können wir stattdessen zum Intrinsic im Bootloader springen.

Wenn Sie zu Hause mitspielen, können Sie, nachdem Sie den Bootloader und die Firmware aus dem Quellcode erstellt haben, mit diesem Befehl nach Symbolen suchen.

nm -S –size-sort -t d bin/token | grep -i ” t ” t

Dieser Befehl gab mir einige interessante Symbole, die sowohl im Bootloader als auch in der Firmware identisch waren. Kein Wunder, alle drei sind Compiler-Intrinsics.

134228637 00000124 T memcpy
134228761 00000140 T Memset
134228357 00000266 T __udivsi3

Um den bösartigen Code, den wir versteckt haben, tatsächlich nutzen zu können, müssen wir andere Funktionen einbinden. Wir tun dies, indem wir Zweige zu unserer Nutzlast in die Funktionen einfügen, die wir anvisieren wollen. Wir müssen die Funktion, die den Flash-Inhalt an die SE sendet, anhängen, um die Bootloader-Funktion anstelle unseres bösartigen Codes zu senden.

Ich habe mich auch dafür entschieden, die Funktion, die auf den Bildschirm zeichnet, anzuschließen. Dies ermöglicht uns eine Vielzahl von lustigen und spannenden Tricks. Von der Änderung der angezeigten Bitcoin-Adressen und Keylogging-PINs bis hin zu, wie ich gleich erklären werde, dem Backdooring der privaten Schlüsselgenerierung ist alles erlaubt!

Mit diesen beiden Hooks und __udivsi3 als Angriffsvektor sieht unser Exploit ein wenig so aus.

Dieser Ansatz setzt unglaubliche 258 Bytes Nutzlast frei! Nun, wir werden definitiv auf die Größe optimieren müssen, auch wenn wir memcpy und memset in den Mix werfen.
Einen Exploit machen

Unsere Nutzlast benötigt zwei Komponenten:

Code zum Ändern des an die SE gesendeten Flash-Inhalts, um den Verifizierungsvorgang zu tricksen.
Ein Angriff wie ein Keylogger oder eine Hintertür zur Schlüsselerzeugung

Ich weiß nicht, wie es dir geht, aber Hintertüren scheinen mir mehr Spaß zu machen.

Unser Exploit erlaubt es uns nicht, die SE zu kompromittieren, also wie können wir eine Hintertür hinzufügen?

Die SE-Firmware von Ledger verfügt über eine Benutzeroberfläche, die für das Dashboard (und die Einstellungen) zuständig ist. Es wird aber auch für den Onboarding-Prozess verwendet (wo das Recovery-Saatgut erzeugt wird).

Wenn wir die Benutzeroberfläche modifizieren können, können wir den Recovery-Seed ändern, der während des Onboarding-Prozesses erzeugt wird. Dies ist recht einfach, da die Benutzeroberfläche Open Source ist und Ledger es Ihnen (per Design!) erlaubt, eine modifizierte UX-Anwendung zu installieren.

Unter normalen Umständen würde das Gerät eine Warnung anzeigen, dass die “Benutzeroberfläche nicht echt ist”, was für jeden aufmerksamen Benutzer eine rote Flagge wäre.

Aber daran erinnern, dass ich versprochen, dass ich erklären würde, wie die Steuerung des Displays kann Backdoor der Schlüssel Generation? Der Grund für diesen Angriff ist, dass wir die nicht echte UX-Warnung einfach ausblenden können.

Für diese Demonstration werden wir nichts Raffiniertes tun, was ein echter Angreifer tun würde, wie z.B. einen zufällig aussehenden, aber völlig vorhersehbaren Recovery-Samen zu erzeugen.

Wir werden etwas viel Offensichtlicheres tun.

diff –git a/src/bolos_ux_onboarding_3_new.c b/src/bolos_ux_onboarding_3_new.c
index ce1849c..b950ae7 100644
a/src/bolos_ux_onboarding_3_new.c
b/src/bolos_ux_onboarding_3_new.c
@@ -395,7 +395,7 @@ void screen_onboarding_3_new_init(void) {
#else

G_bolos_ux_context.onboarding_kind = BOLOS_UX_ONBOARDING_NEW_24;
cx_rng((unsigned char *)G_bolos_ux_context.string_buffer, 32);
os_memset(G_bolos_ux_context.string_buffer, 0, 32);
G_bolos_ux_context.words_buffer_length = bolos_ux_mnemonic_from_data(
(unsigned char *)G_bolos_ux_context.string_buffer, 32,
(unsigned char *)G_bolos_ux_context.words_buffer,

Wenn Sie mit C gut vertraut sind, werden Sie feststellen, dass ich einen Syscall zum Zufallszahlengenerator durch einen Funktionsaufruf ersetze, der die gesamte Entropie auf Null setzt. Wie Sie im Video am Anfang sehen können, erzeugt es einen Recovery Seed, bei dem die ersten 23 Wörter abgebrochen werden (das letzte Wort ist anders, weil es eine Prüfsumme ist).

Da die privaten Schlüssel vom Recovery Seed abgeleitet werden, steuern Sie, wenn Sie den Recovery Seed steuern, alle vom Gerät generierten Bitcoin-Adressen.

Wenn wir alles zusammensetzen, bekommen wir den folgenden Angriff, den ich für sehr ordentlich halte.

Da die SE davon ausgeht, dass die MCU mit echter Firmware arbeitet, ist die Zertifizierung natürlich immer noch erfolgreich. Und, wie ich bereits erwähnte, war keine Manipulation der Hardware erforderlich, was die Sicherheitsintegritätsprüfung von Ledger zunichte macht.

Da der Angreifer das vertrauenswürdige Display und die Hardware-Buttons steuert, ist es erstaunlich schwierig, einen gut geschriebenen Exploit zu erkennen und vom Gerät zu entfernen.
Reparieren des Angriffs

Das Problem mit einer solchen architektonischen Schwachstelle ist, dass es schwierig ist, sie zu beheben, ohne die Architektur zu verändern.

Ledger hat mehrfach versucht, einen Angreifer daran zu hindern, diese Schwachstelle auszunutzen.

Zunächst wurde die MCU-Firmware optimiert und neu angeordnet. Insbesondere ruft die Firmware Funktionen im Bootloader auf, anstatt die Funktionen zu duplizieren. Dies verhindert zwar diesen speziellen Angriffsmodus, aber es ist wichtig, sich bewusst zu sein, dass es andere, “kreativere” Angriffsmethoden gibt, von denen ich weiß, und wahrscheinlich auch einige, die ich nicht kenne.

Zweitens: Die SE fordert die MCU nun auf, den Flash-Inhalt zu senden. Damit soll der Einsatz von Kompressionsalgorithmen verhindert werden. Es soll auch verhindern, dass Code vom Computer über USB geliefert wird. Ich bin mir nicht sicher, wie gut es gelingt, letzteres zu tun, da der Code im RAM gehalten werden kann.

Bemerkenswert ist jedoch, dass die SE mit bis zu 28 MHz und der “Gegner” (die MCU) mit bis zu 80 MHz läuft! Dies wirft die Frage auf, ob ein langsamerer Chip einen schnelleren Chip genau timen kann, um zu verhindern, dass er zusätzliche Dinge tut, besonders angesichts der langsamen UART-Kommunikation.

Ledger weigerte sich, mir einen Freigabekandidaten zu schicken, so dass ich keine Gelegenheit hatte, zu überprüfen, wie gut diese Abschwächungen das Problem lösen. Aber diese werfen eine wichtige Frage auf.

Ist es wirklich möglich, eine Kombination aus Timing und “schwer zu komprimierender” Firmware zu verwenden, um Sicherheit in diesem Modell zu erreichen?

Sichere Systeme mit diesem Modell zu bauen scheint ein unglaublich spannendes Forschungsvorhaben zu sein, und ich denke, es ist interessant zu sehen, wie Unternehmen wie Ledger hier an die Grenzen gehen.
Interaktion mit dem Ledger

Vor der geplanten Offenlegung dieser Schwachstelle hatte ich einige Interaktionen mit dem CEO von Ledger. Auf archive.is und archive.org finden Sie eine archivierte Kopie seines Hauptkommentars, falls dieser aus irgendeinem Grund verschwindet.

In diesen Kommentaren bestreitet der CEO, dass diese Angriffe kritisch sind. Einige der Kommentare von Ledger sind subjektiv, andere eher sachlich. Nachfolgend möchte ich einige dieser Kommentare erläutern.

Die erste Behauptung, die ich ansprechen möchte, ist, dass die Verwundbarkeit eine Reihe von unglaublich unwahrscheinlichen Bedingungen erfordert.

Die von Saleem gemeldete Sicherheitslücke erfordert einen physischen Zugriff auf das Gerät, BEVOR die Installation einer benutzerdefinierten Version der MCU-Firmware, die Installation einer Malware auf dem Computer des Ziels und die Bestätigung einer sehr spezifischen Transaktion.

Ich bin verwirrt, woher diese Behauptung stammen könnte. Aus dem späteren Kontakt mit Ledger wurde mir mitgeteilt, dass der CEO überhaupt nicht über die Sicherheitslücke informiert wurde, als er diese Bemerkungen zu Reddit machte.

Wie ich am Anfang des Artikels sagte, gibt es drei Methoden, um diese Schwachstelle auszunutzen, von denen keine Bedingungen erfordert, die so unwahrscheinlich sind wie diese.

Der bereits erwähnte Malware-Angriffsvektor führt gut zu der nächsten Ausgabe, die ich mit Larchevêques Kommentar habe.

Saleem war sichtlich verärgert, als wir nicht als “kritisches Sicherheitsupdate” kommunizierten und beschlossen, seine Meinung zu diesem Thema zu teilen.

Wenn Sie ein kritisches Sicherheitsproblem beheben, können Sie einen von zwei Wegen wählen.

Verbergen Sie den Sicherheitsfix komplett.

Dies ist eine effektive Methode, um die Aufmerksamkeit von schwarzen Hüten zu vermeiden (wenn Ihr Produkt vollständig geschlossen ist, was bei Ledger der Fall ist).

Dies hat den Nachteil, dass die meisten Benutzer eine Aktualisierung vermeiden, besonders wenn der Prozess sehr schmerzhaft ist (wie in diesem Fall).

Benutzer bei einem kritischen Sicherheitsproblem warnen und ein Update erzwingen

Dies wird häufig für Open-Source-Produkte verwendet oder wenn der Hersteller den Verdacht hat, dass eine Sicherheitslücke in der Wildnis verwendet wird.

Dies hat jedoch den Nachteil, dass es schwarze Hüte auf das Vorhandensein einer Verwundbarkeit hinweist. Daher ist es unerlässlich, dass die Benutzer sofort aktualisieren, um den “First Mover”-Vorteil gegenüber einem potenziellen Angreifer zu erlangen.

Ledger wählte eine fehlerhafte Methode, die die schlimmsten Aspekte dieser beiden Ansätze berücksichtigt. Indem Sie die Aufmerksamkeit auf die Sicherheitskorrekturen in ihrem Firmware-Update lenken, ohne die Benutzer auf ein Update hinzuweisen, verlieren Sie den “First Mover”-Vorteil.

Dies gibt schwarzen Hüten genügend Zeit, um festzustellen, wie die Schwachstelle ausgenutzt werden kann, wodurch alle Benutzer dem Risiko des Malware-Angriffsvektors ausgesetzt sind.

Meine Bedenken erwiesen sich als richtig, da ich von mehreren unabhängigen White Hats kontaktiert wurde, die das Problem ausschließlich anhand der Firmware-Update-Anweisungen von Ledger ermittelt hatten.
Zeitleiste der Offenlegung

11. November 2017: Offiziell gemeldete Sicherheitslücke bei Nicolas Bacca, Ledger CTO. Schwachstelle als unplausibel eingestuft.

14. November 2017: Demonstration eines praktischen Supply-Chain-Angriffs mit modifizierter MCU-Firmware und Benutzeroberfläche. Quellcode an Bacca geschickt.

30.12.2017: Bricked the Ledger Nano S durch Herabstufung der Firmware auf eine nicht unterstützte Version. Drücken Sie F, um Respekt zu zollen.

06. März 2018: Ledger veröffentlicht Firmware-Update für Ledger Nano S.

20. März 2018: Write-up und Proof-of-Concept-Code veröffentlicht.

Firmware-Update für Ledger Blue zum Zeitpunkt des Schreibens unveröffentlicht.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

− 1 = 1