ANZEN-Forschung: Wie wir Keystone über eine USB-Schwachstelle geknackt haben

Sicherheitsupdate (Juli 2026): Das in diesem Artikel behandelte Problem wurde von OneKey Anzen im März 2026 während eines gemeinsamen Sicherheitsaudits mit Keystone entdeckt und betrifft Keystone 3 Pro Firmware, die das USB SDK des MCU-Anbieters integriert. Keystone hat am 1. April 2026 die Firmware v2.4.0 veröffentlicht, die dieses Problem vollständig behebt; bis zum Zeitpunkt der gemeinsamen Bekanntmachung haben beide Seiten keine Beweise dafür gefunden, dass diese Schwachstelle für Angriffe auf Keystone-Benutzer ausgenutzt wurde. Eine erfolgreiche Ausnutzung erfordert, dass ein Angreifer gleichzeitig physischen Besitz des Geräts hat, die korrekte PIN kennt, das Gerät entsperrt, die Genehmigung des Benutzers für die USB-Verbindung erhält und das Gerät mit einem vom Angreifer kontrollierten Computer verbindet. Benutzer, die eine Firmware unter v2.4.0 ausführen, sollten unverzüglich auf die neueste Version aktualisieren; die Verwendung von QR-Signaturen über Air-Gap kann diesen spezifischen USB-Angriffspfad vermeiden, das Durchführen des Upgrades wird jedoch weiterhin empfohlen. Ausführliche Informationen finden Sie unter Gemeinsames Sicherheitsupdate von Keystone und OneKey Anzen.

Anfang August fand die Black Hat USA 2026 in Las Vegas statt; aufgrund von Visaproblemen wurde unser Vortrag in ein On-Demand-Format umgewandelt. Dieser Vortrag basierte auf einem Audit der Keystone-Wallet, bei dem wir schwerwiegende Probleme im USB SDK des Chipherstellers entdeckten und letztlich die Mnemonics extrahieren konnten.

Tatsächlich ist es keineswegs das erste Mal, dass Probleme im USB-Protokoll-Stack auftreten. In den letzten zehn Jahren standen zahllose schwerwiegende Angriffe auf Geräte mit dem USB-Protokoll-Stack in Verbindung – von USB-Treiberschwachstellen und Remote-Redirection im Jahr 2014 über Fusée Gelée, checkm8 und Kamakiri bis hin zum 2026 veröffentlichten usbliter8.

Häufung von Schwachstellen in USB-Protokollen

2014: Erfordern USB-Schwachstellen wirklich physischen Zugriff?

2014 veröffentlichte die NCC Group auf der Black Hat Asia den Vortrag „USB Attacks Need Physical Access Right? Not Any More...“.

Damals wurden USB-Schwachstellen meist als „lokale physische Angriffe“ eingestuft: Ein Angreifer musste ein bösartiges Gerät an die Zielmaschine anschließen, um über fehlerhafte Descriptoren oder class-spezifische Daten eine Treiberlücke auszulösen.

In diesem Vortrag nutzten die Forscher jedoch die RemoteFX-USB-Redirection, um Low-Level-USB-Geräte auf einen entfernten Windows Server umzuleiten. Das bösartige USB-Gerät war physisch mit dem Client des Angreifers verbunden, doch der Treiber, der die bösartigen USB-Daten tatsächlich parste, lief auf dem Remote-Server.

2018, Fusée Gelée: Die Anfragelänge als Objektlänge interpretiert

Das 2018 veröffentlichte Fusée Gelée ist einer der klassischsten Fälle von USB-BootROM-Schwachstellen. Die Lücke befand sich im Recovery Mode (RCM) von NVIDIA Tegra. Das Gerät initialisierte den USB-Stack in einer extrem frühen BootROM-Umgebung und wartete darauf, dass der Host ein Recovery-Image hochlud. Die Schwachstelle trat bei einer scheinbar gewöhnlichen GET_STATUS-Control-Anforderung auf.

