Sicherheits-Checkliste

Lernziel

Nach dieser Seite kannst du ein BLE-Gerät systematisch anhand einer strukturierten Checkliste bewerten. Du weißt, welche Sicherheitsaspekte in jeder Kategorie geprüft werden müssen, welches Werkzeug du für jeden Prüfpunkt einsetzt und was ein Befund in der Praxis bedeutet.

Wofür brauche ich eine Checkliste?

Stell dir vor, du bist Pilot und bereitest eine Maschine zum Start vor. Du verlässt dich nicht auf dein Gedächtnis — du arbeitest eine Checkliste ab. Punkt für Punkt, ohne Abkürzungen. Fehlt ein Schritt, bleibt das Flugzeug am Boden.

Im Security-Assessment ist die Checkliste genauso wichtig. Ohne sie vergisst du im Eifer der Analyse leicht einen ganzen Prüfbereich — etwa ob das Gerät eine Bonded-Device-Whitelist verwendet, oder ob MAC-Adress-Randomisierung aktiv ist. Diese Checkliste deckt alle sicherheitsrelevanten Prüfpunkte eines BLE-Assessments ab und orientiert sich an den OWASP IoT Top 10 und ETSI EN 303 645 (dem europäischen Standard für Consumer-IoT-Sicherheit).

Kategorie 1: Authentifizierung

Authentifizierung ist die Frage: Muss sich ein Gerät ausweisen, bevor es Befehle senden darf? Ein BLE-Gerät ohne Authentifizierung akzeptiert Befehle von jedem in Funkreichweite — so wie eine Haustür ohne Schloss.

Prüfmethode: Wireshark mit aktivem SMP-Filter (btsmp) und JADX für App-Layer-Prüfung.

Was bedeuten die Befunde?

Kein BLE-Pairing bedeutet: Jeder BLE-Client in Reichweite kann sich verbinden und Befehle senden. Das ist der häufigste und kritischste Befund bei Budget-IoT-Geräten — wie beim Smart-LED-Strip in dieser Analyse.

Kein MITM-Schutz (Just-Works-Pairing mit TK=0) bedeutet: Ein passiver Sniffer kann den Pairing-Handshake aufzeichnen und den Long-Term-Key offline berechnen.

Kategorie 2: Verschlüsselung

Verschlüsselung ist die Frage: Kann jemand, der den Funkverkehr mithört, die Daten lesen? Es gibt zwei Ebenen: die Link-Layer-Verschlüsselung (automatisch durch BLE-Pairing) und die App-Layer-Verschlüsselung (manuell implementiert in der App).

Prüfmethode: Wireshark für Link-Layer, Shannon-Entropie-Analyse und JADX/Ghidra für App-Layer.

Was bedeuten die Befunde?

App-Layer-Verschlüsselung mit AES-ECB (wie bei der LED-Brille) schützt vor zufälligem Replay, aber nicht vor einem Angreifer mit Schlüsselkenntnis. AES-ECB ohne Nonce bedeutet außerdem: Gleicher Klartext ergibt immer gleichen Geheimtext — strukturelle Muster bleiben sichtbar.

Hardcodierte Schlüssel sind der kritischste Befund: Sie können mit JADX oder Ghidra aus der APK extrahiert werden, ohne Root-Zugriff und ohne physischen Gerätekontakt. Ein einmal kompromittierter Schlüssel gefährdet alle weltweit verkauften Geräte dieses Modells.

Kategorie 3: Integrität und Replay-Schutz

Integrität ist die Frage: Kann ein Angreifer aufgezeichnete Befehle einfach wiederholen? Ohne Replay-Schutz genügt es, einen gültigen Befehl einmal zu sehen — und ihn beliebig oft wieder abzuschicken.

Prüfmethode: Aufgezeichnete PCAP-Pakete via blatann erneut senden und Gerätereaktion beobachten.

Was bedeuten die Befunde?

Fehlt der Replay-Schutz, kann ein Angreifer beliebige Befehle mit einem einzigen vorherigen Mitschnitt ausführen. Beim Smart-LED-Strip konnte jeder der 69 aufgezeichneten Klartextbefehle direkt wiederholt werden — ohne Schlüssel, ohne Protokollkenntnis.

Kategorie 4: Schlüsselmaterial und Datenschutz

Diese Kategorie prüft, wie mit kryptographischen Schlüsseln umgegangen wird — von der Erzeugung bis zur Speicherung.

Prüfmethode: JADX für Java-Schlüsselverwaltung, Ghidra für native Bibliotheken, Android Keystore API prüfen.

Was bedeuten die Befunde?

Hardcodierte Schlüssel in nativen Bibliotheken (.so-Dateien) sind die schwerwiegendste Schwachstelle in dieser Analyse. Sie betreffen alle je verkauften Geräte des Modells — ein globaler Schlüssel für Millionen von Geräten.

