goSecurity BLOG

Mitte August publizierten die drei Forscher Daniele Antonioli, Nils Ole Tippenhauer und Kasper Rasmussen von unterschiedlichen Universitäten (Singapur, Oxford und Helmholtz-Zentrum für Informationssicherheit in Saarbrücken) auf einer Sicherheitskonferenz in Santa Clara (Usenix) eine konzeptionelle Schwachstelle in der Bluetooth Spezifikation (CVE-2019-9506).

Das Forschertrio erläuterte dann auch, dass diese Schwachstelle seit der ursprünglichen Bluetooth-Version 1.0 besteht. Angreifern ermöglicht das Ausnutzen der Schwachstelle den Bluetooth-Datenverkehr zweier Geräte unverschlüsselt mitzuhören. Da Bluetooth weit verbreitet genutzt wird, erachte ich die Schwachstelle als potentiell sehr gefährlich. Erfahren Sie in diesem BLOG warum ich die Schwachstelle nur als „potentiell“ sehr gefährlich einstufe.

Was kann ein Angreifer tun?

Ein Angreifer kann unter Umständen sämtlichen Bluetooth-Datenverkehr zwischen zwei Geräten unverschlüsselt aufzeichnen. Noch nicht ganz klar ist, ob der Datenverkehr gezielt manipuliert werden kann (Man in the Middle). Zu den betroffenen Verbindungen gehören beispielsweise Tastatur- oder Mauseingaben (sofern über Bluetooth verbunden). Auch der Datenverkehr zwischen Laptop und Mobiltelefon (Tethering via Bluetooth) kann mitgehört werden. Das ist grundsätzlich gefährlich. Da der Datenverkehr über das Internet so oder so verschlüsselt (HTTPS / SMIME / VPN etc.) erfolgen sollte, relativiert sich die Gefährlichkeit, zumindest theoretisch. Die Verschlüsselung passiert nämlich schon auf den Endgeräten (nicht auf dem Bluetooth-Stack). Beim Tethering via Bluetooth dürfte deshalb das reine Mithören eigentlich wenig problematisch sein. Nur: Da diese End zu End Verschlüsselung nicht immer korrekt und ausschliesslich erfolgt (z.B. E-Mail-Verkehr) stufe ich diese Angriffsform als gefährlich ein.

Bedingungen

Der Angreifer muss physisch im Empfangsbereich der betroffenen Geräte sein, resp. eine entsprechende Hardware in diesem Bereich platzieren. Zudem muss der Angreifer den Verbindungsaufbau der abzuhörenden Geräte bereits aktiv manipulieren können. Achtung: Damit ist nicht (wie zum Teil fälschlicherweise publiziert) das Pairing (erste Bekanntmachung der Geräte) gemeint. Es reicht der Verbindungsaufbau beim Einschalten und Verbinden bereits gepairter Hardware.

Eine weitere Bedingung ist die Verwendung von Bluetooth-Basic-Rate (BR) oder Enhanced Data-Rate Verbindungen (EDR). Nicht betroffen ist die Bluetooth Spezifikation BLE (Bluetooth Low Energie), die gerne in batteriebetriebenen Geräten (nicht Akku) wie Pulsmessgurten verwendet wird.

Wem das jetzt nichts sagt: Bluetooth ist nicht gleich Bluetooth. Es gibt verschiedene Spezifikationen, welche auf die jeweilige Anwendung spezialisiert ist. EDR wurde als Zusatz 2004 eingeführt und BLE mit Bluetooth 4.0 im Jahre 2009.

Was genau ist das Problem?

