Eine Bestandsaufnahme in Sachen Bluetooth-Sicherheit

Angriffe auf und über Bluetooth: Wie sicher ist die Bluetooth-Kommunikation?
Keine Kommentare

Die Entwickler von Bluetooth haben von Anfang an die Sicherheit ihres Protokolls im Blick gehabt. Sowohl die Authentisierung der Kommunikationsteilnehmer als auch die Verschlüsselung der Kommunikation waren bereits zu Beginn vorgesehen.

Nachdem die Nutzung von Bluetooth einen solchen Umfang angenommen hatte, dass sich sowohl Untersuchungen als auch Angriffe lohnten, wurden einige Schwachstellen in den Bluetooth-Protokollen und teilweise auch in den entsprechenden Implementierungen gefunden. Natürlich wurden diese recht schnell auch ausgenutzt. Die Schwachstellen wurden in den Implementierungen im Allgemeinen zeitnah behoben, für die Protokolle brachte das 2007 veröffentliche Bluetooth 2.1 entsprechende Fixes. Danach war dann erst einmal Ruhe. Im Herbst 2017 tauchte dann plötzlich eine Bluetooth-Schwachstelle auf, die sogar einen Namen hatte.

September 2017: Microsoft veröffentlicht eine Bluetooth-Schwachstelle

Im September 2017 veröffentlichte Microsoft Details zu einer bereits im Juli behobenen Schwachstelle im Bluetooth-Stack mit der CVE-ID CVE-2017-8628. Die Beschreibung der von Microsoft als wichtig (important) eingestuften Schwachstelle liest sich zunächst recht harmlos: „A spoofing vulnerability exists in Microsoft’s implementation of the Bluetooth stack. An attacker who successfully exploited this vulnerability could perform a man-in-the-middle attack and force a user’s computer to unknowingly route traffic through the attacker’s computer. The attacker can then monitor and read the traffic before sending it on to the intended recipient. To exploit the vulnerability, the attacker needs to be within the physical proximity of the targeted user, and the user’s computer needs to have Bluetooth enabled. The attacker can then initiate a Bluetooth connection to the target computer without the user’s knowledge. The security update addresses the vulnerability by correcting how Windows handles Bluetooth requests.“

Es handelt sich also nur um eine Spoofing-Schwachstelle. Das heißt, der Angreifer kann einen MitM-Angriff ausführen und Daten über seinen Rechner leiten. Gelingen tut dies allerdings nur, wenn der Angreifer nahe genug herankommt, um eine Bluetooth-Verbindung aufzubauen, und nur, wenn das Opfer auf seinem Rechner Bluetooth aktiviert hat.

Drei Relativierungen lassen das Szenario eher unwahrscheinlich erscheinen, was allerdings ein Trugschluss ist. Aber fangen wir hinten an. Bluetooth ist inzwischen ziemlich oft eingeschaltet. Bei Desktoprechnern, weil über Bluetooth eine drahtlose Tastatur und/oder Maus mit dem Rechner verbunden ist, bei Mobilgeräten für die Verbindung zu einem Bluetooth-Kopfhörer oder den Datenaustausch mit einem Smartphone. Und zumindest bei mobilen Geräten ist es auch gar nicht so unwahrscheinlich, dass sich ein Angreifer in Bluetooth-Funkreichweite befindet. Jedenfalls nicht, wenn das Gerät in der Öffentlichkeit verwendet wird, etwa in der Bahn, im Café, auf einer Konferenz, im Wartebereich von Bahnhof oder am Flughafen. Auch „nahe genug“ ist ziemlich relativ, denn damit sind ca. zehn Meter gemeint. Das ist nicht unbedingt das, was ich persönlich unter Nähe verstehe. Hinzu kommt das Problem, dass sich die Entfernung unter Umständen auch vergrößern lässt, aber dazu unten mehr.

BlueBorne – MitM-Angriffe auf die Internetverbindung von Windows

Noch schlimmer sieht es beim nur möglichen MitM-Angriff aus. Die Schwachstelle wurde von Forschern von Armis entdeckt und gehört zu einer Gruppe von Bluetooth-Schwachstellen, genannt BlueBorne. Und die haben mehr darüber veröffentlicht als Microsofts mit seinen vagen Aussagen.

Die Schwachstelle befindet sich zwar im Bluetooth-Stack und wird über Bluetooth ausgenutzt, der MitM-Angriff betrifft aber die gesamte Kommunikation des Opfers. Der Angreifer kann über die Schwachstelle ein bösartiges Netzwerkinterface auf dem Gerät anlegen, das IP-Routing umkonfigurieren und das Gerät dadurch zwingen, die gesamte Netzwerkkommunikation über den MitM zu leiten. Er sitzt also nicht nur in einer Bluetooth-Verbindung, sondern direkt in der Internetverbindung seines Opfers. Außerdem benötigt der Angriff keine Benutzerinteraktion, keine Authentifizierung und kein Pairing, er ist also quasi unsichtbar. Ein Video des Angriffs gibt es auf YouTube.

