Bluetooth

Um die Sicherheitsrisiken des Bluetooth-Einsatzes darstellen zu können, muss zunächst kurz der Bluetooth-Standard dargestellt werden.

Bluetooth-Standard

Die unterste Schicht (Bluetooth Radio) ist für die eigentliche Datenübertragung per Funk zuständig. Darauf setzt das Baseband auf, das für die Übertragung von Daten über die Funkschicht zuständig sit und hierzu den physikalischen Übertragungskanal realisiert. Der darauf aufsetzende Link Controller konfiguriert und kontrolliert die Verbindungen zu anderen Geräten, kann neu hinzugekommene Geräte erkennen und stellt die kryptographischen Sicherheitsmechanismen zur Authentifizierung und Verschlüsselung bereit. Bluetooth verwendet hier einen 128-Bit-Block-Cipher, den safer+-Algorithmus. Der Link Manager Layer kommuniziert über das Link Manager Protocol (LMP). Das über dem Link Manager Layer gelegene Host Controller Interface (HCI) ist die Schnittstelle zwischen den oberen und unteren Protokollschichten und ermöglicht die Kommunikation zwischen einem Bluetooth-Host und einem Bluetooth-Modul.
Mit Radio Frequency Communication (RFCOMM) können serielle (RS-232-) Schnittstellen simuliert werden. RTFCOMM definiert aber auch die Punkt-zu-Punkt-Verbindun zwischen zwei Bluetooth-Geräten über die „serielle Schnittstelle Luft“. Daher werden auch TCP/IP-Verbindungen über das serielle Point-to-Point Protocol (PPP) über RFCOMM realisiert. Telephony Control Protocol Specification Binary (TCS BIN) stellt Funktionen zur Anrufkontrolle bereit. Das Service Discovery Protocol (SDP) bietet Suchdienste für andere Geräte an. Hiermit werden die zur Verfügung stehenden Dienste abgefragt und auf diesem Resultat aufbauend eine Verbindung aufgebaut. Object Exchange (OBEX) ist ein Protokoll der Applikationsebene (Application Layer) im Bluetooth Protokollstack. Das Protokoll wurde aus dem Infrared Data Association (IrDA)-Standard für die Infrarotverbindungen übernommen und ermöglicht den Austausch von Objekten und modelliert auch die Strukturierung von Dialogen zwischen den Objekten. Abbildung 1 zeigt den Schichtaufbau des Bluetooth-Protokollstacks in der Übersicht.

Abbildung 1: Schicht-Aufbau des Bluetooth-Protokolls

Im Bluetooth-Standard wird festgelegt auf welche Weise Anwendungssoftware auf die verschiedenen Ebenen des Protokollstapels zugreifen darf. Dies wird durch die Nutzung von sogenannten „Profilen“ erreicht. Die Bluetooth Special Interest Group (SIG) hat zur besseren Interoperabilität Anwendungsprofile definiert, z.B. das Dialup-Networking Profile (DUN) oder das Headset Profile (HSP)1). Die Profile stellen im Prinzip ein Application Programming interface (API) dar, so dass Programme unterschiedlicher Hersteller auf verschiedenen Geräten problemlos miteinander kommunizieren können.

Bluetooth-Kommunikation

Für den Verbindungsaufbau nutzt Bluetooth initial zwei Prozesse: Inquiry und Paging. Während des Inquiry kann ein Bluetooth-Gerät feststellen, ob sich andere Geräte in Sendereichweite befinden und erhält die entsprechenden Adressen und Zeittakte der gefundenen Geräte. Durch eine anschließende Paging-Aufforderung wird eine Kommunikationsverbindung zwischen den Geräten aufgebaut.
Das die Verbindung initiierende Gerät wird zum Master, das andere zum Slave. Die lokale Zusammenfassung einer Reihe von Bluetooth-Geräten, die gemeinsam einen Kanal verwenden, ergibt ein Piconet (siehe Abbildung 2). Ein Piconet enthält einen Master und bis zu sieben aktiven Slaves. Ist ein Bluetooth-Gerät in dem einen Verbund ein Slave in einem anderen jedoch ein Master, so werden die beiden Piconets miteinander verbunden; man spricht dann von einem sich überlappenden Piconet, dem Scatternet (Abbildung 2). Neben aktiven Slaves kann es auch passive Slaves geben, so genannte „geparkte Geräte“. Allerdings übertragen nur aktive Geräte Daten.