Bei der ersten Bekanntmachung und Verbindung von zwei Bluetooth Geräten (Pairing) wird ein sogenannter Long Term Key verhandelt. Auf Basis dieses Long Term Keys wird bei jeder anschliessenden Verbindung (z.B. Einschalten des PCs und Mobiltelefons) ein Session Key abgeleitet. Der Session Key darf (gemäss Bluetooth-Protokoll) maximal 16 Byte Länge aufweisen. Viele Geräte lassen es zu, dass auch ein Session Key mit 1 Byte akzeptiert wird. Die Idee der Forscher besteht darin, dass ein Angreifer den Datenverkehr (auf Funkbasis) während der Aushandlung abschirmt und den Session Key auf 1 Byte „drückt“. Ein solch kurzer Schlüssel kann anschliessend einfach per Brute Force geknackt werden. Anschliessend kann ein Angreifer den Datenverkehr selbst mitlesen und (wiederum durch Abschirmung auf Funkbasis) möglicherweise auch aktiv manipulieren. Aufgrund aktuell verfügbarer Informationen gehe ich davon aus, dass der Long Term Key nicht geknackt werden kann. Dies bedeutet, dass der Angriff bei jedem neuen Verbindungsaufbau der Geräte neu gestartet werden muss.

Die Bluetooth Special Interest Group (SIG) empfiehlt neu nur noch Schlüssellängen mit mindestens 7 Byte zuzulassen. Zukünftig sollen diese Mindestwerte für die Zertifizierung von Geräten geprüft werden. Das nützt uns zwar für die Zukunft etwas, nicht aber für den Moment. Zudem unterstütze ich den Vorschlag der Forscher, immer das Maximum von 16 Byte einzusetzen, da auch 7 Byte etwas kurz sind.

Welche Geräte?

Die Liste betroffener Geräte ist lang und unter https://www.kb.cert.org/vuls/id/918987/ zu finden.

Was kann ich dagegen tun?

Die gute Nachricht vorneweg: Wenn Bluetooth-Geräte den Downgrade auf unsichere Werte beim Pairing nicht mehr zulassen, ist das Problem gelöst. Da auch genügend lange Schlüssel als Session Keys vorgesehen sind, lässt sich das Problem per Firmware-Update lösen. Leider sind Firmware-Updates nicht bei allen Bluetooth-Geräten so einfach. Mein BOSE-Kopfhörer kann das zwar elegant per App. Ich habe aber keine Ahnung wie ich ein Firmware Update bei meinem Polar-Herzfrequenzmessgurt machen kann… Glücklicherweise verwendet dieser nur BLE, welches ja nicht betroffen ist. Es ist also wichtig Firmware-Updates für alle Geräte durchzuführen, sobald die Hersteller die Schwachstelle gefixt haben.

VPN bei Verbindungen, welche ausserhalb der Firma initiiert werden, war schon immer eine gute Idee. Auch in diesem Fall schützt eine VPN-Verbindung, die sämtlichen Internet-Netzwerk-Verkehr routet, beim Tethering ausgezeichnet. Der Angriff auf Bluetooth ist zwar immer noch möglich, der mitgelesene Datenverkehr ist aber auf einer anderen Ebene bereits verschlüsselt.

Sicherheitskritische Vorgänge (wie Bezahlvorgänge) würde ich sicherheitshalber vorerst nicht tätigen, sofern diese Bluetooth verwenden.

Wie gefährlich ist es wirklich?

Auch das Forschertrio weist darauf hin, dass der Angriff eine gewisse Komplexität aufweist. Einerseits muss der Angreifer (oder dessen Hardware) nahe der kommunizierenden Geräte sein und den Verbindungsaufbau manipulieren können. Das dies rein auf der Funkebene passiert, müssen die Geräte auch entsprechend abgeschirmt werden. Das ist physikalisch nicht immer ganz einfach. Im Labor wird der Angriff vermutlich zuverlässig funktionieren. Ob dies in der Praxis auch der Fall sein wird, mag ich zu bezweifeln.

Dennoch ist es wichtig, dass diese Schwachstelle aufgedeckt und kommuniziert wurde. Ebenso wichtig ist es nun, dass die Hersteller rasch reagieren und bereinigte Firmware-Updates einspielen. Zuletzt ist es natürlich wichtig, dass die Updates auch ausgerollt und installiert werden.