© photocase.com

Fast jeder neue Laptop oder PDA und so gut wie jedes Mobiltelefon hat Bluetooth an Bord. Nur wenige Nutzer aber wissen, wie leicht auf diesem Weg Angreifer an ihre Daten gelangen.

Erinnern Sie sich noch an den freundlichen jungen Mann im schicken Anzug, der Ihnen heute Morgen in der S-Bahn gegenübersaß und während der ganzen Fahrt in seinen Laptop tippte? Eine Station vor Ihnen ist er ausgestiegen. Jetzt weiß er von Ihrem Arzttermin morgen Nachmittag. Er kennt die Nummer Ihrer Freundin. Die SMS, die Ihnen ein Kollege gestern nach dem Meeting sandte, hat er eben gelesen – alle anderen Nachrichten, Termine und Rufnummern auf Ihrem Handy auch. Den Termin für die Besprechung mit Ihrem Chef übermorgen hat er übrigens eine Stunde nach hinten verschoben. Den Alarm dazu auch. So kommen Sie zu spät und können den vakanten Job vergessen, für Kunze ist das Ganze ein riesen Spaß.

Die Geschichte ist natürlich frei erfunden, aber keineswegs aus der Luft gegriffen. Denn die meisten ahnen nicht einmal, wie leicht sich gerade von Handys via Bluetooth Daten stehlen oder manipulieren lassen. Und zwar so, dass der Angriff völlig unbemerkt bleibt.

Seit der Einführung durch die Bluetooth Special Interest Group (SIG, [1]) im Jahre 1998 hat Bluetooth als Kommunikationsmittel massenhafte Verbreitung erlangt. Mittlerweile kommt es nicht nur in Handys und den entsprechenden Headsets und Car-Kits zum Einsatz, sondern findet auch beim drahtlosen Anschluss von Druckern, Mäusen oder auch in Accesspoints Anwendung. Sogar Bluetooth-TV-Adapter sind im Handel, die Bilder, Multimedia-Messages (MMS) oder auch MP3-Songdateien auf den Fernseher übertragen. Leicht lassen sich noch weitere Anwendungsmöglichkeiten vorstellen.

Protokollstapel

Um die Sicherheitsrisiken bei Bluetooth richtig verstehen und einschätzen zu können, ist ein kurzer Ausflug in die Theorie nötig. Abbildung 1 zeigt den Aufbau des Bluetooth-Protokollstack. Über den Ebenen, die für die Parameter der Funkverbindung und die physikalische Übertragung zuständig sind – Bluetooth Radio und Baseband -, findet sich der Link Manager Layer (Link Manager Protocol, LMP). Er ist für das Verbindungsmanagement zuständig und stellt auch die kryptographischen Sicherheitsmechanismen zur Authentifizierung und Verschlüsselung bereit.

In dieser Schicht ist der von Bluetooth verwendete SAFER+-Algorithmus – ein 128-Bit-Block-Cipher – implementiert. Das darüber liegende Host Controller Interface (HCI) trennt die Hardware-nahen Schichten von der eigentlichen Protokollebene ab.

Für bessere Interoperabilität hat die Bluetooth-SIG so genannte Anwendungsprofile definiert. Neben grundlegenden Diensten wie dem Generic Access Profile (GAP), dem Serial Port Profile (SPP) oder dem Dialup-Networking Profile (DUN) gibt es auch ein Headset Profile (HSP) und viele weitere. Die Profile sind von der engeren Bluetooth-Spezifikation (dem Core) entkoppelt.

Auf einer Wellenlänge

Am Verbindungsaufbau sind bei Bluetooth zwei Prozesse beteiligt: Inquiry und Paging. Während des Inquiry kann ein Bluetooth-Gerät feststellen, ob sich andere Geräte in seiner Sendereichweite befinden. Die Prozedur liefert alle Adressen und Zeittakte der gefundenen Geräte. Durch eine anschließende Paging-Anforderung baut ein Gerät dann eine Kommunikationsverbindung zu einem anderen auf. Das Gerät, das die Verbindung initiiert, wird zum Master, das andere zum Slave.

Die lokale Zusammenfassung einer Reihe von Bluetooth-Devices, die gemeinsam einen Kanal verwenden, ergibt ein so genanntes Piconet. In ihnen gibt es immer nur einen Master und bis zu sieben aktive Slaves. Neben den aktiven Slaves kann es weitere passive geben (geparkte Geräte). Die Anzahl dieser Slaves wird durch den verfügbaren Speicher auf dem Bluetooth-Chip eingeschränkt. Heutige Chips unterstützen in der Regel allerdings nur sieben Slaves – in diesem Fall ist es egal, ob sie aktiv oder passiv am Piconet teilnehmen.

Sicherheitsvorkehrungen