Microsoft ist mit seiner MitM-Schwachstelle dabei noch relativ gut weggekommen, denn Code konnten die Forscher über Bluetooth unter Windows nicht einschleusen, ganz anders als bei Android und Linux.

BlueBorne im Überblick

Die Forscher von Armis haben ihrem Angriff den Namen „BlueBorne“ gegeben, weil er sich über die Luft verbreitet (auf Englisch „airborne“) und Geräte über Bluetooth angreift. BlueBorne-Angriffe sind unabhängig von Benutzeraktionen, bestimmten Systemversionen oder -konfigurationen. Es reicht zunächst, wenn Bluetooth auf dem angegriffenen Gerät aktiviert ist. Dann suchen die Geräte ständig nach eingehenden Verbindungsanfragen beliebiger Geräte und nicht nur von denen, mit denen es bereits ein Pairing gibt. Und wenn eine Anfrage kommt, ist die Kommunikation auch ohne Pairing möglich.

API Conference 2019

Oliver Drotbohm

REST Beyond the Obvious – API Design for Ever Evolving Systems

mit Oliver Drotbohm (Pivotal Software, Inc.)

Arne Limburg

API-Kompatibilität durch Consumer-Driven Contracts

mit Arne Limburg (OPEN KNOWLEDGE GmbH)

Microservices Summit 2019

Kubernetes Kickstarter

mit Jörg Müller (INNOQ)

In 7 Schritten zum Cloud-Native mit AWS

mit Matthias Rosenstock und Christian Schulz (OPEN KNOWLEDGE)

Die Schwachstellen in den Bluetooth-Protokollen wurden wie schon erwähnt in Version 2.1 behoben. Die Armis-Forscher haben sich daher die verschiedenen Implementierungen angesehen und sind dabei auf Schwachstellen gestoßen. Bluetooth ist ein schwierig zu implementierendes Protokoll, was zu zwei Problemen führt:

  1. Die Hersteller folgen den Richtlinien zur Implementierung Wort für Wort, was dazu führt, dass es eine in der Implementierung eines Herstellers vorhandene Schwachstelle mit ziemlich hoher Wahrscheinlichkeit auch identisch oder ähnlich in anderen Implementierungen gibt. In diesem Fall trifft das auf die obige Windows-MitM-Schwachstelle zu, die einen „Zwilling“ in Android hat.
  2. Einige Bereiche der Bluetooth-Spezifikation lassen zu viel Raum für Interpretationen, sodass die Wahrscheinlichkeit für unterschiedliche Implementierungen und dadurch unterschiedliche Schwachstellen darin steigt.

Der Angriff im Überblick

Ein BlueBorne-Angriff erfolgt in mehreren Schritten. Zuerst sucht der Angreifer in seiner Umgebung nach aktiven Bluetooth-Verbindungen. Die Geräte können auch dann identifiziert werden, wenn sie sich nicht im Discoverable-Modus befinden. Danach fragt der Angreifer die individuelle MAC-Adresse des Geräts ab und prüft, welches System auf dem Gerät läuft.
Je nach System wird dann die auszunutzende Schwachstelle und damit der passende Exploit ausgewählt. Der Angreifer hat bei Android-Geräten die Wahl zwischen einem MitM-Angriff auf die gesamte Kommunikation des Opfers und der vollständigen Kompromittierung des Geräts, Linux-Geräte können ebenfalls kompromittiert werden, und auf Windows-Geräten sind die obigen MitM-Angriffe möglich.

Betroffene Betriebssysteme

Amris hat insgesamt acht Schwachstellen entdeckt, und die Forscher befürchten, dass das nur die Spitze eines Eisbergs ist. Die gefundenen Schwachstellen wurden an die betreffenden Entwickler gemeldet und inzwischen behoben. Was allerdings nicht ganz problemlos ablief, da es einmal mehr einen Hersteller gab, der sich um die Meldungen nicht scherte: Samsung. Das Unternehmen wurde im April, Mai und Juni 2017 kontaktiert und hat nie reagiert. Vermutlich waren einige Leute ziemlich überrascht, als sie am dann am 12. September im Rahmen der koordinierten Veröffentlichung der Schwachstellen davon erfuhren.