Abbildung 2: Piconet- bzw. Scatternet-Aufbau

Die vom HCI bereitgestellten kryptographischen Sicherheitsmechanismen sichern die Kommunikation zwischen dem Link Manager und dem eigentlichen Protokollstack ab, d.h. der HCI stellt eine Art „Trennung“ dar (Abbildung 1). Die Absicherung beruht auf der Verwendung von Verbindungsschlüsseln (Link-Keys), die nur für die Verbindung zwischen zwei Geräten genutzt werden. Der Link-Key besteht aus der Geräteadresse sowie einer geheimen Zufallszahl, die gesichert überragen werden muss. Zu dieser Übertragung wird eine weitere öffentliche Zufallszahl verwendet, die aus der Geräteadresse und einer bis zu 16 Byte langen PIN besteht. Die PIN gibt der Nutzer ein oder sie ist fest vorkonfiguriert. Letzteres ist typischerweise bei Headsets der Fall. Eine vom Hersteller fest vorgegebene, nicht änderbare PIN verringert natürlich die Sicherheit der Kommunikation hinsichtlich der Vertraulichkeit, Integrität, Verbindlichkeit und Authentizität der übertragenen Daten. Während des Pairing wird nach der Authentifizierung der Geräte und der PIN-Eingabe der Link-Key generiert und zwei Bluetooth-Geräte können nun verschlüsselt miteinander kommunizieren. Die Verschlüsselung ist optional und kann immer dann genutzt werden, wenn sich ein Gerät gegenüber einem anderem authentifiziert hat. Die Verschlüsselung verwendet ein Stromchiffre-Verfahren, welches im Standard E0 genannt wird. Die Reichweite von Bluetooth hängt von der Übertragungsleistung der eingesetzten Geräte ab und wird in drei Sendeleistungsklassen eingeteilt2):

Bluetooth-Klasse Max. Leistung
(mW)
Max. Leistung
(dBm)
Reichweite in m
(im Freien)
110020~ 100
22,54~ 20
310~ 10

Ist ein Angreifer jedoch mit einer Antennenverstärkung, können auch Signale von einem weit entfernten Platz empfangen werden. Je nach verwendeter Ausrüstung wurden schon Entfernungen bis zu einem Kilometer überwunden3).

Bluetooth-Sicherheit

Für Linux gibt es diverse Programme, mit denen die Bluetooth-Kommunikation untersucht werden kann und die schon in der Backtrack-Cd integriert sind. Seit 2012 wird Backtrack allerdings nicht mehr weiterentwickelt, der Nachfolger ist Kali-Linux, das im folgenden zur Backtrack-Distribution Gesagte kann 1:1 auf die Kali-Distribution übertragen werden.
Das HCI-Tool kann als eine Art „Schweizer Messer“ im Umgang mit Bluetooth angesehen werden:

+ es durchsucht die Umgebung nach Bluetooth-fähigen Geräte
+ es listet die gefundenen Adressen auf
+ es ermöglicht die Bluetooth-Sitzung mittels eines Dump zu sichern