Wie bei jedem funkbasierten Verfahren besteht auch bei Bluetooth die Möglichkeit, den Datenverkehr abzuhören oder sich aktiv in die Kommunikation einzuschalten. Allerdings findet beispielsweise im Unterschied zur WLAN-Technologie keine Kommunikation zwischen Geräten statt, solange sie kein gemeinsames Piconet bilden. Mit anderen Worten: Bluetooth-Geräte ohne aktive Verbindung übertragen auch keine Daten.

Abbildung 1: Der Aufbau der Schichten bei Bluetooth. Das Host Controller Interface schirmt die grundlegenden Schichten für die Funkverbindung, physische Datenübertragung und Verschlüsselung vom klassischen Netzwerk-Protokollstack ab.

In der Bluetooth-Spezifikation sind kryptographische Sicherheitsmechanismen vorgesehen, die, vom HCI bereitgestellt, die Kommunikation des Link-Managers und des Protokoll-Stack absichern. Basis dieses Verfahrens sind Verbindungsschlüssel, die Link-Keys. Das sind 128 Bit lange Combination-Keys, die in der Regel nur für die Verbindung zwischen zwei Geräten genutzt und dort gespeichert werden. In sie gehen die Geräteadresse und eine geheime Zufallszahl ein, die gesichert zu übertragen ist.

Dazu bedient sich jedes Gerät einer weiteren, öffentlichen Zufallszahl, der Geräteadresse und einer bis zu 16 Byte langen PIN. Die PIN gibt der Nutzer ein oder sie ist fest vorkonfiguriert, was häufig bei Headsets der Fall ist. Letzteres hat die direkte Konsequenz, dass es unmöglich ist, zwei verschiedene Geräte mit fester PIN zu paaren.

Wollen zwei Geräte verschlüsselt kommunizieren, müssen sie sich erst authentifizieren und einen Link-Key generieren. Das geschieht während des Pairing. Hierfür wird der PIN-Code benötigt. Ist ein Link-Key erzeugt, reicht er für jede weitere Authentifizierung aus.

Die beschriebene Verschlüsselung ist optional – eine der Schwächen der Bluetooth-Spezifikation. Sie kommt immer dann in Frage, wenn sich mindestens ein Gerät gegenüber dem anderen authentisiert hat. Die Verschlüsselung benutzt eine Stromchiffre, das so genannte E0-Verfahren.

Zahnbohrer

Trotz dieser Bemühungen um die Sicherheit von Bluetooth, finden Hacker Angriffspunkte, aus denen ernste Gefahren erwachsen. So lassen sich zum Beispiel Anrufe auf dem Opfer-Handy triggern, die etwa über 0190er Nummern entsprechend hohe Kosten (und damit einen hohen Gewinn beim Angreifer) verursachen. Nutzt der Hacker den GPRS-Datendienst über das gekaperte Telefon, erhält er einen für ihn kostenlosen Internetzugang, über den er unerkannt und unter der Identität des ahnungslosen Opfers Spam oder Malware verschicken kann. Auch SMS-Dienste lassen sich entsprechend missbrauchen, sei es nun per Anruf eines kostenpflichtigen Premium-Dienstes oder durch Versenden von Spam-SMS bis hin zu DoS-Angriffen (SMS-Bombing).

Neben diesen immer ärgerlichen und oft teuren Angriffen sind aber meist auch die auf dem Mobiltelefon oder dem PDA gespeicherten Kontaktdaten ein lohnendes Ziel. Termine, Telefonbucheinträge, SMS – die im Zeitalter des Onlinebanking sogar Transaktionsnummern enthalten können -, alles das fällt gewitzten Dieben via Bluetooth in die Hände. Dabei lassen sich verschiedene Angriffsarten unterscheiden.

Die bekanntesten heißen Bluejack, Bluesnarf und Bluebug. Beim Bluejacking geht es in erster Linie darum, Nachrichten an ein fremdes Mobiltelefon zu schicken. Bluesnarfing leitet sich von einem Slang-Ausdruck für das Anfertigen einer nicht autorisierten Kopie ab. Bei dieser Form lädt der Hacker Daten des Mobiltelefons, etwa Einträge im Telefonbuch oder im Kalender, SMS-Nachrichten oder gespeicherte Bilder herunter.

Bluebugging schließlich bietet vollen Zugriff auf die AT-Kommandos des Mobiltelefons und erlaubt es damit, SMS und E-Mails zu senden und zu empfangen sowie Telefongespräche zu führen. Neben diesen bekannten Angriffen gibt es noch eine ganze Reihe weitere.