Android: Alle mit Android betriebenen Smartphones, Tablets und Wearables (mit Ausnahme von Geräten, die ausschließlich Bluetooth Low Energy verwenden) sind unabhängig von der Android-Version von vier Schwachstellen betroffen. Zwei davon sind Pufferüberlaufschwachstellen im Bluetooth Network Encapsulation Protocol (BNEP) und erlauben das Einschleusen von Schadcode (CVE-2017-0781 und CVE-2017-0782). Eine weitere Schwachstelle befindet sich im Service Discovery Protocol (SDP) und führt zu einem Datenleck (CVE-2017-0785). Die vierte Schwachstelle befindet sich im Bluetooth-Profil für das Personal Area Network (PAN Profile) und erlaubt, genau wie die oben beschriebene Schwachstelle in Windows, MitM-Angriffe auf die gesamte Kommunikation (CVE-2017-0783). Unter den betroffenen Geräten sind z. B. Google Pixel, Samsung Galaxy, Samsung Galaxy Tab, die LG Watch Sport und das Pumpkin Car Audio System. Google hat den Android-Partnern am 7. August 2017 einen Patch zur Verfügung gestellt, der auch Bestandteil des am 4. September veröffentlichten Security-Updates ist. Armis hat zudem einen Scanner veröffentlicht, mit dem Sie prüfen können, ob Ihre Android-Geräte betroffen sind.

Windows: Alle Windows-Versionen ab Vista sind von der oben beschriebenen „Bluetooth Pineapple“-Schwachstelle betroffen, die MitM-Angriffe erlaubt (CVE-2017-8628). Die Schwachstelle kann natürlich nur auf Rechnern ausgenutzt werden, die Bluetooth unterstützen. Gepatcht wurde sie nur in den noch unterstützten Windows-Versionen, also ab Windows 7 SP1. Für Vista gibt es keinen Patch.

Linux: Alle Linux-Geräte mit BlueZ (dem nativen Bluetooth-Stack von Linux) enthalten eine Schwachstelle im SDP-Server, die zu einem Informationsleck führt (CVE-2017-1000250). Darüber können Teile des Bluetooth-Speichers ausgespäht werden, die z. B. die von Bluetooth verwendeten Schlüssel enthalten. Alle Geräte mit einem Linux-Kernel ab der im Oktober 2011 veröffentlichten Version 3.3-rc1 enthalten eine Pufferüberlaufschwachstelle im Logical Link Control and Adaptation Layer Protocol (L2CAP), die das Einschleusen von Code erlaubt (CVE-2017-1000251). Zu den betroffenen Geräten gehören z. B. die Smartwatch Samsung Gear S3, Samsung Smart TVs und der „Smarte“ Kühlschrank Samsung Family Hub. Patches für beide Schwachstellen wurden veröffentlicht und an die Upstream-Projekte weitergeleitet. Die Linux-Distributionen haben mit der Verteilung der Updates begonnen.

iOS: Alle iPhone-, iPad- und iPod-Touch-Geräte mit iOS 9.3.5 und niedriger und alle AppleTV-Geräte mit iOS Version 7.2.2 und niedriger enthalten eine Pufferüberlaufschwachstelle im Low Energy Audio Protocol (LEAP), die das Einschleusen von Code erlaubt (CVE-2017-14315). Die Ausnutzung der Schwachstelle ist möglich, sofern Bluetooth eingeschaltet ist, die Zugriffskontrolle hat keine Wirkung. Apple hat die Schwachstelle bereits in iOS 10 behoben, sodass hier kein neuer Patch nötig ist.

Bluetooth auf den Sicherheitskonferenzen

BlueBorne hat in den Medien ziemlich viel Aufmerksamkeit bekommen, da es mit einem schönen Namen und entsprechenden Marketingmaßnahmen gepusht wurde. Darüber hinaus war die Sicherheit von Bluetooth aber auch immer wieder Thema auf unterschiedlichen Sicherheitskonferenzen. Nicht immer, aber immer mal wieder. Die Quellen [1] bis [14] bieten ein Portfolio ausgesuchter Talks und Videos von Sessions, die sich mit der Sicherheit von Bluetooth befassen.

Fazit

Es sieht fast so aus, als würde Bluetooth überwiegend für zwei Zwecke genutzt: Zum einen für den Anschluss von Tastatur, Maus und Kopfhörern, zum anderen für die Steuerung von IoT-Geräten, vor allem Schlössern. Und in beiden Bereichen wimmelt es nur so von Schwachstellen. Im ersten Fall in der Bluetooth-Implementierung, im zweiten in der Bluetooth-Nutzung.

Da Bluetooth schwierig zu implementieren ist, dürften die BlueBorne-Schwachstellen tatsächlich nur die Spitze eines Eisbergs sein. Auch wenn davon dann eigentlich inzwischen mehr zu sehen sein müsste. Wahrscheinlich hat also nur noch niemand weiter nachgebohrt, wie es mit der Sicherheit der Bluetooth-Implementierungen aussieht.

