louisabricot/writeup-cve-2019-19194Une description et une preuve de concept théorique pour CVE-2019-19194
Ceci est une analyse et une preuve de concept théorique de la CVE-2019-19194.
⚠️ Cette CVE a été découverte par https://asset-group.github.io/disclosures/sweyntooth/
Ce rapport décrit comment la vulnérabilité Zero LTK Initialisation (CVE-2019-19194) permet à un attaquant un contrôle total de la communication sur une application Bluetooth Low Energy (BLE) en contournant la procédure d'appairage Secure Connections.
Cette vulnérabilité affecte les produits utilisant les implémentations Telink SMP qui prennent en charge la procédure d'appairage Secure Connections.
BLE est un système de communication radio à faible consommation et à courte portée. Il consiste en un ensemble de protocoles standardisés qui fournissent une connectivité à distance et une sécurité entre deux dispositifs.
La pile BLE est répartie sur deux blocs architecturaux : Host et Controller.
Cette répartition permet d'implémenter chaque bloc dans des composants physiquement séparés.
Une interface logique standard nommée Host Controller Interface (HCI) permet la communication entre les deux blocs.
Au-dessus du bloc Host se trouve l'application BLE.
La couche physique opère dans la bande radio ISM (Industriel, Scientifique et Médial), sur le spectre 2,4 GHz. Elle utilise 40 canaux : 3 canaux de diffusion et 37 canaux de données.
La couche de liaison (LL) a de nombreuses responsabilités qui ne seront pas décrites ici. Elle est régie par une machine à états qui définit des rôles et états importants :
Le protocole de contrôle de liaison logique et d'adaptation agit comme une couche de multiplexage de protocoles. Il gère la fragmentation et la réassemblage des paquets entre les couches inférieures et supérieures.
Le profil d'accès générique concerne la découverte et la connexion des dispositifs. En d'autres termes, GAP définit les procédures pour la transmission des paquets de diffusion et leur réception via le balayage.
Une fois qu'une connexion entre deux dispositifs BLE est établie, GATT utilise un modèle client/serveur pour échanger des données entre les deux dispositifs. Le client et le serveur utilisent tous deux le protocole d'attribut (ATT).
Le SM prend en charge les procédures liées à la sécurité telles que l'appairage, le liaisonnement et la distribution de clés. L'appairage des dispositifs est considéré comme le fondement de la sécurité Bluetooth : une fois appairés, les deux dispositifs peuvent chiffrer leur communication, s'authentifier mutuellement, etc.
Parmi les différents protocoles impliqués dans la communication BLE, la CVE zero LTK installation se produit pendant la procédure d'appairage, en mode Secure Connections.
Le mode d'appairage Secure Connections est considéré comme « l'approche plus sécurisée » et a été développé pour résoudre les faiblesses du mode Legacy. Cependant, la CVE zero LTK installation a révélé que de mauvaises implémentations de l'appairage SC permettent de contourner la sécurité.
Le dispositif central envoie une demande d'appairage et les deux dispositifs échangent sur leurs capacités et exigences de sécurité. Cette phase définit le mode d'appairage.
Échange de clés publiques : Un échange de clés publiques est initié par le dispositif central. Le périphérique et le central vérifient tous deux que la clé reçue se trouve sur la courbe P-256.
Calcul du DHKey : Chaque dispositif utilise sa propre clé privée (SK) et la clé publique de l'autre dispositif (PK) pour calculer sa clé Diffie-Hellman (DHKey). Ainsi, les deux dispositifs possèdent la même valeur DHKey.
Central: DHKey = p256(SKc, PKp)
Peripheral: DHKey = p256(SKp, PKc)
Si une protection MITM était demandée, une procédure interactive a lieu pour confirmer l'authenticité des dispositifs d'appairage.
Calcul de la Long Term Key (LTK) et confirmation mutuelle : Les dispositifs s'authentifient mutuellement et calculent une clé LTK. Une clé de session est dérivée de la LTK afin de chiffrer la liaison avant la Phase 3.
Via la liaison chiffrée, les dispositifs peuvent distribuer des clés.
La cause racine de zero LTK installation est qu'il n'y a aucune vérification de l'état dans lequel se trouvent les deux dispositifs lors de la procédure d'appairage. Ainsi, un dispositif central attaquant peut sauter l'étape de génération de clés et d'authentification. Cela a pour conséquence qu'une clé LTK est définie à 0 dans le dispositif périphérique, et donc une clé de session facilement dérivable.
⚠️ Il s'agit d'une preuve de concept entièrement théorique car je n'ai pas pu obtenir un pcap de découverte BLE, de diffusion ou de procédures d'appairage, et je ne disposais pas non plus d'un dispositif BLE avec une implémentation Telink SMP.