Android: Bluetooth P2P ohne Nutzerbestätigung möglich

Ich habe mich kürzlich mit der Frage beschäftigt, ob es möglich ist, mehrere Android-Geräte via Bluetooth miteinander zu verbinden, ohne dafür irgendeine Bestätigung des Nutzers einzuholen.

Viele App-Entwickler möchten dies zugunsten der Usability gern machen. Aus Sicherheitsgründen ist aber nicht gewollt, dass es funktioniert. Bevor eine Peer-to-Peer-Verbindung aufgebaut werden kann, ist daher eigentlich erst eine Bestätigung des Nutzers erforderlich.
Dennoch habe ich recht schnell einen Weg gefunden, wie es trotzdem geht. Kritisch betrachtet handelt es sich dabei um eine Sicherheitslücke in Android.

Eine Sicherheitslücke in Android?

Keine Angst, das Ganze hat nicht die Tragweite von Stagefright. Es handelt sich in diesem Sinne auch nicht um einen Programmierfehler oder Bug. Viel mehr kann man wohl von "broken by design" sprechen, denn um die besagte P2P-Verbindung ohne die Einwilligung des Nutzers herzustellen, spiele ich schlicht zwei verschiedene Funktechnologien gegeneinander aus.

Dennoch ist die Tatsache, dass der heimliche Aufbau einer Bluetooth-P2P-Verbindung so einfach möglich ist, ein sicherheitsrelevantes Problem. Warum dem so ist, will ich im Folgenden aufzeigen.

Bluetooth: Verbindungsaufbau

Die meisten Smartphone-Nutzer haben irgendwann schon einmal Bluetooth benutzt. Die Technologie kommt zum Einsatz um Daten von einem Telefon zum anderen zu übertragen oder um Headsets, Lautsprecher, Freisprechanlagen und andere Geräte drahtlos mit dem Telefon zu verbinden.

Der zum Verbindungsaufbau nötige Ablauf ist den meisten daher bekannt. Man aktiviert Bluetooth, falls es nicht ohnehin dauerhaft aktiviert ist, stellt die Sichtbarkeit beider Geräte ein, sodass sie sich gegenseitig finden können und koppelt (oder "paart") die Geräte dann mithilfe einer PIN.

Ist dieser Pairing-Prozess einmal durchgeführt, können die Geräte zukünftig auch miteinander kommunizieren, ohne sichtbar zu sein. Dies funktioniert, da die beteiligten Geräte sich die zum Verbindungsaufbau benötigte MAC-Adresse des jeweils anderen Gerätes merken.

Insofern App-Programmierer dies möchten, ist es auch möglich, Android-Geräte via Bluetooth zu verbinden, ohne dass eine Nutzerbestätigung oder PIN-Eingabe nötig ist. Möglich machen dies die in der Android-API enthaltenen Funktionen createInsecureRfcommSocketToServiceRecord() sowie listenUsingInsecureRfcommWithServiceRecord().
Wie die Funktionsnamen schon sagen, geht man hier von einer unsicheren Verbindung aus. Es findet kein Pairing-Prozess statt, daher werden die verbundenen Geräte auch nicht in die Liste der bekannten Bluetooth-Geräte aufgenommen. Dennoch können über die entstandene Bluetooth-Socket-Verbindung natürlich jedwede Daten übertragen werden.

In Sachen Sicherheit ist der Knackpunkt dieses Verfahrens, dass man eine P2P-Verbindung zu einem anderen Gerät nur dann aufbauen kann, wenn man dessen MAC-Adresse weiß. Ist diese nicht bekannt, ist ein Discovery-Prozess nötig, welcher wiederum erfordert, dass das Gerät für andere Bluetooth-Geräte sichtbar gemacht wird.
Da hierfür wieder die Bestätigung des Nutzers eingeholt werden muss, eigenen sich die Funktionen ohne Weiteres also nicht dazu, unbemerkt Geräte miteinander zu verbinden, deren MAC-Adresse man nicht kennt.

Das ist gut für die Sicherheit, denn wie oben schon angedeutet, ist ja nicht gewollt, dass sich Geräte autonom verbinden. Doch leider lässt sich dieser Schutzmechanismus aushebeln. Ein Weg dies zu tun, ist die Verwendung von WiFi Direct.

WiFi Direct: Eine kurze Einführung