Gemäß der USB-Semantik ist ein status-Objekt nur 2 Bytes groß. Der Host gibt über wLength an, wie viele Daten er maximal empfangen möchte, und das Gerät sollte min(Host-Anfragelänge, tatsächlich verfügbare Datenlänge) zurückgeben.

Doch bei der Verarbeitung des Endpoint-Recipients führte das BootROM fälschlicherweise eine Logik wie die folgende aus:

status = get_usb_endpoint_status(index);

/* Fehler: Verwendung der vom Host angegebenen Anfragelänge */
size_to_tx = setup_packet.length;

memcpy(dma_buffer, &status, size_to_tx);

Das bedeutet, dass die tatsächliche Länge des 2-Byte-Objekts ignoriert wurde und stattdessen das vom Angreifer kontrollierte wLength direkt als Länge für memcpy diente – theoretisch bis zu 65.535 Bytes.

Darüber hinaus erlaubte RCM dem Angreifer bereits vor der Signaturüberprüfung, eine größere Payload im Speicher abzulegen; dieser Payload-Bereich lag zufällig nahe am aktiven Stack des BootROM. Durch gezielte Auswahl des DMA-Puffers und Strukturierung des Speicherlayouts konnte die Out-of-Bounds-Kopie schließlich vom Angreifer kontrollierte Daten auf den Ausführungs-Stack schreiben.

Zudem verfügte die damalige BootROM-Umgebung weder über gängige Stack-Canaries noch über ASLR oder wirksamen Speicherausführungsschutz. Das Endergebnis: Bevor Sicherheitsverriegelungen oder Rechteeinschränkungen griffen, hatte der Angreifer bereits beliebige Codeausführung im BootROM-Kontext erlangt.

Dies weist direkte Parallelen zu der später in diesem Artikel behandelten Hardware-Wallet-Schwachstelle auf.

2019, checkm8: Angreifer kontrollieren nicht nur Daten, sondern auch das „Unvollendete“

Das 2019 veröffentlichte checkm8 ist einer der folgenschwersten Fälle von Apple-SecureROM-Schwachstellen. Es betraf mehrere Generationen von iOS-Geräten und ermöglichte es Angreifern, im DFU-Modus Codeausführung im BootROM-Kontext zu erlangen, um anschließend das SecureROM zu dumpen, Firmware-Keybags zu entschlüsseln oder das Gerät in einen Demotion-Status zu versetzen, der JTAG erlaubt. Da sich die Schwachstelle im bei der Chipherstellung fest eingebrannten BootROM befand, konnte sie bei bereits ausgelieferten Geräten nicht durch iOS-Updates behoben werden.

Anders als Fusée Gelée war checkm8 kein einfacher Längenprüfungsfehler. Der Kern lag in einem Use-After-Free innerhalb der Apple-DFU-USB-State-Machine: Eine USB-Datenphase wurde nicht ordnungsgemäß beendet, weshalb globale Variablen zur Speicherung des Datenphasenstatus nicht bereinigt wurden; der zugrunde liegende DFU-Puffer wurde jedoch beim Beenden des USB-Stacks freigegeben.

Unter normalen Umständen speichert das BootROM nach Erhalt einer DFU_DNLOAD-Anforderung mit DATA-Phase den Empfangspuffer und wLength. Nach vollständigem Datenempfang leert der Completion-Callback diese Zustände; beim Verlassen des DFU-Modus wird der entsprechende I/O-Puffer freigegeben.

DFU_DNLOAD(setup)
{
    ep0_buffer    = dfu_io_buffer;
    ep0_remaining = setup.wLength;
}

DATA_complete()
{
    ep0_buffer    = NULL;
    ep0_remaining = 0;
}

DFU_exit()
{
    free(dfu_io_buffer);
}

