IoT-Pentesting: Angriffsflächen vernetzter Geräte

Ein vernetztes Produkt ist selten ein einzelnes Prüfobjekt. Zu betrachten sind die Hardware (Debug- und Speicherschnittstellen, Bauteilbestückung), die Firmware (Bootkette, Dateisystem, hinterlegte Geheimnisse), die Funkschnittstellen (u. a. Wi-Fi, Bluetooth Low Energy, Zigbee, Thread, LoRaWAN, Mobilfunk und proprietäre Sub-GHz-Protokolle), das Cloud-Backend mit seinen APIs sowie die begleitende Mobile- oder Web-App. Genau diese Aufteilung spiegelt sich in den fünf Anforderungskategorien des OWASP ISVS – IoT Ecosystem, User Space Application, Software Platform, Communication und Hardware Platform. Eine isolierte Prüfung einzelner Ebenen übersieht typischerweise die Übergänge, etwa das Onboarding eines Geräts in ein Nutzerkonto.

Die Hardware-Analyse beginnt mit der Identifikation von Bauteilen und Testpunkten auf der Platine. Serielle Konsolen (UART) geben in der Praxis häufig Bootlogs, Bootloader-Zugriff oder eine unzureichend geschützte Shell frei; Debug-Schnittstellen wie JTAG oder SWD erlauben je nach Sperrzustand des Controllers das Anhalten der CPU sowie Lese- und Schreibzugriffe auf den Speicher. Externe Flash-Bausteine an SPI oder I2C lassen sich in vielen Fällen im eingebauten Zustand oder nach Auslöten auslesen. Geprüft wird deshalb nicht nur, ob solche Zugänge existieren, sondern ob Debug-Ports produktiv deaktiviert bzw. authentifiziert sind, ob Secure Boot greift und ob sensible Parameter verschlüsselt oder in einem geschützten Element abgelegt sind.

Firmware wird über Hersteller-Downloads, mitgeschnittene Update-Vorgänge oder einen Speicher-Dump beschafft und anschließend entpackt. Die statische Analyse sucht nach fest eingebauten Zugangsdaten, privaten Schlüsseln und Zertifikaten, unsicheren Konfigurationen sowie veralteten Komponenten, die über eine Stückliste (SBOM) mit bekannten Schwachstellen abgeglichen werden. Ergänzend wird die dynamische Analyse am laufenden oder emulierten System durchgeführt. Die OWASP Firmware Security Testing Methodology (FSTM) beschreibt dieses Vorgehen in neun Phasen von der Informationsbeschaffung über Extraktion und Emulation bis zur Verifikation der Findings. Zentrale Prüffrage bleibt die Update-Fähigkeit: Wird die Signatur eines Updates tatsächlich geprüft, und lässt sich ein Downgrade auf eine ältere, angreifbare Version verhindern?

Für Anforderungen und Testdurchführung stehen offene Kataloge bereit. Der OWASP ISVS bündelt Sicherheitsanforderungen für IoT-Ökosysteme in fünf Kategorien und liegt öffentlich als Release Candidate 1.0RC vor; der OWASP ISTG ergänzt seit seiner Version 1.0 vom 1. März 2024 eine Pentest-Methodik mit Geräte- und Angreifermodell sowie einem Testfallkatalog, der u. a. Funkschnittstellen, Verarbeitungseinheiten, Gerätespeicher, interne und physische Schnittstellen sowie Firmware und Update-Mechanismus abdeckt. Auf Produktebene definiert ETSI EN 303 645 in der Version V3.1.3 (2024-09) eine Baseline für Consumer-IoT mit 13 Themenbereichen – von der Abschaffung universeller Standardpasswörter über die Behandlung eingehender Schwachstellenmeldungen bis zur sicheren Ablage sicherheitsrelevanter Parameter – ergänzt um ein Kapitel zu Datenschutzbestimmungen. Die zugehörige Bewertungsmethodik liefert ETSI TS 103 701 (V2.1.1, 2025-05) mit Testfällen je Provision; das BSI legt beide Dokumente dem IT-Sicherheitskennzeichen für smarte Verbrauchergeräte zugrunde. Eine erste Selbsteinschätzung entlang des ISVS ist über das frei nutzbare Self-Assessment unter isvs.vamisec.com möglich.

Die Delegierte Verordnung (EU) 2022/30 macht die Cybersicherheitsanforderungen aus Artikel 3 Absatz 3 Buchstaben d, e und f der Funkanlagenrichtlinie 2014/53/EU für bestimmte Kategorien von Funkanlagen anwendbar – für internetfähige Geräte, für Geräte, die personenbezogene Daten verarbeiten (u. a. Kinderbetreuungsprodukte, Spielzeug, am Körper getragene Geräte) sowie für Geräte, die virtuelle Werte oder Geld verarbeiten; ausgenommen sind sektorspezifisch regulierte Produkte wie Medizinprodukte, Luftfahrt- und Kraftfahrzeugausrüstung. Die Anforderungen gelten seit dem 1. August 2025, nachdem die Delegierte Verordnung (EU) 2023/2444 den ursprünglichen Termin um zwölf Monate verschoben hatte. Als harmonisierte Normen sind EN 18031-1, -2 und -3 im Amtsblatt gelistet (Durchführungsbeschluss (EU) 2025/138 vom 28. Januar 2025) – jedoch mit Einschränkungen, unter anderem für Konstellationen, in denen Nutzende auf die Vergabe eines Passworts verzichten können; in diesen Punkten entfällt die Konformitätsvermutung. Parallel greift der Cyber Resilience Act (Verordnung (EU) 2024/2847): Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gelten ab dem 11. September 2026, die übrigen Pflichten ab dem 11. Dezember 2027; zu diesem Datum hat die Kommission die Aufhebung der Delegierten Verordnung (EU) 2022/30 beschlossen, um Doppelregulierung zu vermeiden.

Ein IoT-Pentest beginnt mit dem Scoping: Prüfobjekte, Geräte- und Angreifermodell (physischer Zugriff und Autorisierungsniveau) sowie Anzahl der Testmuster und Rückbaurisiken werden festgelegt, ergänzt um eine gemeinsame Bedrohungsmodellierung. Darauf folgen Informationsbeschaffung, Hardware- und Schnittstellenanalyse, Firmware-Extraktion mit statischer Analyse, die Prüfung von Funk- und Netzprotokollen sowie von Cloud-API, Onboarding-Prozess und App – jeweils mit Verifikation der Findings am laufenden Gerät. Ergebnis ist ein Bericht mit reproduzierbaren Nachweisen, einer nachvollziehbaren Risikobewertung und einer nach Aufwand und Wirkung sortierten Maßnahmenliste; ein Retest belegt die Wirksamkeit der Behebung. Für Hersteller ist diese Dokumentation zugleich Nachweismaterial: Anhang I Teil II des Cyber Resilience Act verlangt wirksame und regelmäßige Tests und Überprüfungen der Produktsicherheit sowie die Identifikation und Dokumentation von Schwachstellen und Komponenten einschließlich einer maschinenlesbaren Stückliste.