Skip to content

Mobile Security - Bluetooth-Implementierungen mit einer aktuellen Schwachstelle

Eigentlich wollte ich zum Abschluss des Themas "Bluetooth" in dieser Folge ja die Schutzmaßnahmen aus der NIST Special Publication 800-121 Revision 2 vorstellen. Aber da ist mir eine diese Woche veröffentliche Schwachstelle in der Bluetooth-Implementierung vieler Hersteller dazwischen gekommen. Die geht natürlich vor.

Schwachstelle beim Pairing

Eli Biham und Lior Neumann haben einen neuen Angriff auf Bluetooth-Implementierungen vorgestellt: Fixed Coordinate Invalid Curve Attack.

Beim Pairing erfolgt wie von mir hier erklärt ein Diffie-Hellman-Schlüsselaustausch auf Grundlage von elliptischen Kurven (ECDH). Einige Bluetooth-Implementierungen prüfen die dabei verwendeten ECDH-Parameter nicht oder nicht ausreichend. Ein Angreifer kann das ausnutzen, um unerkannt bestimmte Werte zu manipulieren und sich den ausgehandelten Schlüssel zu verschaffen und danach die übertragenen Daten zu belauschen oder zu manipulieren.

Damit der Angriff funktioniert müssen beide Verbindungspartner eine betroffene Bluetooth-Implementierung verwenden. Nutzt auch nur einer der beiden eine sichere Version, ist der Angriff nicht möglich.

Außerdem muss der Angreifer natürlich in Reichweite sein, und der Angriff ist nur während des Pairings möglich. Was i.A. nur beim ersten Verbindungsaufbau zwischen zwei Geräte erfolgt.

Die Schwachstelle hat die CVE-ID CVE-2018-5383 und wird vom US-CERT in der Vulnerability Note VU#304725 behandelt.

Der Angriff von Eli Biham und Lior Neumann

Betroffen sind das Secure Simple Pairing des normalen Bluetooths und das LE Secure Connections Feature von Bluetooth LE.

Wie ein MitM-Angriff beim Diffie-Hellman-Schlüsselaustausch auf Grundlage von Primzahlen funktioniert hatte ich bereits beschrieben. Im Fall von Elliptischen Kurven funktioniert das Ganze analog. Um das hier zu erklären, müsste ich zuerst eine kleine Einführung in die Kryptographie über Elliptische Kurven allgemein und den DH-Schlüsselaustausch darüber im besonderen bringen, und das würde den Rahmen bei weitem sprengen. Weshalb ich das Thema "Krypto-Verfahren mit Elliptischen Kurven" auch schon auf der ToDo-Liste habe.

Aber zurück zum aktuellen Problem. Um den Angriff auf den Schlüsselaustausch zu verhindern müssen die ausgetauschten Nachrichten durch eine digitale Signatur oder einen Message Authentication Code authentisiert werden. Und genau darauf verzichten einige Bluetooth-Implementierungen. Eli Biham und Lior Neumann haben herausgefunden, dass es dadurch möglich ist, die Parameter so zu manipulieren, dass der Angreifer den ausgetauschten Schlüssel ermitteln und danach damit die Kommunikation belauschen oder Daten in sie einschleusen kann.

Betroffene Implementierungen

Bei Bluetooth LE ist das Pairing im Betriebssystem des Hosts implementiert, so dass die Geräte ggf. unabhängig vom verwendeten Chip betroffen sind. Androids Bluetooth-Stack Bluedroid ist betroffen. Microsofts Windows dagegen nicht, da dort das angegriffenen LE SC nicht unterstützt wird.

Auf Bluetooth BR/EDR Plattformen wird der Schlüsselaustausch vom Chip durchgeführt, so dass hier alle Geräte betroffen sind, die einen betroffenen Chip verwenden. Eli Biham und Lior Neumann haben herausgefunden, dass die Implementierungen von Qualcomm, Broadcom und Intel betroffen sind, und damit der größte Teil der Bluetooth-Chip-Markts. Um die Schwachstelle zu beheben müssen die Treiber aktualisiert werden, und erste Updates gibt es bereits, z.B. für Android, Apples macOS und iOS, und von Intel für deren Bluetooth-Treiber für Windows und Linux.

Auch der Bluetooth-Standard wurde "gepatcht". Die Bluetooth Special Interest Group (SIG) die Protokollspezifikation angepasst. Darin ist nun genau festgelegt, wie die ausgetauschten öffentlichen Schlüssel geprüft werden müssen. Im Rahmen des Bluetooth Qualification Program werden die Bluetooth-Implementierungen in Zukunft auch auf die Schwachstelle getestet, so dass Standard-konforme Implementierungen in Zukunft sicher sein sollten. Sollten, weil ja immer die Möglichkeit weiterer Schwachstellen besteht.

Die war nun hoffentlich wirklich der vorerst vorletzte Artikel zur Bluetooth-Sicherheit. In der nächsten Folge werde ich noch die Schutzmaßnahmen aus der NIST Special Publication 800-121 Revision 2 vorstellen, danach ist dann erst mal wieder ein anderes Thema an der Reihe.

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Aktuelles, Grundlagen

Trackbacks

Dipl.-Inform. Carsten Eilers am : Mobile Security - Bluetooth absichern, Teil 1

Vorschau anzeigen
Wie angekündigt geht es ab dieser Folge zum vorläufigen Abschluss des Themas &quot;Bluetooth-Sicherheit&quot; um den Schutz von Bluetooth, insbesondere um die Schutzmaßnahmen aus der NIST Special Publication 800-121 Revision 2. Aufgrund de