In letzter Zeit ebenfalls wichtig geworden sind die Attacken, die Bluetooth auch aus großer Entfernung angreifbar machen, die Long Distance Attacks. Dabei sind mit entsprechendem technischen Aufwand durchaus Entfernungen von mehreren hundert Metern bis zu 1,2 Kilometer möglich, selbst Standardgeräte haben meist eine Reichweite von etwa 40 Metern. Das ermöglicht auch Angriffe auf vorbeifahrende Autos. Bei diesem Car-Whispering – also dem Mithören und Mitschneiden der Sprachdaten, die Mobiltelefon und Headset austauschen – fängt zum Beispiel auf einer Autobahnbrücke positioniertes Equipment die Signale auf.

Abbildung 2: Wenige Kommandos reichen aus, um ein Telefonbuch zu stehlen.

Dabei nutzt der Angreifer den Umstand aus, dass viele Telefone oder auch Car-Kits eine Standard-PIN benutzen, die allgemein bekannt ist. In den meisten Fällen ist das »0000«. Ist ein solches Gerät dauerhaft sichtbar, kann man sich einfach mit dem Telefon oder dem Car-Kit verbinden und das Headset-Profil ausführen. Die Authentifizierung und Verschlüsselung wird hierbei nicht umgangen, sondern einfach mit Hilfe der Standard-PIN aktiviert.

Bluetooth und Linux

Alle im Folgenden gezeigten Angriffe setzen den Bluetooth-Stack von Linux ein. Er ist unter dem Namen Bluez seit Kernel 2.4.6 fester Bestandteil von Linux. Alle zeitgemäßen Distributionen bringen einen solchen aktuellen Stack und auch die notwendigen Tools bereits mit. Zusätzlich sollten die Pakete »bluez-utils«, »obexftp« und »cu« beziehungsweise »minicom« installiert sein.

So ausgerüstet kann der Angreifer – aber auch ein Sicherheits-Tester – die Bluesnarf- und Bluebug-Schwachstellen aufspüren. Zuerst sucht er die Umgebung nach Bluetooth-Geräten ab. Dies bewerkstelligt etwa das Kommando »hcitool«:

# hcitool scan
Scanning ...
00:0E:6D:10:1D:B6   Nokia 6310i
00:05:7A:01:A3:80   Airbus A380
00:06:6E:21:69:C2   Bluespoon AX
00:0F:DE:6C:61:04   T610

Abbildung 3: Zwei oder mehr Geräte, die sich einen Kanal teilen, bilden ein so genanntes Piconet. Dabei gibt es Punkt-zu-Punkt-Verbindungen (a) und solche, die mehrere Punkte einschließen (b). Überlappen sich Piconets, spricht man von einem Scatternet (c).

Nun ist die erste Voraussetzung für einen Angriff auf eines der gefundenen Geräte gegeben – seine Bluetooth-Adresse ist bekannt. Für den Bluebug-Angriff reicht es vollkommen aus, ein neues RFCOMM-Terminaldevice zu erzeugen. Das geschieht mit dem Kommando:

rfcomm bind 42 00:0E:6D:10:1D:B6 17

Es erzeugt das TTY »/dev/rfcomm42« und bindet es an den RFCOMM-Kanal 17 des Telefons mit der Adresse 00:0E:6D:10:1D:B6.

Der Kanal 17 lässt eine Verbindung zum AT-Parser ohne Authentifizierung und Verschlüsselung zu. Nun kann der Angreifer ein Terminalprogramm, zum Beispiel Minicom oder CU benutzen, um AT-Kommandos abzusetzen. Das Auslesen von einzelnen Telefonbucheinträgen geschieht etwa über spezielle Kommandos aus der ETSI-Spezifikation:

# cu -l /dev/rfcomm42
Connected.
AT+CPBS="ME"
OK
AT+CPBR=1
+CPBR: 1,"",,"Paris Hilton"
OK
~.
Disconnected.

Natürlich besteht auch die Möglichkeit, Programme wie Gnokii und Gammu zu benutzen, die alle notwendigen AT-Befehle kapseln und mit einer einfachen Syntax zur Verfügung stellen. Für den Bluesnarf-Angriff bietet sich das Programm Obexftp an. Es stellt über den RFCOMM-Kanal, der dem OBEX-Push-Profil zugeordnet ist, eine Anfrage an die Datei »telecom/pb.vcf«. Das Push-Profil wird diese Anfrage ausführen und das komplette Telefonbuch im V-Card-Format zurückliefern. Da das OBEX-Push-Profil normalerweise keine Authentifizierung erfordert, was für den Austausch von Visitenkarten auch keinen Sinn ergäbe, kommt man unbemerkt an die Daten im Telefon. Zuerst ist dabei mit Sdptool der RFCOMM-Kanal für OBEX-Push zu ermitteln (Abbildung 2). Bei Telefonen von Nokia ist dies in den meisten Fällen der Kanal 9 und bei Sony-Ericsson der Kanal 10.

