IoT Penetration Testing · Moritz Samrock

IoT Penetration Testing ist die autorisierte, ganzheitliche Sicherheitsprüfung von Internet-of-Things-Ökosystemen. Im Gegensatz zu traditionellen Pentests, die sich auf eine einzelne Schicht konzentrieren, umfassen IoT-Assessments den gesamten Stack: Geräte-Hardware und -Firmware, drahtlose und kabelgebundene Kommunikationsprotokolle, Cloud-Backend-Infrastruktur, mobile Companion-Apps und die APIs, die alles verbinden. Ziel ist es, ausnutzbare Schwachstellen über diese vernetzten Komponenten hinweg zu finden, bevor ein Angreifer sie zu einer vollständigen Kompromittierung verketten kann.

Die Herausforderung der IoT-Sicherheitsprüfung liegt in ihrer Breite. Ein einzelnes Smart-Gerät kommuniziert möglicherweise über BLE, verbindet sich mit einem MQTT-Broker über TLS, synchronisiert seinen Zustand mit einer Cloud-API und wird über eine mobile App verwaltet — jede Schicht mit eigener Angriffsfläche, wobei Schwachstellen in einer Schicht oft die Ausnutzung einer anderen ermöglichen.

Wer beauftragt diesen Test?

IoT-Penetrationstests werden von IoT-Produktunternehmen, Smart-Home- und Gebäudeautomatisierungsherstellern, Medizingeräteherstellern, Industrial-IoT-Anbietern und CISOs beauftragt, die IoT-Geräte im Unternehmensmaßstab einsetzen. Der Anstoß kommt typischerweise von Product-Security-Teams während der Pre-Launch-Validierung, von Compliance-Abteilungen zur Vorbereitung regulatorischer Zertifizierung oder von Enterprise-Security-Teams, die IoT-Geräte vor der Integration in Unternehmensnetzwerke evaluieren.

Ziel des Tests

Primäre Ziele sind die Bewertung der Sicherheitslage des gesamten IoT-Ökosystems, die Identifikation von Schwachstellen, die unbefugten Gerätezugriff, Datenabfluss oder Gerätemanipulation ermöglichen könnten, und die Prüfung, ob das Gerät in einer Weise kompromittiert werden kann, die die Privatsphäre oder Sicherheit der Nutzer beeinträchtigt. Spezifische Ziele umfassen die Prüfung der Firmware-Update-Integrität und -Authentizität, die Evaluierung der Protokollsicherheit drahtloser Kommunikation, die Bewertung von Cloud-API-Autorisierung und -Authentifizierung, die Verifikation der korrekten TLS-Implementierung und die Bestimmung, ob die Kompromittierung eines Geräts Angriffe auf andere Geräte desselben Deployments ermöglicht.

Was wird getestet?

Die Prüfung umfasst die gesamte IoT-Angriffsfläche über vier Domänen:

Geräteebene — Firmware-Extraktion und -Analyse (hardcodierte Geheimnisse, Debug-Schnittstellen, Update-Mechanismen), Hardware-Debug-Ports (UART, JTAG, SWD), lokale Speicherverschlüsselung, Bootloader-Sicherheit und physische Schnittstellen (USB, SD-Karte, Reset-Verhalten).

Kommunikationsebene — Drahtlose Protokolle (BLE-Pairing und GATT-Services, Zigbee-Schlüsselaustausch, Z-Wave-S2-Authentifizierung, LoRaWAN-Session-Key-Management, WLAN-Konfiguration), kabelgebundene Protokolle (Ethernet, seriell) und Anwendungsschicht-Protokolle (MQTT-Authentifizierung und ACLs, CoAP-Security, HTTP/WebSocket-APIs, UPnP/SSDP/mDNS-Service-Discovery-Exposition).

Cloud-/Backend-Ebene — API-Authentifizierung und -Autorisierung (OAuth-Flows, API-Key-Management, IDOR-Schwachstellen), Geräte-Provisioning- und Registrierungsflows, Over-the-Air (OTA)-Update-Infrastruktur (Signierung, Auslieferung, Rollback-Schutz), Datenspeichersicherheit und Multi-Tenant-Isolation.

Mobile-/Companion-App-Ebene — Authentifizierungsflows, lokale Datenspeicherung (Keychain/Keystore-Nutzung, Klartext-Zugangsdaten), Certificate-Pinning-Implementierung, API-Kommunikationssicherheit und Inter-Process-Communication (IPC)-Angriffsfläche.

Übliche Schwachstellen und Findings

