IoT-Penetrationstest: Was wir angreifen und was wir finden

Ein IoT-Produkt ist nie nur ein Gerät. Es ist Hardware, Firmware, eine Funkstrecke, eine App und ein Cloud-Dienst. Einem Angreifer reicht es, wenn eines davon schwach ist. Ein IoT-Penetrationstest nimmt sich alles zusammen vor, denn die spannenden Angriffe laufen meist über die Grenzen hinweg.

Das machen wir in so einem Test wirklich, und das finden wir immer wieder.

Die fünf Ebenen, die wir angreifen

1. Hardware

Zuerst öffnen wir das Gerät. Auf der Platine suchen wir nach Debug-Schnittstellen (UART, JTAG, SWD), Testpunkten und dem Flash-Chip. Eine serielle Konsole, die direkt in einer Root-Shell landet, gehört im Feld noch immer zu den häufigsten Findings.

Ist der Debug-Port gesperrt, holen wir uns die Firmware auf anderem Weg: Wir lesen den Flash-Chip direkt aus oder bringen den Prozessor per Glitching dazu, eine Prüfung zu überspringen.

2. Firmware

Haben wir die Firmware, entpacken wir sie und lesen sie. Typische Fragen:

• Gibt es fest einprogrammierte Passwörter, API-Schlüssel oder private Schlüssel?
• Welche Open-Source-Komponenten stecken drin, und wie alt sind sie?
• Gibt es eine Secure-Boot-Kette, und prüft wirklich jede Stufe die nächste?
• Wie werden Updates geprüft? Signiert, oder nur gegen eine Prüfsumme verglichen?

3. Funk und lokale Schnittstellen

Bluetooth LE, WLAN, Zigbee, Thread, LoRaWAN oder eine proprietäre Sub-GHz-Strecke: Wir schneiden den Verkehr mit, spielen ihn wieder ein und verändern ihn. Das Pairing ist ein beliebtes Ziel, denn viele Geräte akzeptieren jeden, der im richtigen Moment fragt.

4. App

Die zugehörige App weiß oft mehr, als sie sollte. Wir dekompilieren sie, suchen nach Secrets und beobachten, wie sie mit Gerät und Cloud spricht.

5. Cloud und APIs

Hier testen wir, ob ein Kunde an die Geräte eines anderen Kunden kommt. Kaputte Zugriffskontrolle auf Geräte-IDs ist der Klassiker: Du änderst eine Zahl in einer Anfrage und steuerst das Produkt von jemand anderem.

Was wir am häufigsten finden

Finding	Warum es zählt
Offene Debug-Konsole (UART/JTAG)	Volle Kontrolle bei physischem Zugriff und ein schneller Weg zur Firmware
Fest einprogrammierte Zugangsdaten oder Schlüssel in der Firmware	Ein ausgelesenes Gerät kompromittiert die ganze Flotte
Unsignierte oder schwach geprüfte Updates	Ein Angreifer kann eigene Firmware installieren
Veraltete Komponenten mit bekannten Schwachstellen	Öffentliche Exploits funktionieren ohne Anpassung
Pairing ohne echte Authentifizierung	Jeder in der Nähe kann das Gerät übernehmen
Cloud-API vertraut der Geräte-ID	Zugriff auf Geräte und Daten anderer Kunden
Gleiches Standardpasswort auf jedem Gerät	Massenhafte Kompromittierung aus dem Internet

Nichts davon braucht exotische Techniken. Es braucht jemanden, der hinschaut.

So läuft ein Test ab

1. Scoping-Call. Fünfzehn Minuten, um Gerät, Schnittstellen und Testtiefe abzustimmen.
2. Teardown und Firmware. Wir gehen ins Gerät und holen heraus, was darauf läuft.
3. Angriff. Hardware, Funk, App und Cloud, und dann die Kombinationen dazwischen.
4. Bericht und Debriefing. Jedes Finding mit Proof of Concept, Schweregrad und Fix, erklärt für dein Entwicklungsteam.
5. Retest. Wir prüfen, ob die Fixes halten.

So bereitest du dich vor

• Schick mindestens zwei Geräte. Eines überlebt vielleicht nicht.
• Stell eine Testumgebung in der Cloud bereit, getrennt von der Produktion.
• Gib uns Firmware-Images und Dokumentation, wenn du sie hast. Das spart Tage.
• Nenn uns eine Ansprechperson aus der Entwicklung, die Fragen schnell beantwortet.

Warum jetzt

Seit dem 1. August 2025 gelten die Cybersecurity-Anforderungen der Funkanlagenrichtlinie (RED) für Funkgeräte, und ab Dezember 2027 gilt der Cyber Resilience Act für fast alles mit digitalen Elementen. Beide erwarten, dass Produkte getestet sind, bevor sie auf den Markt kommen.

Du willst wissen, wie sich dein Gerät schlägt? Schau dir unsere IoT-Security-Tests an oder hol dir ein Pentest-Angebot.