Bluesnarfing, sprich unauthorisiertes Kopieren von Daten, und Bluebugging, die komplette Kontrolle über ein Gerät mit Hilfe von AT Befehlen, sind eigentlich altbekannt. Bluesnarfing wurde erstmals im November 2003 von Marcel Holtmann vorgestellt, Bluebugging im März 2004 von Martin Herfurt. Derartige Techniken wurden auf dem 21C3 präsentiert. Trotzdem die Hersteller informiert wurden und Patches verfügbar sind, ist die Information, dass die Bluetooth Implementationen einiger Hersteller sehr leichtfertig brisante Daten durch die Luft schmeissen, leider nicht bis zum Konsumenten weitergeleitet worden. So ist es nicht verwunderlich, dass derartige Attacken im Regierungsbezirk in Berlin das Herrschaftswissen der Republik, wie es der Spiegel nennt, preisgeben. Nur die Tatsache, dass es nachwievor keine Script Kiddie Tools für derartige Attacken im Netz gibt, verhindert schlimmeres oder ist es vielleicht gar mitschuld an der Misere? Ich weiss es nicht, das ist wohl fast schon eine Glaubensfrage.

Auf jeden Fall stelle ich mir immer noch die Frage wie solche Sicherheitslücken zustande kommen. Wieso kann man sich bei manchen Handys auf einen Channel, der nicht via SDP gelistet ist, verbinden und dem Telefon munter Befehle senden, die es dann ungefragt ausführt? Man kann diese Lücke sogar dazu verwenden dem Telefon mitzuteilen, dass es bitte einfach abhebt, wenn man anruft. Dadurch ist eine Raumüberwachung mit Hilfe einer Yagi Antenne auf knapp anderthalb Kilometer Entfernung möglich!

Fällt solch eine Eigenschaft aus Versehen und unbemerkt in den Code?

Oder wurde sie zu Testzwecken implementiert und nachher vergessen?

Das manche Hersteller es irgendwie versäumt haben bei OBEX FTP eine Authentifizierung einzubauen und man deshalb munter das Telefonbuch sowie den Kalendar auslesen kann, kann ich mir ja noch vorstellen.

Wie auch immer solche Dinge zustande kommen mögen, die Informationspolitik der entsprechenden Unternehmen ist miserabel.

Dank Blooover braucht man auch noch nicht einmal mehr einen Laptop, ein Handy mit Bluetooth und Java Unterstützung reicht aus, um derartige Attacken fahren zu können. Und wer sich ein wenig mit Bluetooth auskennt, bei Ebay z.B. ein Nokia 6310i mit ungepatchter Softwareversion ersteigert, via Bash Script die RFCOMM Channels des Telefons abklappert und mit der CVS Version von BlueZ vertraut ist, wird diese Lücken ebenfalls schnell finden. Sie sind einfach zu trivial.

Eine Einführung in das Thema bietet der Artikel Bluetooth for fun and profit.

Bei Nokia kann man sich eine komplette Dokumentation der AT Befehle downloaden und man wird feststellen, dass man mit seiner Bluetooth Verbindung mindestens genauso viel machen kann, wie der Mensch an der Handytastatur.

Das Tracken von Personen Dank der eindeutigen Bluetooth Adresse, sowie Blueprinting, Erkennen des Herstellers anhand der ersten drei Byte, brauch ich wohl kaum noch erwähnen. Also was gibt's neues seid dem 21C3?

Mehrere Angriffsmöglichkeiten sowohl auf den Bluetooth Stack als auch auf Dienste, die über Bluetooth erreichbar sind, können zu einer Denial of Service Attacke führen und entweder nur den Bluetooth Stack oder gleich das ganze Gerät abstürzen lassen.

Ein Beispiel für solch eine Attacke wurde auf dem 21C3 präsentiert, indem einem PDA ein etwas größeres L2CAP Packetchen geschickt wurde und dadurch lustige Nebeneffekte auftraten. Aber anscheinend geht es noch viel einfacher, denn es wurde berichtet, dass der Bluetooth Stack von Nokia 7650, Nokia 6600, Siemens V55, Motorola S55 und Windows 2003 abstürzen soll, wenn sie zu lange mit l2ping -f genervt werden. Mehr dazu hier.