WiFI Direct, oft als "WFD" abgekürzt und manchmal auch als "WLAN Direct" oder "WiFi P2P" bezeichnet, ist den meisten Anwendern noch nicht allzu geläufig. Es handelt sich dabei um einen noch recht jungen, WLAN-basierten Standard der WiFI Alliance, der viele Ähnlichkeiten zu Bluetooth aufweist. WiFi Direct ist dafür konzipiert, Peer-to-Peer-Verbindungen zwischen WLAN-fähigen Geräten herzustellen. Das heißt, es sind WLAN-Verbindungen ohne Access Point möglich. WiFi Direct wird inzwischen von sehr vielen Druckern und Fernsehgeräten unterstützt, in Android ist es in Form der WiFiP2p-API seit Version 4.0 mit an Board.

Das Funktionsprinzip hinter WiFi Direct ist recht einfach: Geräte, die eine Verbindung aufbauen möchten, einigen sich dynamisch darauf, dass eines der Geräte zum Access Point (in WiFi Direct "Group Owner") wird. Alle anderen Geräte, das können je nach vorhandener Soft- und Hardwareumsetzung beliebig viele sein, melden sich bei diesem an. Die entstandene WLAN-Architektur gleicht der eines herkömmlichen Heimnetzwerkes, mit einem WLAN-Router und beliebig vielen angemeldeten Clients.

Damit sich die verbindungswiligen Geräte gegenseitig finden, ist ein Discovery-Prozess notwendig. In diesem wird aktiv nach möglichen WFD-Verbindungspartnern gesucht. Um selbst gefunden zu werden, senden die Geräte ihren eigenen (frei konfigurierbaren) WiFi-Direct-Namen in die Welt hinaus. (Das ist vergleichbar mit einem Access Point, der ständig Beacons mit seiner SSID versendet, um für alle WLAN-fähigen Geräte in der Nähe sichtbar zu sein.)

Wie bei Bluetooth sieht Android auch bei WiFi Direct vor, dass keine P2P-Verbindungen ohne die Bestätigung des Nutzers aufgebaut werden. Eine PIN-Eingabe ist zum Verbindungsaufbau meist nicht nötig, der Nutzer muss nur Ja oder Nein drücken.

Das Sicherheitsproblem: Bluetooth + WFD = Verbindung ohne jegliche Einwilligung

Die bis hierhin vorgestellten Informationen reichen aus, um Androids Sicherheitsmechanismen auszuhebeln und Peer-to-Peer-Verbindungen herzustellen, ohne dass der Nutzer etwas davon weiß.

Der "Hack" ist sehr einfach: Wie oben beschrieben, kann man via Bluetooth unsichere Verbindungen herstellen, für die keine Nutzereinwilligung erforderlich ist. Dazu müssen aber erst die MAC-Adressen der beteiligten Geräte bekannt sein, was nur möglich ist, wenn man die Gerätekonfiguration schon bei der Programmierung weiß oder indem man sie via Discovery-Prozess erfährt, wofür aber eine Nutzerbestätigung erforderlich wäre.

Doch das Vorhandensein der WiFi-Direct-Technologie im gleichen Endgerät macht es möglich, diese Barriere zu durchbrechen. Denn wie oben schon erklärt, hat jedes WiFi-Direct-Gerät einen veränderbaren Namen. Dieser lässt sich nicht nur über das Konfigurationsmenü von Android, sondern auch programmiertechnisch manipulieren. Hierfür erbittet Android (leider) keine Bestätigung des Nutzers. Folglich kann man den WiFi-Direct-Namen benutzen, um die Bluetooth-MAC-Adresse des jeweiligen Endgerätes zu publizieren. Andere Geräte können diese dann erfahren, indem sie die verfügbaren WiFi-Direct-Geräte abfragen. Der Versuch eines Verbindungsaufbaus ist hierfür nicht nötig und somit wird der Nutzer auch nicht gefragt, ob er eine WFD-Verbindung aufbauen möchte.
Das Wissen der Bluetooth-MAC-Adresse reicht dann aus, um die Geräte unbemerkt miteinander zu verbinden und beliebige Daten übertragen zu können.

Gefahrenpotenzial