checkm8 nutzte genau die Lücke zwischen diesen Schritten aus: Der Angreifer initiiert zunächst eine Anforderung mit DATA-Phase, sodass das BootROM den Pufferzeiger und die verbleibende Länge speichert, und sendet die Daten dann absichtlich nicht vollständig. Durch Abbruch der Übertragung oder Erzeugen eines Timeouts wird der DATA-Completion-Callback nicht ausgeführt; anschließend wird ein DFU-Zustandswechsel oder ein USB-Reset ausgelöst, wodurch der USB-Stack beendet und der ursprüngliche Puffer freigegeben wird.

Zu diesem Zeitpunkt ist der Speicher bereits freigegeben, im Empfangsstatus verbleibt jedoch der alte Zeiger:

free(dfu_io_buffer);
ep0_buffer = old_dfu_io_buffer;  // Dangling-Pointer

Als Nächstes musste das Heap-Layout vorbereitet werden. Öffentliche Exploits leaken eine Reihe von USB-Request-Objekten, um nachfolgende Allokationspositionen zu verändern, sodass neue DFU-Puffer an anderer Stelle platziert werden, während die alte Adresse von Objekten wie usb_device_io_request wiederbelegt wird.

Sendet man danach erneut USB-Daten, schreibt das BootROM weiterhin über den verbliebenen ep0_buffer, wodurch in Wirklichkeit das neue Objekt überschrieben wird. Der Exploit modifiziert Felder wie callback und next, um die Callback-Adresse auf die zuvor platzierte Payload zu richten. Sobald die nächste USB-Anforderung abgeschlossen ist, springt das SecureROM in den Code des Angreifers.

2020, Kamakiri: Wie eine USB-Anforderung zu einem indirekten Sprung wird

Kamakiri zielte auf den BootROM-Download-Modus einer Reihe von MediaTek-SoCs ab. Es ermöglichte Angreifern, den Authentifizierungspfad zu umgehen, der eigentlich unautorisierte Download Agents blockieren sollte, und eine unsignierte First-Stage-Payload im BootROM-Kontext auszuführen. Mit dieser Ausführungsfähigkeit konnten nachfolgende Payloads auf den Flash-Speicher zugreifen, Speicher dumpen, den Boot-Status modifizieren oder zuvor nicht mehr bootfähige Geräte wiederherstellen.

Die Exploit-Kette von Kamakiri war sehr kurz, da das MediaTek-BootROM bereits die erste vom Angreifer benötigte Fähigkeit bereitstellte: das Hochladen von Daten in einen bekannten SRAM-Bereich über das Download-Protokoll. Der Angreifer platzierte die First-Stage-Payload dort und triggerte die Schwachstelle über eine spezielle USB-Control-Anforderung.

Die Schwachstelle lag genau im Dispatch-Handling von USB-Control-Anforderungen. Unabhängige Reverse-Engineering-Analysen fassten die Logik in etwa so zusammen:

handler = handler_array[value * 13];
handler();

Das Kernproblem lag darin, dass der Selektorwert aus der USB-Anforderung ohne ausreichende Bereichsprüfung zur Indizierung einer Funktionszeigertabelle verwendet wurde. Solange der Angreifer einen geeigneten Kontrollwert fand, sodass der Tabelleneintrag auf die Adresse der zuvor hochgeladenen SRAM-Payload verwies, konnte eine USB-Anforderung in einen indirekten Aufruf der Payload verwandelt werden. Da sich die BootROM-Layouts verschiedener SoCs geringfügig unterscheiden, mussten der genaue Indexwert und die Payload-Adresse eventuell angepasst oder enumeriert werden.

Der öffentliche PoC sendete nach dem Hochladen von Stage 1 folgenden Control-Transfer:

ctrl_transfer(
    0xA1,   # class request, device-to-host, interface recipient
    0,
    0,
    10,     # wIndex
    0
)

2026, usbliter8: Der USB-Controller verschiebt den DMA-Schreibzeiger vor den Puffer

Das im Juni 2026 veröffentlichte usbliter8 erweiterte softwareseitig nicht patchbare BootROM-Exploits erneut auf Apples A12-, A13- sowie S4- und S5-SoCs.

