Stand der Forschung
Bekannte BLE-Angriffe und aktuelle Sicherheitsstudien
Lernziel
Nach dieser Seite weißt du, welche bedeutenden Angriffe auf BLE und Bluetooth bereits entdeckt wurden, wie weit verbreitet die Schwachstellen in echten Produkten sind und warum es sich um ein systemisches Problem handelt — nicht um einzelne Ausreißer.
Einleitung: Ein Muster, kein Zufall
Wenn du dir die Sicherheitsforschung der letzten zehn Jahre ansiehst, fällt eines auf: Die gleichen Fehler tauchen immer wieder auf. Schwache Verschlüsselung, fehlende Authentifizierung, hartcodierte Schlüssel. In Fitness-Trackern, smarten Schlössern, medizinischen Geräten und industriellen Sensoren.
Das ist kein Pech — das ist ein Muster.
In diesem Abschnitt schauen wir uns an, was die Forschungsgemeinschaft bisher herausgefunden hat: fundamentale Protokollangriffe, die Milliarden Geräte betreffen, und Produktstudien, die zeigen, wie es in der Praxis aussieht.
Protokollangriffe: Schwachstellen im Standard selbst
Die gefährlichsten Angriffe sind jene, die nicht eine einzelne schlechte App treffen, sondern den Bluetooth-Standard als Ganzes.
BlueBorne (2017)
Im September 2017 veröffentlichte das Sicherheitsunternehmen Armis einen Angriff mit dem Namen BlueBorne. Die Besonderheit: Ein Angreifer brauchte kein Pairing, keine Nutzerinteraktion, keine Verbindungsanfrage. Er musste lediglich in Bluetooth-Reichweite sein.
Der Angriff nutzte fehlerhafte L2CAP-Implementierungen in verschiedenen Bluetooth-Stacks aus und ermöglichte Remote Code Execution — das Ausführen beliebigen Codes auf dem Zielgerät, ohne dass der Nutzer etwas bemerkt.
BlueBorne: 8,2 Milliarden betroffene Geräte
CVSS-Score: 9.8 (Critical). Betroffen waren Android, Linux, Windows und iOS. Der Angriff funktionierte über Bluetooth, solange das Radio aktiviert war — Pairing oder aktive Verbindung waren nicht nötig. Für einen Angreifer, der sich in einem belebten Café oder einer U-Bahn befindet, ein erschreckend einfaches Werkzeug.
BlueBorne wurde durch Patches behoben, aber er zeigte ein grundsätzliches Problem: Bluetooth ist in einem Ausmaß verbreitet, bei dem selbst ein einzelner Stack-Fehler planetarischen Schaden anrichten kann.
KNOB Attack (2019)
Ein Jahr später beschrieben Forscher den KNOB-Angriff (Key Negotiation of Bluetooth). Er traf einen Designfehler im BR/EDR-Schlüsselaustauschprotokoll.
Stell dir vor, zwei Personen einigen sich auf einen Codeschlüssel — aber ein Dritter kann dazwischenfunken und sagen: "Nehmt einen Schlüssel mit nur einer Stelle statt acht." Genau das ist KNOB: Ein Man-in-the-Middle kann die ausgehandelte Schlüsselentropie auf 1 Byte reduzieren. Das macht Brute-Force-Angriffe in Echtzeit möglich.
KNOB: Designfehler, nicht Implementierungsfehler
CVE-2019-9506, CVSS 8.1 (High). Das Erschreckende an KNOB ist, dass es kein Bug in einer einzelnen Implementierung war — es war ein Fehler in der Spezifikation selbst. Die Bluetooth SIG musste nachträglich durch Erratum 11838 eine Mindestentropie von 7 Byte vorschreiben.
BIAS Attack (2020)
Ebenfalls 2020 zeigte die BIAS-Studie (Bluetooth Impersonation AttackS), dass ein Angreifer ein bekanntes Gerät imitieren kann, ohne den Long-Term-Pairing-Key zu kennen. Der Grund: Der BR/EDR-Standard schreibt keine obligatorische gegenseitige Authentifizierung vor.
In den Tests waren 28 von 30 untersuchten Chipsets verwundbar (CVE-2020-10135, CVSS 5.4, Medium). Ein Angreifer, der einmal weiß, welche Geräte sich normalerweise verbinden, kann sich als eines davon ausgeben.
SweynTooth (2020)
SweynTooth ist ein besonders beunruhigendes Beispiel, weil es nicht ein einzelnes Gerät oder einen einzelnen Hersteller betraf — sondern über 480 Produkte auf einmal.
Forscher entdeckten durch systematisches Fuzzing 18 Schwachstellen in BLE-SDK-Implementierungen verschiedener Chiphersteller. Die Schwachstellen reichten von Denial-of-Service (das Gerät friert ein oder startet neu) bis hin zu vollständigem Security-Bypass.
SweynTooth: Auch in medizinischen Geräten
Zu den betroffenen Produkten zählten Pacemaker und Insulinpumpen. Die FDA (die US-amerikanische Zulassungsbehörde für Medizinprodukte) veröffentlichte 2020 eine offizielle Safety Communication. Eine Schwachstelle in einem Herzschrittmacher ist kein theoretisches Problem mehr.
BrakTooth (2021)
BrakTooth (2021) beschreibt eine verwandte Schwachstellenfamilie im Bluetooth Classic LMP (Link Manager Protocol). In 13 Chipsets von 11 Herstellern nachgewiesen, ermöglicht sie unter anderem willkürliche Codeausführung auf ESP32-basierten Geräten — einem der weltweit am häufigsten eingesetzten Microcontroller in IoT-Produkten.
Attack Tree
Erkunde die wichtigsten BLE-Angriffe auf einer interaktiven Zeitleiste — klicke auf einen Eintrag für Details:
BLE-Angriffs-Timeline (2016–2025)
Produktstudien: Wie sieht es in der Praxis aus?
Protokollangriffe sind eine Sache. Aber wie sicher sind die Geräte, die Menschen heute kaufen?
Smarte Schlösser
Ho et al. analysierten 2016 fünf kommerzielle Smart Locks und dokumentierten Implementierungs- und Designfehler, die sowohl physische als auch digitale Sicherheit betrafen.
Eine neuere Studie von Piran et al. (2025) untersuchte 18 BLE-Smart-Locks. Ergebnis: 14 von 18 Geräten waren für insgesamt zehn Angriffsvektoren anfällig — darunter sieben bereits bekannte und drei neu identifizierte. Die betroffenen Produkte sind bei über 20 Millionen Nutzern im Einsatz.
Smarte Schlösser: Populär und verwundbar
Das Paradoxe: Verbraucher kaufen Smart Locks, weil sie sicherer wirken als traditionelle Schlösser. Die Forschung zeigt das Gegenteil. Ein klassisches Schloss kann man nicht über Bluetooth öffnen.
Fitness-Tracker und Wearables
Das Bild bei Wearables ist ähnlich ernüchternd. Das gilt nicht nur für alte Geräte.
- Das et al. (2016) wiesen Privacy-Leakage im BLE-Traffic von Fitness-Trackern nach — Daten wurden unverschlüsselt übertragen.
- Sivakumaran und Blasco (2023) analysierten in einer Großstudie über 17.000 BLE-Apps und stellten fest, dass über 60 % Sicherheitslücken aufwiesen.
- Claramunt et al. (2022) verglichen Wearables für Minderjährige und zeigten, dass nur wenige BLE Secure Connections mit ECDH nutzten — die Mehrheit setzte auf veraltete Legacy-Pairing-Methoden.
- Gress et al. (2025) demonstrierten, dass selbst neuere Fitness-Tracker-Modelle weiterhin fehlende gegenseitige Authentifizierung und fehlende End-to-End-Verschlüsselung aufwiesen.
Auch neuere Geräte sind betroffen
Ein verbreiteter Irrtum: "Ältere Geräte sind unsicher, neue sind es schon." Die Studie von Gress et al. aus 2025 zeigt, dass aktuelle Fitness-Tracker die gleichen Grundfehler wie ihre Vorgänger von 2014 wiederholen.
Smart-Home-Plattformen
Fernandes et al. legten 2016 Overprivilege und unzureichenden Datenschutz in der SmartThings-Plattform offen. Apps hatten Zugriffsrechte auf weit mehr Geräte und Funktionen als sie eigentlich benötigten — ein Angreifer, der eine App kompromittiert, bekommt damit automatisch Zugriff auf das gesamte Smart Home.
Firmware-Analyse im großen Maßstab
Wie sieht es aus, wenn man nicht einzelne Geräte analysiert, sondern tausende Firmware-Images automatisiert untersucht?
FIRMADYNE (Chen et al., 2016) emuliert Linux-basierte Firmware und analysierte 23.035 Images. Dabei wurden 14 zuvor unbekannte Schwachstellen identifiziert. FirmAE (Kim et al., 2020) verbesserte die Emulationsrate auf 79 % und fand 12 neue Zero-Days.
Automatisierte Firmware-Analyse
Zero-Day bedeutet: Die Schwachstelle war dem Hersteller unbekannt — sie wurde zum ersten Mal durch die Analyse entdeckt. In beiden Studien zusammen wurden also 26 neue Schwachstellen gefunden, nur durch das Analysieren von Firmware, die die Hersteller selbst veröffentlicht hatten.
Zuo et al. (2019) analysierten 18.166 BLE-Apps im Google Play Store und extrahierten 26.610 unique UUIDs. Über diese UUIDs lassen sich Geräte anhand ihrer Companion-App-Fingerprints identifizieren — ein Angriff, den wir im Guide-Bereich durch APK-Dekompilierung nachvollziehen werden.
Das große Bild: Systemisch, nicht zufällig
Schau dir die Muster an, die sich durch alle diese Studien ziehen:
- Fehlende oder schwache Authentifizierung (Smart Locks, Fitness-Tracker, Protokollangriffe)
- Schwache oder fehlende Verschlüsselung (Wearables, Smart-Home)
- Designfehler im Standard selbst (KNOB, BIAS)
- Fehler in verbreiteten SDKs und Chipsets (SweynTooth, BrakTooth)
- Sicherheitsprobleme, die sich über Jahre wiederholen (2014 bis 2025)
Eine formale Verifikation des BLE-Key-Agreement-Protokolls mittels ProVerif (Zhang et al., 2020) bestätigt das theoretisch: Legacy Pairing und insbesondere Just Works bieten strukturell keinen Man-in-the-Middle-Schutz. Das ist keine Implementierungsschwäche — das ist eine Designentscheidung.
Warum dieser Überblick wichtig ist
Der Guide in diesem Kurs baut auf genau diesen Erkenntnissen auf. Wenn du verstehst, dass fehlende Authentifizierung ein universelles Muster ist, erkennst du es sofort, wenn du Phase 2 (Traffic-Capture) durchführst und siehst, dass ein Gerät keine Pairing-Anforderung stellt.
Zusammenfassung
- BlueBorne (2017): Remote Code Execution ohne Pairing, 8,2 Mrd. Geräte betroffen, CVSS 9.8
- KNOB (2019): Schlüsselentropie auf 1 Byte reduzierbar — Designfehler im Standard
- BIAS (2020): Geräteimitierung ohne Kenntnis des Pairing-Keys, 28/30 Chipsets betroffen
- SweynTooth (2020): 18 Schwachstellen, 480+ Produkte, inkl. Pacemaker und Insulinpumpen
- Produktstudien: 60 %+ der BLE-Apps haben Sicherheitslücken, 14/18 Smart Locks verwundbar
- Fazit: Schwachstellen sind systemisch — sie resultieren aus Designentscheidungen und weit verbreiteten Implementierungsfehlern, nicht aus Einzelfällen
Wissenstest
Wie viele Byte Schlüsselentropie konnte ein Angreifer bei der KNOB Attack erzwingen?
Was machte BlueBorne besonders gefährlich?