Embedded Device Penetration Testing: Warum ein Web-Pentest nicht reicht

Ein vernetztes Produkt wird ausgeliefert mit Cloud-API, Companion-App, Funkverbindung, Firmware und Platine. Wenn die Budgetposition „Penetrationstest" heißt, kauft sie meist den Scope API und App. Der Test findet echte Probleme, und das Produkt wird trotzdem über die Schichten kompromittiert, die niemand angesehen hat. Das Web-Interface ist ein Interface unter vieren. Das Produkt sind alle.

Diese Note legt dar, was ein Embedded-Produkt-Assessment Schicht für Schicht abdeckt, und warum jede Schicht Befunde produziert, die die Schicht darüber nicht sehen kann.

Das Produkt ist ein Stack, keine Website

Produkt-Security-Testing startet mit einer anderen Arbeitseinheit als ein Web-Pentest. Die Einheit ist nicht eine Applikation; es ist das Produkt: Hardware, Firmware, Funk, Companion-App, Cloud-Backend, und die Nähte dazwischen. Ein Assessment, das nur eine Schicht abdeckt, prüft die Naht gegen nichts. Angreifer bevorzugen die Nähte: Sie pairen über BLE mit dem Gerät, um die Provisioning-API zu erreichen; sie ziehen Keys aus dem Flash, um mit dem Backend zu reden; sie nutzen die App, um das Gerät in Zustände zu bringen, die niemand je getestet hat.

Die Abdeckungskarte oben ist die ehrliche Zusammenfassung der meisten „wir hatten doch schon einen Pentest"-Gespräche: Die Schichten mit HTTP wurden getestet, die Schichten mit Lötkolben nicht.

Hardware: die Schicht, die alles andere umwertet

Physischer Zugriff ist der Einstieg, den Product-Teams systematisch unterschätzen, weil er nach Fähigkeiten klingt, die niemand hat. In der Praxis: Flash-Chips werden mit Clamp-Testern und einem flashrom-Aufruf gelesen; UART-Pads werden gefunden, indem man an unbestückten Header-Footprints Kontinuität gegen GND misst; JTAG ist in Produktions-Silizium oft aktiv, weil das Deaktivieren auf jemandes Todo-Liste stand. Aus einem Dump nehmen wir Zertifikate, Tokens, Keys, Konfiguration und Versionshistorie direkt mit, offline, in Ruhe, ohne Rate Limit und ohne Logs.

Hardware-Befunde sortieren jede andere Schicht neu. Das „sauber gehärtete" Backend-Session-Token bedeutet etwas anderes, sobald es aus jeder Einheit extrahierbar ist. Die Secure-Boot-Kette bedeutet etwas anderes, sobald das unsignierte Recovery-Image von SD bootet.

Firmware: die Evidenz-Schicht

Firmware-Analyse ist gleichzeitig Angriffsfläche und Evidenzquelle. Als Fläche: Parser für Update-Pakete, Protokoll-Handler, Management-Interfaces, die Update-State-Machine selbst. Code, der mit vollen Privilegien auf dem Gerät läuft. Als Evidenz: Firmware enthält die Backend-Endpunkte, die Protokoll-Implementierung zum Diffen, die Hardcoded Secrets, Version und Patch-Level jeder Third-Party-Komponente. Ein Produkt-Assessment ohne Firmware ist ein Assessment bei ausgeschaltetem Licht.

Funk: das Interface ohne Pförtner

BLE-, LoRa-/Wi-Fi- oder proprietäre Sub-GHz-Verbindungen sind die einzigen Interfaces, die ein Angreifer erreicht, ohne etwas zu öffnen, damit die billigste Angriffsfläche des Produkts. Standard-Befunde: Pairing-Flows ohne MITM-Schutz (siehe BLE Pairing), Kommandos, die ohne Re-Authentifizierung in privilegierte Zustände zurückkehren, und Protokoll-Parser, die dem Funk Längenfelder glauben. Web-Scope sieht davon nichts, es ist kein HTTP im Spiel.

So bereiten Sie vor, dass das Budget Befunde kauft

Der Unterschied zwischen teurer Checkliste und produktivem Assessment ist meist Vorbereitung:

• Testgeräte, keine Produktionsausschuss. Geräte, die booten, verbinden und updaten. Zwei, drei Stück, plus Debug-Zugang, falls Sie ihn geben können. Gesperrte Geräte sind ein legitimer Befund, aber sie sollten der einzige Grund sein, warum wir stoppen.
• Dokumentation unter NDA. Protokollbeschreibung, Flash-Map, Update-Paket-Layout, erwartete Pairing-Flows. Reverse Engineering des eigenen Produkts kostet Budget, das Sie in Befunde investieren wollten.
• Ein Backend-Scope, der die Geräte-Endpunkte einschließt. Die API-Fläche, die die Geräte benutzen, ist die interessante Fläche.
• Ein Kontakt, der Engineering-Fragen innerhalb eines Tages beantwortet. Jeder Wartetag ist ein Testtag, der nicht stattfindet.

Wie Ergebnisse aussehen sollten

Ein ernsthaftes Produkt-Assessment liefert Befunde, gerankt nach dem, den ein Angreifer tatsächlich gewinnt, über Schichten verkettet, mit Reproduktionsschritten und Evidenz-Spur: welcher Dump, welcher Capture, welcher Request. Und es liefert die negativen Ergebnisse, die zählen: was getestet wurde und gehalten hat, damit das nächste Release dagegen diffen kann. Listet der Bericht nur Web-Befunde für ein Produkt mit Hardware im Karton, haben Sie nicht das Produkt getestet. Sie haben eine URL getestet, die zufällig mit einem Gerät verkauft wird.