Bei erfolgreicher Ausnutzung können Angreifer Code im EL1-Kontext des SecureROM ausführen, das DFU-Verhalten modifizieren, den Production-Mode des Chips temporär demoten oder Signaturprüfungen umgehen, um ein unsigniertes Original-iBoot zu starten. Dies bedeutet auch, dass die Boot-Vertrauenskette des Anwendungsprozessors gebrochen wurde – irreparabel durch nachfolgende iOS-Updates.

usbliter8 unterscheidet sich von den vorherigen Fällen: Es nutzt primär die DMA-Zeigersemantik des Synopsys-DWC2-USB-Controllers bei der Verarbeitung von SETUP-Transaktionen aus.

Gemäß USB-Protokoll ist der Datenteil einer SETUP-Transaktion fest auf 8 Bytes festgelegt. Der DWC2-Controller erlaubt den fortlaufenden Empfang von drei SETUP-Paketen und schreibt diese sequenziell via DMA in den Speicher. Drei reguläre SETUP-Pakete belegen zusammen 24 Bytes. Trifft die vierte SETUP-Transaktion ein, subtrahiert der Controller fix 24 Bytes vom DOEPDMA-Schreibzeiger, um die Adresse an den Anfang dieser Gruppe von SETUP-Puffern zurückzusetzen. Bei regulären 8-Byte-SETUP-Paketen geht diese Logik exakt auf.

Der Controller akzeptiert jedoch auch anomale SETUP-Daten von weniger als 8 Bytes und rückt den DMA-Zeiger um die tatsächlich geschriebene Länge vor; die interne Schreibgranularität beträgt 4 Bytes. Sendet ein Angreifer wiederholt 4-Byte-Short-Packets, verschieben die ersten drei Pakete die Adresse insgesamt nur um 12 Bytes nach vorne. Trifft das vierte Paket ein, springt der Controller dennoch starr um 24 Bytes zurück. Folglich werden die SETUP-Daten der nächsten Runde nicht mehr in den ursprünglichen Puffer geschrieben, sondern 12 Bytes vor dessen Anfang. Wiederholt man diesen Vorgang kontinuierlich, wandert die DMA-Schreibposition in vorhersagbaren Schritten zu niedrigeren Adressen, was letztlich zu einem stabilen Buffer-Underflow führt.

Normalerweise kann ein Out-of-Bounds-DMA des USB-Controllers nicht zwangsläufig beliebigen Systemspeicher korrumpieren. Moderne SoCs beschränken den Adressbereich, auf den ein USB-Controller zugreifen darf, üblicherweise über eine IOMMU. In der SecureROM-Umgebung von A12 und A13 befindet sich das USB-DART jedoch im Bypass-Zustand, sodass dem Controller-DMA eine wirksame Adressisolation fehlt. Dadurch bleibt der Underflow nicht auf einen engen SETUP-Puffer beschränkt, sondern kann weitere SRAM-Objekte überschreiben.

Auf dem A12 grenzt der USB-DMA-Puffer an den Stack des USB-Tasks; der Exploit kann das gespeicherte Link-Register überschreiben und beim Task-Switch die Kontrolle über den Programmzähler (PC) übernehmen. Das A13 führte Pointer Authentication ein, weshalb das direkte Überschreiben der Rücksprungadresse nicht mehr funktionierte; öffentliche Exploits nutzten daher eine komplexere Speicherkorruptionskette, um schließlich den Zeiger auf den USB-Interrupt-Handler im BSS zu überschreiben, sodass der nächste USB-Interrupt in den Code des Angreifers springt. Beide Pfade führen letztlich zur SecureROM-EL1-Ausführung.

Vom USB-Out-of-Bounds-Zugriff zur beliebigen Codeausführung

Die Ursache der auf der Black Hat USA vorgestellten Schwachstelle lag ebenfalls im USB SDK.