Standard- oder hardcodierte Zugangsdaten — Werkseitig gesetzte Benutzernamen und Passwörter, die bei allen Geräten identisch sind und in öffentlich verfügbaren Handbüchern dokumentiert werden
Unsichere Firmware-Update-Mechanismen — OTA-Updates ohne kryptographische Signierung ausgeliefert, was Man-in-the-Middle-Firmware-Ersetzung ermöglicht
Unverschlüsselte Gerätekommunikation — Sensible Daten (Telemetrie, Zugangsdaten, Befehle) im Klartext über das Netzwerk oder den Funkkanal übertragen
Schwaches BLE-Pairing — Geräte mit Just-Works-Pairing oder statischen Passkeys, die passives Mithören oder aktives MITM während des Pairings ermöglichen
MQTT ohne Authentifizierung — Message Broker, die Verbindungen ohne Zugangsdaten akzeptieren und jedem Netzwerkteilnehmer das Abonnieren aller Topics oder das Veröffentlichen beliebiger Befehle erlauben
Exponierte Cloud-APIs — Gerätemanagement-APIs mit fehlender oder defekter Autorisierung, die einem Benutzer die Steuerung der Geräte anderer Benutzer erlauben (IDOR)
Fehlende Eingabevalidierung auf Geräte-APIs — Lokale Webserver oder Befehlsschnittstellen, die für Injection, Buffer Overflows oder Command Injection anfällig sind
Information Disclosure über Service Discovery — UPnP-, SSDP- oder mDNS-Broadcasts, die Gerätetyp, Firmware-Version, interne IPs und manchmal Zugangsdaten preisgeben
Schwache TLS-Implementierung — Selbstsignierte Zertifikate ohne Validierung akzeptiert, veraltete TLS-Versionen (1.0/1.1) oder fehlendes Certificate Pinning, das Traffic-Interception ermöglicht
Privacy-Leaks — Geräte, die Nutzerverhaltensdaten, Standortinformationen oder Audio/Video an Cloud-Dienste übertragen, ohne angemessene Zustimmungsmechanismen oder Verschlüsselung
Unsicheres Geräte-Provisioning — Registrierungsflows, die einem Angreifer erlauben, Geräte zu claimen oder zu reclaimen, möglicherweise durch Zurücksetzen auf Werkseinstellungen

Ablauf eines IoT-Penetrationstests

Interesse/Erstanfrage — Der Hersteller oder das einsetzende Unternehmen meldet sich für ein IoT-Security-Assessment. Das Pentest-Team erfasst Informationen zum Geräte-Ökosystem: das Gerät selbst, seine Kommunikationsprotokolle, Cloud-Services und Companion-Apps. Die Anzahl verfügbarer Gerätemuster für Tests wird besprochen.

Erstgespräch zum Verständnis der Kundenziele — Eine detaillierte technische Diskussion mit dem Produktteam, um die vollständige IoT-Architektur zu erfassen: Geräte-Hardware und -Firmware, verwendete drahtlose und kabelgebundene Protokolle, Cloud-Plattform (AWS IoT, Azure IoT Hub, Custom), Mobile-App-Plattformen (iOS, Android) und etwaige Drittanbieter-Integrationen. Tester und Auftraggeber einigen sich darauf, welche Schichten im Scope sind und welche Testtiefe pro Schicht angestrebt wird.

Angebotserstellung und Freigabe — Das Angebot spezifiziert die Testmethodik für jede Schicht (Gerät, Kommunikation, Cloud, Mobile), erwartete Dauer, benötigte Gerätemuster, erforderliche Testkonten und Liefergegenstände. Es wird von Produktmanagement, Engineering, Rechtsabteilung und — bei Enterprise-Deployments — dem CISO geprüft.

Scope-Definition — Gerätemodell, Firmware-Version, App-Version, Cloud-Umgebung (Staging vs. Produktion) und spezifische Testkonten werden dokumentiert. Der Scope definiert explizit, ob Hardware-Level-Tests (Gerät öffnen, Debug-Schnittstellen proben) enthalten oder auf Firmware-Level und darüber beschränkt sind.

Letter of Engagement — Unterzeichnete Autorisierung, die alle Ökosystem-Komponenten abdeckt, IP-Handhabung, NDA-Bedingungen und Responsible-Disclosure-Timelines für Schwachstellen, die bereits im Feld befindliche Geräte betreffen könnten.

Erstellung weiterer Freigaben — Cloud-Plattformen (AWS, Azure, GCP) erfordern ggf. Benachrichtigung oder Genehmigung für Sicherheitstests. App-Store-Richtlinien können gelten, falls die mobile App reverse-engineered wird.