Das IoT ist zugegebenermaßen auch ein viel interessanteres Forschungsgebiet, in dem sich die Entwickler beim Einbau von Schwachstellen scheinbar gegenseitig übertrumpfen wollen. Und das kann man nicht auf die schwierig zu implementierenden Bluetooth-Protokolle schieben, denn die müssen ja nur genutzt werden. Und dass man z. B. seine Requests vor Replay-Angriffen schützt, sollte einerseits selbstverständlich sein und andererseits auch von jedem Entwickler durchgeführt werden können. Dass es trotzdem so viele Schwachstellen gibt, lässt sich eigentlich nur mit Nachlässigkeit erklären: Die Geräte des IoT sollen schnell auf den Markt, und wenn sie mit den richtigen Eingaben laufen wie erwartet, ist alles bestens. Auf den eigentlich wichtigeren Teil, den Schutz vor absichtlich falschen Daten, verzichtet man dann anscheinend gern.

Das ist sehr kurzfristig gedacht, denn wenn ein Hersteller erst einmal den Ruf hat, unsichere Geräte zu verkaufen, dürfte das den Verkauf eben dieser Geräte ziemlich schwierig machen. Vor allem, wenn es dabei um sicherheitsrelevante Geräte wie Schlösser handelt, und um so mehr, wenn man zuvor mit der Sicherheit eben dieser Schlösser geworben hat. Es ist daher unverständlich, wieso man nicht konsequenter auf die Sicherheit achtet.

Links und Literatur

[1] Seri, Ben; Vishnepolsky, Gregory; Black Hat Europe 2017: „BlueBorne – A New Class of Airborne Attacks that can Remotely Compromise Any Linux/IoT Device“; Video; GitHub: ArmisSecurity/blueborne – „PoC scripts demonstrating the BlueBorne vulnerabilities“
[2] Jasek, Slawomir; HitB Amsterdam 2017: „HITB Lab: Blue Picking: Hacking Bluetooth Smart Locks“
[3] Michalevsky, Yan; Black Hat Asia 2017: „MASHaBLE: Mobile Applications of Secret Handshakes Over Bluetooth LE“; Video;
GitHub: ymcrcat/MASHaBLE – „Mobile Applications of Secret Handshakes over BLE“
[4] Ray; 33C3: „Lockpicking in the IoT …or why adding BTLE to a device sometimes isn’t smart at all“; Medien
[5] Rose, Anthony; Ramsey, Ben; DEF CON 24: „Picking Bluetooth Low Energy Locks from a Quarter Mile Away“; Präsentation; Aktualisierte Präsentation; Video; GitHub: merculite/BLE-Security – „Hacking Bluetooth Low Energy Locks“
[6] Zero_Chaos, Granolocks; DEF CON 24: „Realtime Bluetooth Device Detection with Blue Hydra“; Präsentation; Aktualisierte Präsentation; Video; GitHub: pwnieexpress/blue_hydra – „Blue Hydra“
[7] follower; goldfisk; DEF CON 24: „Breaking the Internet of Vibrating Things : What We Learned Reverse Engineering Bluetooth- and Internet-Enabled Adult Toys“; Website „Private Play Accord“; Präsentation; Video
[8] Bugher, Grant; DEF CON 22: „Detecting Bluetooth Surveillance Systems“; Präsentation; Aktualisierte Präsentation; Video
[9] Jasek, Slawomir; Black Hat USA 2016: „GATTacking Bluetooth Smart Devices – Introducing a New BLE Proxy Tool“; Video; GitHub: securing/gattacker „A Node.js package for BLE (Bluetooth Low Energy) security assessment using Man-in-the-Middle and other attacks“; GATTack.io
[10] Beccaro, Matteo; Collura, Matteo; DEF CON 23: „Extracting the Painful (blue)tooth“; Präsentation; Video
[11] Ossmann, Michael; Black Hat USA 2015: „The NSA Playset: A Year of Toys and Tools“; Video; NSA Playset; NSA Playset: TINYALAMO (BT)
[12] Ryan, Mike: Hack in the Box Malaysia 2014: „The NSA Playset: Bluetooth Smart Attack Tools“
[13] Cohen, Joseph Paul; DEF CON 21: „Blucat: Netcat For Bluetooth“; Präsentation; Video; SourceForge: Blucat (netcat for Bluetooth); GitHub: ieee8023/blucat – „Blucat (netcat for Bluetooth)“
[14] Ryan, Mike; Black Hat USA 2013: „Bluetooth Smart: The Good, The Bad, The Ugly, and The Fix!“; Video


Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -