Vom Oszilloskop zum Glitch-Generator Die Sicherheit bei UART auf dem Prüfstand

Anbieter zum Thema

Keysight Technologies Deutschland GmbH

Bürklin GmbH & Co. KG

dataTec AG

ISH Ingenieursozietät GmbH

Die UART-Schnittstelle ist ein mächtiges Werkzeug zur Fehlerbehebung und Konfiguration von Embedded-Systemen. Sie hat direkten Zugriff auf die Firmware und ist ein primäres Ziel für Angreifer. Doch wie sicher sind gängige Schutzmaßnahmen wirklich?

UART (Universal Asynchronous Receiver-Transmitter) ist in der Gerätehardware als Debugging-Schnittstelle weit verbreitet. Die Kommunikation erfolgt denkbar einfach über drei Leitungen: Senden (TX), Empfangen (RX) und Masse (GND). Für Angreifer ist UART das sogenanntes Goldene Ticket, da die Schnittstelle oft einen unbefugten Low-Level-Zugriff ermöglicht. Im Extremfall sogar auf eine nicht authentifizierte Root-Shell. Hersteller stehen daher vor der Herausforderung, UART so abzusichern, dass autorisiertes Personal sie nutzen kann, böswillige Akteure jedoch ausgesperrt bleiben. Dass eine hochgesicherte Implementierung dennoch kein unüberwindbares Hindernis darstellt, zeigt die folgende Analyse eines realen Falls.

Die physische Spurensuche

Der erste Schritt besteht darin, die physische Verbindung zum Zielgerät herzustellen. Man sucht nach Testpads auf der Leiterplatte, die üblicherweise in Gruppen von drei oder vier Pins angeordnet sind. Auf dem untersuchten Gerät (Bild 1) befand sich eine vielversprechende Anschlussfläche für einen vierpoligen Stecker in unmittelbarer Nähe eines eMMC-Chips. Die Identifizierung der Pins ist ein klassischer messtechnischer Prozess. Die Masse (GND) lässt sich mittels Durchgangsprüfung gegen eine bekannte Massefläche (beispielsweise eine geerdete Schraube oder Abschirmung) schnell bestimmen. Die Versorgungsspannung (V_CC) ist oft an einer dickeren Leiterbahn erkennbar, die vom Pin wegführt. Im vorliegenden Fall ergab die Prüfung: Pin 1 führt Spannung, Pin 4 ist Masse.

Signalanalyse am Oszilloskop

m TX und RX zu unterscheiden, ist ein Oszilloskop das effizienteste Werkzeug. Da der TX-Pin Daten sendet, zeigt er beim Bootvorgang ein unregelmäßiges Rechtecksignal. Der RX-Pin hingegen bleibt passiv, da er lediglich auf eingehende Daten wartet. Der Anschluss des Oszilloskop-Tastkopfs an Pin 2 des mysteriösen Anschlusses bestätigte den Datenfluss: Pin 2 ist TX, folglich ist Pin 3 RX.

Die nächste Hürde ist die Dekodierung der Daten. Da UART kein Taktsignal zur Synchronisation verwendet, muss die Baudrate bekannt sein. Diese lässt sich aus dem Rechtecksignal ableiten: Man misst den kleinsten Impuls (ein einzelnes Datenbit). Wie in Bild 2 zu sehen ist, betrug die Amplitude (ΔY) etwa 3,3 V. Das ist eine Standardspannung für UART. Die gemessene Frequenz (Δ X) lag bei etwa 116.280 Hz. Unter Berücksichtigung der Standard-Baudraten ergab sich ein Zielwert von 115.200 Baud. Mit diesen Parametern konnte ein USB-zu-UART-Adapter angeschlossen werden, um die Kommunikation des Geräts am Laptop mitzuverfolgen.

Die Sicherheitsbarrieren der Firmware

Nach der Hardware-Verbindung folgt die Ernüchterung: Die Boot-Meldungen des Geräts münden weder in einer Shell-Eingabeaufforderung noch in einer interaktiven Schnittstelle. Ein Standardangriff besteht darin, den automatischen Bootvorgang durch Tastenkombinationen wie Strg+C zu unterbrechen, um in die Konfigurationsumgebung des Bootloaders zu gelangen. Dort könnten Boot-Parameter so geändert werden, dass das System statt des Standard-Skripts direkt eine interaktive Shell (/bin/sh) startet. Das untersuchte Gerät war jedoch dagegen gewappnet.