Ich konnte das Mangels Verfügbarkeit dieser Devices nicht nachprüfen und kann nur sagen, dass mein geliebtes Nokia 6310i das nicht interessiert. Aber ich bin neugierig geworden und habe mich gefragt, ob es bei derart einfachen Angriffen nicht auch die Möglichkeit einer LAND Attacke, also Senden eines Pakets mit gleicher Absender- wie Empfängeradresse, gibt.

Manche Bluetooth Chipsätze erlauben es mit Hilfe eines HCI Befehls die Adresse neu zu setzen, doch Vorsicht man sollte sich die alte Adresse notieren, sonst isse futsch. Hier ein kurzes Codesnippet für den Ericsson Chipsatz, das mir freundlicherweise von Marcel Holtmann zur Verfügung gestellt wurde. Die handelsüblich verbauten CSR Chipsätze bieten solch ein nettes Feature leider nicht an.

#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>

#define OCF_ERICSSON_STORE_IN_FLASH     0x0022
typedef struct {
        uint8_t         user_id;
        uint8_t         flash_length;
        uint8_t         flash_data[253];
} __attribute__ ((packed)) ericsson_store_in_flash_cp;
#define ERICSSON_STORE_IN_FLASH_CP_SIZE 255

static void change_bdaddr(int dd, char *btaddr)
{
        struct hci_request rq;
        ericsson_store_in_flash_cp cp;
        bdaddr_t bdaddr;

        memset(&cp, 0, sizeof(cp));
        cp.user_id = 254;
        cp.flash_length = 6;

        str2ba(btaddr, &bdaddr);
        memcpy(&cp.flash_data, &bdaddr, 6);

        memset(&rq, 0, sizeof(rq));
        rq.ogf    = OGF_VENDOR_CMD;
        rq.ocf    = OCF_ERICSSON_STORE_IN_FLASH;
        rq.cparam = &cp;
        rq.clen   = ERICSSON_STORE_IN_FLASH_CP_SIZE;
        rq.rparam = NULL;
        rq.rlen   = 0;

        if (hci_send_req(dd, &rq, 1000) < 0) {
                perror("");
                return;
        }
}

int main(int argc, char *argv[])
{
        int dd;

        if(argc < 3)
          {
            printf("change_btaddr <devnr> <addr>\n");
            exit(0);
          }

        dd = hci_open_dev(atoi(argv[1]));
        if (dd < 0) {
                perror("");
                exit(1);
        }

        change_bdaddr(dd,argv[2]);

        hci_close_dev(dd);

        return 0;
}

Eine Liste der Ericsson HCI Commands und Events gibt es hier.

Als ich daraufhin die Adresse des Bluetooth Sticks auf die selbe wie meines Nokia 6310i gesetzt hab und ein l2ping ausführen wollte, bekam ich nur ein No route to host um die Ohren gehaun. Ok aktiv geht es schon mal nicht, also probiert man einen passiven Scan. Auch der zeigte kein Ergebnis. Ich weiss jetzt leider nicht, ob überhaupt ein Paket in die Luft geschleudert wurde oder ob der Stick nur mit sich selber geredet hat, aber ich bin optimistisch, dass es dort draussen einen Bluetooth Stack gibt, der für sowas zu haben ist.

Ok. Weg von L2CAP hin zu OBEX. In der Software eines Sony Ericsson P900 und Nokia 9500 wurden mehrere Deskriptor Overflow Möglichkeiten mit Hilfe von VCards, deren Dateiname oder Inhalte mehr als 200 Zeichen beinhaltet, entdeckt, die sich aber laut Aussage des Entdeckers leider nicht exploiten lassen und selbst wenn es eine Möglichkeit gäbe, es dem Angreifer nicht viel bringen würde, weil das Symbian OS diese Dienste mit sehr niedrigen und eingeschränkten Privilegien laufen lässt. Trotz allem kann solch eine Attacke zu einem Denial of Service führen.