Abbildung 4: Eine Bluetooth-Session unter der Lupe. HCI-Dump sammelt und speichert alle Daten.

Wie das Telefonbuch lassen sich auch der Kalender und weitere gerätespezifische Informationen auslesen. Hierfür eignen sich jene Pfade, die die IrMC-Spezifikation definiert. Beispiele sind »telecom/cal.vcs« für den kompletten Kalender oder »telecom/devinfo.txt« für telefonspezifische Information.

Paarungsverhalten

Um die folgenden Angriffe ohne einen teuren Protokollanalysator nachzuvollziehen, setzen Linux-User das Tool HCI-Dump ein. Es protokolliert alle Daten ab HCI aufwärts. Das Pairing benutzt auf der Ebene des Link-Managers kryptographische Verfahren für die Authentifizierung und Verschlüsselung.

Diese Verfahren sind in der Hardware implementiert, es besteht keine Möglichkeit für den Host-Stack, sie zu modifizieren. Das ist auch nicht notwendig. Der Host-Stack muss den Link-Manager nur mit der eingegebenen PIN versorgen und nachher den Link-Key für eine weitere Authentifizierung speichern. Beides geschieht über das HCI mit Hilfe von Kommandos und Events.

Im HCI-Dump-Beispiel (Abbildung 4) ist ein Verbindungsaufbau zu sehen. Diese Verbindung erfordert ein Pairing, wofür hier die PIN »1234« benutzt wird. In HCI-Dump ist diese PIN zwar zu erkennen, sie wird aber nie im Klartext übertragen. Nach Überprüfung der PIN generiert der Link-Manager den Link-Key und teilt ihn dem Host-Stack mit.

Diese Methode der Authentifizierung sollte eigentlich vor jedem Zugriff auf das Telefonbuch oder einen AT-Parser stattfinden. Die Angriffe Bluesnarf und Bluebug finden aber gerade ohne sie statt. Das ist möglich, weil das Telefon bei bestimmten RFCOMM-Kanälen nie nach PIN oder Link-Key fragt.

Dass die Angriffe praktisch durchführbar sind, ist erwiesen: Innerhalb von nur 14 Minuten fand Adam Laurie im Houses of Parliament in London 46 verwundbare Mobiltelefone, ein Test während der Rushhour in London ergab 336 Geräte in weniger als zwei Stunden, von denen immerhin 119 angreifbar waren.

Schwache Argumente

Die Argumente der Industrie sind in den meisten Fällen nicht haltbar. So führen die Hersteller häufig die nur geringe Reichweite von Bluetooth als Verteidigung gegen Vorwürfe an – deshalb sei die Gefahr ebenfalls gering. Die Tests in London zeigten ein gegenteiliges Bild. Außerdem ist zu fragen, ob nicht eine Reichweite von zehn Metern für einen Angreifer völlig ausreicht. Den bestohlenen Benutzer interessiert wahrscheinlich ebenfalls nicht, ob der Angriff auf einem prinzipbedingten Fehler im Bluetooth-Protokoll beruhte oder einen Implementierungsfehler ausnutzte.

Das Argument, ein Gerät müsse sichtbar sein, um angreifbar zu sein, trifft technisch nicht zu: Sobald auch nur die Bluetooth-Devive-Adresse (BD_ADDR) detektierbar ist, wird jedes Gerät angreifbar, ob es sichtbar ist oder nicht. Ein Tool für solche Attacken ist Redfang. Gleiches gilt für den Tipp, man solle Version oder Modellbezeichnung des Geräts durch Änderung des Namens tarnen: Blueprinting erlaubt (fast immer) die Identifikation des verwendeten Modells.

Interessanterweise ist auch oft das Argument zu hören, es sei einfacher, das Telefon zu stehlen, als Daten per Bluetooth auszulesen. Dabei wird aber vergessen, dass der Benutzer den Verlust des Telefons meist schnell bemerkt. Ein Datendiebstahl über eine Funkverbindung ist aber nicht zu bemerken. Nicht zuletzt dadurch ist auch das Entdeckungsrisiko für den Täter sehr gering.

Richtig und bedacht eingesetzt ist Bluetooth nicht unsicherer als ein ordinäres IP-Netzwerk. Nur kennen viele Nutzer die Gefahren nicht, wie auch entsprechende Tests immer wieder belegen. Manche Geräte – etwa die meisten Headsets – lassen sich außerdem gar nicht wirksam absichern. Daher ist es dringend notwendig, ein entsprechendes Gefahrenbewusstsein bei den Benutzern zu schaffen und so auch den Druck auf die Gerätehersteller und die Bluetooth-SIG zu erhöhen. (jcb)