Die Hilfsfunktion zeigt die Möglichkeiten des Werkzeugs auf, welches über die Kommandozeile bedient wird. Mit dem Befehl „hcitool scan“ wird die Umgebung nach Bluetooth-Geräten abgesucht und die von den gefundenen Geräten angegebene Netzwerkadresse angezeigt. Mittels des Befehls „rfcomm bind Netzwerkadresse 17“ kann beispielsweise zu einem gefundenen Handy ein neues RFCOMM-Terminal-Device auf Kanal 17 erzeugt werden. Kanal 17 erlaubt eine Verbindung zum AT-Parser ohne Authentifizierung und Verschlüsselung. Mitteles des Terminalprogramms XMinicom können AT-Befehle an das verbundene Bluetooth-Gerät übergeben werden und anschließend über entsprechende Kommandos entsprechend der ETSI-Spezifikation z.B. Telefonbucheinträge angezeigt werden4).
Eine andere Angriffsmöglichkeit ist eine sogenannte „Bluesnarf“-Attacke. Bei einer „Snarf“-Attacke wird eine Information ohne Einverständnis des jeweiligen Eigentümers eingesehen. Normalerweise kann dieser Angriff im Umkreis von 10 Metern ausgeführt werden, es wurden aber auch schon Distanzen bis zu einem Kilometer überbrückt5). Für diese Art des Zugriffs ist keine Kopplung der Geräte erforderlich, daher ist auf dem angegriffenen Gerät auch nicht zu sehen, welche Daten ausgelesen wurden. Zu bemerken istz allerdings, dass hierbei eher eine fehlerhafte Implementierung als ein Fehler im Bluetooth-Standard ausgenutzt wird: bei einigen Implementierungen erfolgt bei einer Kommunikation über bestimmte RFCOMM-Kanäle nie die Nachfrage nach PIN oder Link-Key. Dieser gewinn beim Bedienungskomfort der Anwender, z.B. beim Austausch von elektronischen Visitenkarten, geht natürlich auf Kosten der Sicherheit.
Auf der Backtrack-CD bietet sich das Programm Obexftp für einen Bluesnarf-Angriff an. Da das OBEX-push-Profil für den Austausch von Visitenkarten keine Authentifizierung erfordert, kann hierüber das vollständige Telefonbuch ausgelesen werden. Mittels des Befehls „sdptool search –bdaddr Netzwerkadresse opush“ wird der RFCOMM-Kanal, der dem OBEX-Push-Profil zugeordnet ist, ausgelesen. Bei Nokia-Handys ist dies in der Regel Kanal 9, bei Sony-Ericson Kanal 10. Über den Befehl „obexftp –b Netzwerkadresse –B 10 –g telecom/pb.vcf“ wird nun eine Anfrage bezüglich der Datei „telecom/pb.vcf“ ausgeführt. Das OBEX-push-Profil führt diese Anfrage aus und übermittelt das komplette Telefonbuch im vCard-Format. Andere Anfrage sind natürlich auch möglich, beispielsweise „telecom/cal.vcs“ für die Kalenderdaten oder „telecom/devinfo.txt“ für gerätespezifische Informationen.


Zurück zur Themenübersicht

1) Bluetooth Special Interest Group (SIG): Bluetooth Wireless Technology Profiles. [Online]. 2006 [zitiert 2006-10-29]; Verfügbar unter http://bluetooth.com/Bluetooth/Learn/Works/Profiles_Overview.htm
2) Zivadinovic D. Wetmeisterlich - Bluetooth-USB-Adapter mit großer Reichweite. [Online]. 2006 [zitiert 2006-10-29]; Verfügbar unter http://www.heise.de/mobil/artikel/54030/0
3) , 5) Outmesguine M. 1 Kilometer World Record Bluetooth Link? [Online]. 2004 [zitiert 2006-10-29]; Verfügbar unter http://www.thewirelessreport.com/2004/07/30/1-kilometer-world-record-bluetooth-link
4) ETSI [Online]. 2006 [zitiert 2006-10-29]; Verfügbar unter http://www.etsi.org

Navigation
QR-Code
QR-Code Bluetooth (erstellt für aktuelle Seite)