Ich hab daraufhin die bluez-utils und die Kernel Bluetooth Implementation gepatched, so dass der Devicename mehr als die üblichen 248 Zeichen umfasst, in der Annahme, dass so etwas vielleicht auch zu einem Overflow führen könnte, doch Fehlanzeige. Die Firmware des Bluetooth Stick liest nur 248 Zeichen und Ende. Eine Möglichkeit des Overflows besteht somit wahrscheinlich nur über die Netzwerkebende, also via Pakete / Payload. Etwas Perl Code im POC Status zum Thema gibt es hier.

Zwei israelische Forscher, Avishai Wool und Yaniv Shaked von der Universität in Tel Aviv, haben den Algorythmus des in Bluetooth verwendeten Verschlüsselungsverfahren Safer+ geknackt. Nach eigenen Aussage ist es möglich eine vierstellige PIN mit einem 3 GHz Rechner in 0.06 Sekunden zu errechnen.

Dazu muss allerdings der gesamte Pairing Prozess mitgeschnitten werden, dann kann mit der Bruteforce Methode der Link Key ermittelt werden. Die Tatsache, dass viele Hersteller nur eine vier stellige PIN zulassen, erleichtert solche Angriffe enorm.

Die selben Forscher haben eine Repairing Attacke entdeckt, wobei einem Gerät mit gespoofter Bluetooth Adresse erzählt wird, man hätte aus Versehen den Link Key verbummelt, was einen neuen Pairing Prozess auslöst und dazu dienen kann den Pairing Prozess erneut mitzulesen.

Eventuell ist es nach dem alten Verfahren RST + Spoof möglich ein Bluetooth Gerät auszuschalten und seine Verbindung zu hijacken?

Bluetooth Sniffer, die den gesamten Pairing Prozess, also auch die Layer unterhalb von L2CAP und HCI, mitlesen können, kosten derzeit mehrere tausend Dollar. Da stellt sich mir als Unwissenden in Sachen Firmware Programmierung die Frage, ob es nicht möglich wäre eine Open Source Bluetooth Firmware zu entwickeln, die neben dem Spoofen der Bluetooth Adresse einen Sniffer beinhaltet und direkt das Bruteforce Konzept mit in den Code gießt.

Heute kam über die Full Disclosure Mailingliste eine Mail in mein Postfach geflattert, die mir mitteilte, dass es auf einem ungepatchten Mac OS X, sowie diversen PDAs, wie z.B. einem HP Ipaq 2215 möglich sei mit einer angepassten btftp Version von Affix aus dem Root Verzeichnis eines OBEX FTP Servers auszubrechen und somit beliebig im Dateisystem rumzuhüpfen. Alles was es dazu brauchte, waren diese freundlichen ../ Zeichen und die Tatsache, dass es Hersteller gibt, die selbst OBEX FTP ohne Authentifikation erlauben.

Die Zukunft wird wohl noch einige nette Spielereien in Sachen Bluetooth parat haben. Die Designer des Bluetooth Protokolls betonen nachwievor, dass alle Angriffe lediglich Fehler in der Implementation, aber nicht im Design sind. Bei einem angreifbaren auf einem unbekannten, gebrochenen Cipher basierenden Pairing Prozess lässt sich über diese Aussage vielleicht langsam, aber sicher streiten. Dennoch steht für mich ausser Frage, dass das Design von Bluetooth bei weitem robuster ist, als von manch anderem Protokoll, vor allem durch die Tatsache, dass nur die Firmware an die unteren Layer kommt.

Doch schön gedacht, ist noch lange nicht schön gemacht.

Bluetooth sollte somit besser nur bei Bedarf angeschaltet werden und man sollte peinlichst genau darauf achten, welchem Gerät man eine Verbindung gestattet.

Hab ich erähnt, dass Du Dein Handy patchen solltest? ;)