Sensible Daten in Advertising-Paketen sind besonders problematisch bei Health-Geräten: Körpergewicht und Impedanz der Lebenlang-Waage liegen für jeden passiven Empfänger in 30 Metern Umgebung lesbar vor — ohne Verbindungsaufbau, ohne Pairing, ohne jede Interaktion.

Kategorie 5: Compliance und Offenlegung

Diese Kategorie prüft nicht die technische Sicherheit des Geräts, sondern den organisatorischen Umgang damit.

Wie dokumentierst du deine Befunde?

Jeder Prüfpunkt, der ein Sicherheitsproblem aufdeckt, muss strukturiert dokumentiert werden. Ein guter Befundbericht enthält für jeden Fund:

Pflichtfelder pro Befund:

• Befunds-ID: Eindeutige Kennung, z. B. VULN-2026-001
• Titel: Kurze, präzise Beschreibung (max. 80 Zeichen)
• Kategorie: Authentifizierung / Verschlüsselung / Integrität / Schlüsselmaterial / Compliance
• CVSS-3.1-Vektor: Vollständiger Vektor und Score, z. B. AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N → 8.1 HIGH
• Technische Beschreibung: Was wurde gefunden, wie wurde es gefunden (Werkzeug, Methode)
• Reproduzierbarkeit: Schritte, um den Befund zu reproduzieren
• OWASP-IoT-Mapping: Welchem I1–I10-Punkt entspricht der Befund
• Gegenmaßnahme: Was der Hersteller tun sollte

Beispiel-Befund (LED-Strip):

VULN-2026-002: Fehlende BLE-Authentifizierung im Smart-LED-Strip

CVSS-3.1: AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N → 6.5 MEDIUM
          (Alternativ mit AC:H für Angreifer ohne Vorerfahrung: 4.2 MEDIUM)

Beschreibung:
Das Smart-LED-Strip akzeptiert GATT-Write-Requests von beliebigen
BLE-Clients ohne Pairing, Authentifizierung oder Autorisierungsprüfung.
In einer 45-sekündigen Wireshark-Session wurden 69 GATT-Write-Requests
(btatt.opcode == 0x12) erfasst — alle im Klartext, ohne SMP-Handshake.

Reproduktion:
1. blatann-Skript ausführen (Phase 5 PoC-Template)
2. Verbindung zur MAC-Adresse des Strips aufbauen
3. Farbbefehl senden: 7e 07 05 03 ff 00 00 10 ef
4. Strip reagiert — keine Authentifizierung erforderlich

OWASP IoT I1: Weak, Guessable, or Hardcoded Passwords

Gegenmaßnahme:
BLE-Pairing mit Passkey-Methode implementieren. GATT-Server so konfigurieren,
dass Write-Operationen nur für gebondete Geräte zulässig sind.

Reale Befunde aus der Analyse: Kurzübersicht

Die drei untersuchten Geräte liefern konkrete Beispiele für jeden Prüfbereich:

LED-Brille (Sonhomay)

Smart-LED-Strip

Körperwaage (Lebenlang)

Prüfreihenfolge: Effizient durch die Kategorien

Die Kategorien bauen auf den Phasenergebnissen auf. Diese Reihenfolge ist effizient:

1. Authentifizierung zuerst (Phase 2-Ergebnis): Kein Pairing gefunden? Das ist sofort ein HIGH-Befund und beeinflusst alle weiteren Kategorien.
2. Verschlüsselung (Phase 1 + 2): Link-Layer klar durch Wireshark, App-Layer durch JADX.
3. Schlüsselmaterial (Phase 3): Ghidra-Analyse der nativen Bibliotheken — hier stecken die kritischsten Befunde.
4. Integrität / Replay (Phase 5): Aktiver Test mit dem PoC aus Phase 5 — Befehle wiederholen und Reaktion beobachten.
5. Compliance (nach Abschluss): Disclosure-Prozess einleiten, CVSS-Scores konsolidieren.

Befundbericht: Schnell-Übersicht

Trage deine Ergebnisse in diese Übersicht ein, um den Status eines Assessment-Ziels auf einen Blick zu sehen:

Zusammenfassung

• Die Checkliste strukturiert ein BLE-Assessment in fünf Kategorien: Authentifizierung, Verschlüsselung, Integrität, Schlüsselmaterial und Compliance.
• Jeder Prüfpunkt ist einem Werkzeug (Wireshark, JADX, Ghidra, blatann), einer Risikostufe und einer OWASP-IoT-Nummer zugeordnet.
• Kein Pairing ist der häufigste Befund bei Budget-IoT-Geräten und erhält CVSS 8.1 (HIGH).
• Hardcodierte Schlüssel in nativen Bibliotheken sind der kritischste Befund — sie kompromittieren alle Geräte eines Modells weltweit.
• Sensible Daten in Advertising-Paketen sind besonders bei Health-Geräten ein DSGVO-relevanter Befund.
• Die Compliance-Kategorie erinnert daran, dass Responsible Disclosure eine ethische Pflicht ist — nicht nur eine Best Practice.