Die Analyse der Boot-Meldungen (Bild 4) offenbarte zwei wesentliche Schutzmechanismen:

• bootdelay = -3: Dieser Wert deaktiviert das Zeitfenster für eine Unterbrechung des Bootvorgangs komplett. Selbst massive Datenfluten am RX-Pin, ein gängiger Trick zum Abfangen des Bootvorgangs, laufen hier ins Leere.

• bootstopkeysha256: Selbst bei einer erfolgreichen Unterbrechung verlangt das System ein Passwort. Der zugehörige Passwort-Hash wurde im Log ausgegeben. Obwohl das Passwort in diesem Fall durch Brute-Force als „password12345“ identifiziert werden konnte, war der Weg zur Eingabe durch das fehlende Boot-Delay versperrt.

Den eMMC-Speicher stören

Wenn die Software-Ebene den Zugriff verweigert, muss die Manipulation auf der Hardware-Ebene ansetzen. Ein bekanntes Verfahren von Brad Dixon (Carve Systems) sieht vor, den Ladevorgang der Firmware zu stören, indem man die Datenleitung des Speichermediums (hier der data0-Pin des eMMC) im richtigen Moment auf Masse legt [1]. Das Ziel ist es, das System durch einen Lesefehler zum Abbruch des automatischen Bootvorgangs zu zwingen, in der Hoffnung, dass es in eine rettende Bootloader-Shell zurückfällt.

Auch hier zeigte sich das Design des Geräts widerstandsfähig. Während des Bootens fanden umfangreiche Validierungsprüfungen statt:

• Eine Shmoo-Plot-Validierung prüfte die Funktionalität des gesamten eMMC.

• Verschlüsselungszertifikate wurden gelesen und verifiziert.

Jeder Fehler während dieser sensiblen Phasen führte nicht zum Rückfall in eine Shell, sondern zum sofortigen Systemstopp mit der Aufforderung: ERROR ### Please RESET the board ###. Ein präzises Timing war also überlebenswichtig.

Automatisierte Fehlerinjektion

Nach genauer Untersuchung der Boot-Meldungen wurde ein extrem kurzes Zeitfenster zwischen dem Abschluss der Validierung und dem Versuch des Kernels, das Betriebssystem zu laden, identifiziert. Um dieses Fenster exakt zu treffen, wurde ein Glitch-Pattern-Generator (Keysight DS1180A) eingesetzt [2]. Das Tool überwacht den UART-Datenstrom in Echtzeit. Sobald eine vordefinierte Textphrase in den Boot-Meldungen erscheint, löst das Gerät automatisch einen Glitch (Kurzschluss der data0-Leitung gegen Masse) aus. Das Besondere: Das Timing ist mikrosekundengenau einstellbar.

Die Analyse ergab, dass das Zeitfenster, in dem der Glitch den Bootprozess erfolgreich stoppen kann, ohne das System zum Absturz zu bringen, etwa vier Sekunden beträgt. In der hochpräzisen Welt der Fehlerinjektion, wo Glitches oft im Nanosekundenbereich zwischen einzelnen CPU-Befehlen gesetzt werden müssen, ist dies eine ungewöhnlich lange Zeitspanne. Dennoch war dieser automatisierte Trigger der Schlüssel zum Erfolg: Der automatische Bootvorgang konnte unterbrochen werden, und der Zugriff auf die geschützte Konfiguration war frei.

Ein Fazit

Der Fall verdeutlicht, dass UART-Schnittstellen trotz restriktiver Software-Konfigurationen und Passwortschutz verwundbar bleiben. Die Kombination aus klassischer Signalanalyse am Oszilloskop und moderner Fehlerinjektion zeigt die Grenzen rein softwarebasierter Sicherheitskonzepte auf. Für Entwickler von Embedded-Systemen bedeutet das, dass Sicherheit nicht nur im Code, sondern auch durch physische Härtung der Hardware. Das kann etwa durch das Deaktivieren von Debug-Pins in der Serienfertigung gewährleistet werden. (heh)

Quellen

[1] How to Root an Embedded Linux with a Sewing Needle. (PDF).

[2] DS1180A Glitch Pattern Generator. Keysight.

* Ricky Lawshae ist Principal Security Researcher bei Keysight Technologies.

(ID:50843022)