Line-Coding-Anforderungen in CDC erfordern lediglich eine sehr kleine, feste Struktur. Das integrierte USB SDK stellte dafür jedoch ein festes 8-Byte-CmdBuff bereit und übergab das vom Host bereitgestellte req->wLength direkt an die zugrunde liegenden Sende- oder Empfangsfunktionen. Der Code führte weder eine Längenprüfung durch noch forderte er, dass die Länge der protokollarisch festgelegten festen Länge entsprach. Dies führte zu Out-of-Bounds-Lese- und -Schreibzugriffen.

Code der USB-SDK-Out-of-Bounds-Schwachstelle

Natürlich ist der Out-of-Bounds-Lese-/Schreibzugriff nur der erste Schritt – damit hat man lediglich ein Speicherkorruptionsprimitiv erlangt; das eigentliche Ziel war beliebige Codeausführung.

Da die Schwachstelle im USB-CDC-Pfad auftrat, prüfte ich zunächst den USB-Protokoll-Stack entlang des Dispatch-Ablaufs der aktuellen Anforderung. Bei der Analyse von g_usbDev fiel mir dev.class_cb auf. Dabei handelt es sich nicht um einen gewöhnlichen Datenzeiger, sondern um die Laufzeit-Callback-Tabelle des USB-Class-Treibers; der USB-Core ruft bei der Anforderungsverarbeitung über diese Tabelle Funktionen wie Setup, DataIn und DataOut auf. Gelingt es, class_cb zu überschreiben, durchläuft eine nachfolgende reguläre USB-Anforderung die von uns kontrollierten Funktionszeiger – was es zu einem idealen Ziel für ein Hijacking macht.

Der gesamte Exploit lässt sich in zwei USB-Anforderungen aufteilen.

Die erste Anforderung nutzt SET_LINE_CODING, um den Out-of-Bounds-Schreibzugriff auszulösen. Bei diesem Schreibvorgang müssen drei Dinge gleichzeitig geschehen: Platzieren des shellcode in CmdBuff, Erstellen einer gefälschten Callback-Tabelle im benachbarten SRAM und schließlich das Ändern von class_cb auf die Adresse dieser gefälschten Tabelle.

Anschließend sende ich eine reguläre GET_LINE_CODING-Anforderung. Der USB-Core verarbeitet diese wie gewohnt und ruft über class_cb->Setup(...) den Setup-Callback des Class-Treibers auf. Der Unterschied: class_cb zeigt nun nicht mehr auf die ursprüngliche Callback-Tabelle, sondern auf unsere gefälschte Tabelle; der gefälschte Setup-Zeiger wiederum verweist auf den shellcode in CmdBuff. Somit lenkt die zweite USB-Anforderung den PC direkt auf unseren im SRAM platzierten Code.

Da der shellcode im SRAM liegt, müsste eigentlich die Nicht-Ausführbarkeit von Datenbereichen berücksichtigt werden. Die Firmware verwendete bei der MPU-Konfiguration jedoch ein falsches Größenformat, was zu einem Schutzbereich von 0 führte – die MPU-Region, die die Ausführungsrechte des BSS einschränken sollte, war de facto wirkungslos. Daher konnte der Code in CmdBuff direkt ausgeführt werden.

Hijacking der USB-Callback-Tabelle zur Ausführung von shellcode

Nachdem die theoretische Machbarkeit feststand, ging es an die praktische Umsetzung. Zuerst testete ich den tatsächlichen Bereich für Out-of-Bounds-Lese- und Schreibzugriffe. Ich konstruierte Control-Transfers von 64 Bytes: Das Out-of-Bounds-Lesen konnte kontinuierlich rund 24 KB SRAM leaken, doch beim Out-of-Bounds-Schreiben stürzte das System ab einer Position von 4.352 Bytes reproduzierbar ab.

Eine anschließende Überprüfung ergab, dass die Out-of-Bounds-Daten an dieser Stelle einen bei CmdBuff + 0x1130 noch verwendeten Zeiger überschrieben, wodurch EP0 unmittelbar die Fähigkeit verlor, weitere Daten zu empfangen.

Position des Out-of-Bounds-Writes, der zum Geräteabsturz führt