Dieses Vorgehen funktioniert nur, wenn auf allen beteiligten Geräten eine App läuft, die die entsprechenden Konfigurationsänderungen vornimmt und Bluetoothverbindungen aufbaut bzw. eingehende Verbindungsanfragen entgegennimmt. Dafür muss Bluetooth natürlich aktiviert sein (ohne Nutzereinwilligung kann es programmiertechnisch nicht angeschaltet werden). Bei Nutzern, die häufig Kopfhörer, Headsets oder eine Freisprechanlage benutzen, ist das jedoch meist der Fall.

Wer jetzt denkt, "Na so eine App würde ich mir doch sowieso nicht installieren", der unterschätzt die Gefahr. Vor nicht allzu langer Zeit berichteten die Medien über eine millionenfach installierte Taschenlampen-App, deren einzige Funktion eigentlich sein sollte, dass sie die Kamera-LED des Telefons an- und ausschaltet. Es stellte sich jedoch heraus, dass die App heimlich massenhaft Nutzerdaten sammelte. Das Beispiel zeigt, dass es recht einfach ist, Smartphone-Besitzern Schadcode unterzujubeln, ohne dass diese es bemerken. Auch im Bereich des Social Engineerings gibt es unzählige Beispiele, die zeigen, dass (vor allem technisch nicht allzu versierte) Benutzer zu allem bereit sind, wenn sie glauben, sie würden das Richtige tun.
In einer Welt, in der jeder einen Computer in der Hosentasche mit sich herumträgt, welcher permanent mit dem Internet verbunden ist, aber in der der durchschnittliche Anwender schon davon überfordert ist, sich die App-Berechtigungen in Googles Play-Store anzusehen und darüber nachzudenken, ob diese für den angegebenen Funktionsumfang der Anwendung Sinn machen, haben es böswillige App-Entwickler sehr leicht.

Im konkreten Fall ließe sich der vorgestellte Implementierungsansatz von Kriminellen beispielsweise nutzen, um ein Mobiltelefon über eine kurze Funkstrecke hinweg (mithilfe eines zweiten Smartphones) zu überwachen. Darüber hinaus ist aber auch die autonome Vernetzung einer Vielzahl von Telefonen denkbar. Gerade in dicht besiedelten Gebieten oder im Falle von Menschenansammlungen wäre dies durchaus umsetzbar. Angreifer könnten versuchen Bluetooth-Scatternets auszubilden und diese beispielsweise als Botnet einsetzen.

Besonders heimtückisch ist, dass man als Smartphone-Nutzer nahezu nichts von den heimlich aufgebauten Peer-to-Peer-Verbindungen mitbekommt. Da kein Pairing stattfindet, tauchen die verbundenen Geräte nicht in Androids Bluetooth-Einstellungen auf. Auch bei der WLAN-Funktionalität sind für den Anwender keine Einschränkungen bemerkbar. WiFi Direct kann parallel zum normalen WLAN-Betrieb genutzt werden, ein nebenher laufender WFD-Discovery-Prozess hat daher keine merklichen Auswirkungen. Der manipulierte WiFi-Direct-Name lässt sich zwar in den Tiefen der erweiterten WLAN-Einstellungen einsehen, doch dorthin verirren sich wohl nur die wenigsten Anwender.

Gegenmaßnahmen

Mir ist nicht bekannt, dass es irgendeine Schadsoftware gibt, die den beschriebenen Ansatz ausnutzt. Dennoch empfehle ich sowohl die Bluetooth- als auch die WLAN-Funktionalität mobiler Endgeräte auszuschalten, wenn diese gerade nicht benötigt werden.

Die beste Gegenmaßnahme wäre aber meiner Ansicht nach, wenn Google in einer kommenden Android-Version einführen würde, dass für die Änderung des WiFi-Direct-Namens eine Nutzerbestätigung erforderlich ist.
Solang dies nicht der Fall ist, bleibt die Möglichkeit des heimlichen P2P-Verbindungsaufbaus bestehen.

App-Entwickler, die nichts Böses im Schilde führen, können das beschriebene Vorgehen natürlich auch einsetzen, um nutzerfreundliche Apps zu entwerfen, die nicht dauernd um eine Bestätigung betteln. Ob der Ansatz genutzt wird, um eine bessere Usability zu gewährleisten oder um Schadsoftware zu entwickeln, liegt am Ende im Ermessen des Programmierers.

Geschnatter