Bereitstellung von Informationen je nach Black-/Gray-/White-Box-Ansatz — Der Auftraggeber stellt Gerätemuster, Testkonten (mehrere Rollen falls zutreffend), Cloud-API-Dokumentation, Firmware-Binaries oder Quellcode (für White-Box-Tests), Mobile-App-Builds und Netzwerkarchitekturdiagramme bereit. Bei Black-Box-Assessments erhält der Tester nur das Gerät, den App-Store-Link und öffentlich verfügbare Dokumentation.

Kick-Off Call — Finale Abstimmung mit dem Produktteam, Cloud Operations und Security-Ansprechpartnern. Kommunikationskanäle, der Umgang mit Findings, die Produktionsgeräte betreffen könnten, und der Testzeitplan werden bestätigt.

Durchführung mit laufender Information der Stakeholder — Tests erfolgen Schicht für Schicht, aber mit Blick auf schichtübergreifende Angriffsketten. Gerätetests: Firmware-Extraktion, Debug-Interface-Probing, lokale API-Tests, Reset-Verhaltensanalyse. Kommunikationstests: Protokoll-Capture und -Analyse, Verschlüsselungsvalidierung, Replay-Angriffe, MITM-Versuche. Cloud-Tests: API-Fuzzing, Authentifizierungs-Bypass-Versuche, Autorisierungsgrenzen-Tests, OTA-Update-Integritätsprüfung. Mobile-App-Tests: statische und dynamische Analyse, Netzwerk-Traffic-Inspektion, lokale Speicherprüfung, Authentifizierungsflow-Tests. Der Tester dokumentiert Findings pro Schicht und identifiziert gezielt Ketten, bei denen Schwächen in einer Schicht die Ausnutzung einer anderen ermöglichen. Stakeholder erhalten regelmäßige Updates; kritische Findings (RCE, Authentifizierungs-Bypass, Privacy-Verletzungen) werden sofort gemeldet.

Sammlung und Bewertung der Schwachstellen — Findings werden mit technischem Nachweis dokumentiert, nach Schweregrad (CVSS oder OWASP IoT Risk Rating) bewertet und hinsichtlich realer Auswirkungen im Deployment-Kontext des Geräts eingeordnet.

Erstellung des Abschlussberichts — Ein umfassender Bericht deckt Findings über alle Schichten ab, hebt schichtübergreifende Angriffsketten hervor, liefert komponentenspezifische Behebungsanleitung (Firmware-Fix, API-Patch, Konfigurationsänderung, Protokoll-Upgrade) und enthält eine Management-Zusammenfassung für nicht-technische Stakeholder.

Vorstellung in einer Präsentation — Die Ergebnisse werden dem Produktteam, dem Security Leadership und der Geschäftsführung vorgestellt. Die Präsentation geht die kritischsten Angriffsszenarien durch und demonstriert End-to-End-Exploitation-Ketten.

Projektabschluss — Maßnahmenprioritäten werden vereinbart, wobei zwischen via OTA-Update deploybare Fixes und solchen, die Hardware-Änderungen erfordern, unterschieden wird. Empfehlungen für laufende Sicherheitstests (Regressionstests nach Firmware-Updates, regelmäßige Neubewertung) werden dokumentiert.

Wer sollte diesen Test wann durchführen lassen?

IoT-Produkthersteller sollten Tests vor der Markteinführung beauftragen — das ist zunehmend nicht optional, sondern rechtlich vorgeschrieben. Der EU Cyber Resilience Act verlangt Sicherheitsbewertungen für Produkte mit digitalen Elementen, die auf dem europäischen Markt verkauft werden. ETSI EN 303 645 bietet einen Baseline-Sicherheitsstandard für Consumer-IoT, dessen Einhaltung viele Händler und Märkte inzwischen erwarten. Medizinisches IoT unterliegt der MDR/IVDR und der FDA Premarket Cybersecurity Guidance. Industrielles IoT wird durch die IEC 62443 abgedeckt.

Über den Pre-Launch hinaus sollten IoT-Pentests nach signifikanten Firmware-Updates, bei der Ergänzung neuer Kommunikationsprotokolle oder Cloud-Integrationen, beim Deployment von IoT-Geräten in Unternehmensnetzwerke (Bewertung durch die einsetzende Organisation) und regelmäßig für Geräte mit langer Feldeinsatzdauer wiederholt werden, da sich die Bedrohungslandschaft um sie herum weiterentwickelt.