Die Lösung war relativ einfach: Da wir bereits über die Fähigkeit zum Out-of-Bounds-Lesen verfügten, lasen wir den realen Zustand per Out-of-Bounds-Read aus und luden die gedumpten Zustandsdaten in den shellcode. Damit stand eine vollständige Logik für beliebige Codeausführung.

Nun ließ sich class_cb überschreiben, doch sollte das Hijacking den USB-Kanal nicht dauerhaft beschädigen. Der lange Schreibvorgang platziert zunächst shellcode und gefälschte Callback-Tabelle im SRAM und lässt class_cb temporär auf die Fake-Tabelle zeigen; nach dem Senden von GET_LINE_CODING springt der USB-Core über das gefälschte Setup in den shellcode. Nach Abschluss der Aufgabe schreibt der shellcode das Ergebnis hinter CmdBuff, stellt das originale class_cb wieder her und ruft das ursprüngliche Setup auf, sodass die EP0-Übertragung ordnungsgemäß endet. Dadurch ist jedes Hijacking nur ein kurzer Detour: USB bleibt voll funktionsfähig und bereit für die nächste Aufgabe.

Die Firmware versuchte ursprünglich, den BSS mittels MPU als nicht-ausführbar zu konfigurieren, doch der Konfigurationscode verwendete ein fehlerhaftes Größenformat, sodass der berechnete Schutzbereich letztlich null betrug.

Von beliebiger MCU-Codeausführung zur Mnemonic-Extraktion

Beliebige Codeausführung auf der MCU bedeutet noch nicht automatisch, dass Mnemonics extrahiert werden können. Die Architektur der Hardware-Wallet ist wie folgt aufgebaut: Die verschlüsselten Mnemonic-Informationen sind im DS28S60 SE gespeichert, während an der Generierung des AES-Keys zur Entschlüsselung sowohl OTP als auch die beiden SEs (ATECC608 und DS28S60) beteiligt sind.

Sicherheitsarchitektur der Hardware-Wallet

Der Prozess zur Generierung dieses AES-Keys sieht wie folgt aus:

Ablauf der AES-Key-Generierung

Die für die SE-Interaktion und AES-Generierung erforderlichen Credentials werden primär aus dem Passcode (Entsperrpasswort) der Wallet und dem OTP erzeugt; der Ablauf ist wie folgt:

Ablauf der Passcode- und OTP-Credential-Generierung

Der Passcode lässt sich nach dem Auslesen des Passwort-Hashs durch Brute-Force ermitteln; somit wird letztlich nur noch das OTP-Salt benötigt, um die Generierung des AES-Keys abzuschließen. Zur Extraktion des OTP läuft der shellcode auf derselben Privilegienebene wie die reguläre Firmware, sodass über die USB-Schwachstelle in MPU-Register geschrieben, die MPU deaktiviert und anschließend das OTP ausgelesen werden kann.

Die finale Exploit-Methode sieht wie folgt aus: Nach Erhalt des AES-Keys kann die BIP39-Entropy entschlüsselt und die Mnemonics rekonstruiert werden.

Vollständige Angriffskette von der USB-Schwachstelle bis zur Mnemonic-Extraktion

Fazit

Im Verlauf dieser Untersuchung kam KI in erheblichem Umfang bei der Schwachstellenanalyse und im Exploit-Entwicklungsprozess zum Einsatz. Der Einsatz von KI steigert die Effizienz von Sicherheitsforschern enorm und verändert die Forschungskosten für derartige Schwachstellen grundlegend. Während das Auffinden und Ausnutzen von Schwachstellen früher oft immense manuelle Arbeitszeit bis zu einem stabilen Exploit erforderte, lassen sich Codeverständnis, Struktur-Matching, Skriptgenerierung und Ursachenanalyse bei Fehlschlägen heute deutlich beschleunigen.

Zudem werden USB SDKs sowie andere Drittanbieter-Komponenten bei Sicherheitsüberprüfungen von Produkten leicht übersehen – und genau diese Schwachstelle führt am Ende häufig dazu, dass die gesamte Produktsicherheit kompromittiert wird.