Actualités

BrakTooth : mise en lumière de 16 vulnérabilités impactant plus de 1 400 terminaux sous Intel ou Qualcomm !

Permettant des exécutions de code à distance en passant par des attaques de type Denial-of-Service (DoS), BrakTooth cible spécifiquement la connectivité sans-fil ou protocole BT (BlueTooth classic) : pas moins de 16 vulnérabilités (13 concernant directement les constructeurs ou fabricants) ont été mises en lumières de 11 constructeurs différents dont Intel, Qualcomm qui sont équipementier et en lien – technique – étroit avec l’exploit mais aussi des fabricants de terminaux mobiles comme Xiaomi (le Pocophone F1 étant cité, entre-autres…) ou, entre-autres, ES (Expressi System). Au total, il est estimé que 1 400 terminaux seraient concernés par BrakTooth.

 

 

Signifiant littéralement crashTooth (crash étant emprunté au mot norvégien Brak), le PoC – mis en lumière par des chercheurs de l’Université de Technologie et Design de Singapour et l’Institut I2R – repose sur un un “kit de développement ESP32 bon marché” et d’un code personnalisé (essence, code, du PoC). Le port USB1 est ciblé (depuis ESP32, dont le kit est accessible au prix de 14,80 dollars USD, est-il souligné voire 4 dollars USD depuis AliExpress, suivant le modèle dudit kit…) pour atteindre une destination différente suivante l’exploit ou le but recherché. De la télémétrie distante est massivement utilisée sous le terminal de la victime (délai-pagination pour vérifier la santé-terminal via une absence de retour-réponse pour confirmer l’exploit ou la viralité instillée voire en cherchant d’autres informations depuis un port en série ou, entre-autre, une connexion SSH) en effectuant, en préambule, des enregistrements des paquets OTA (Over-The-Air).

 

L’ensemble est aspiré par un “renifleur actif” au sein des protocoles BR-EDR.

 

Outre les terminaux impactés, cet ensemble de 16 vulnérabilités concerne plus largement de nombreux SoC (dont l’exploit repose de manière différente, suivant à quelle hauteur l’ensemble repose ou non sur le chipset ; un environnement isolé permettant d’être immunisé presque totalement de ces vulnérabilités, à l’inverse d’un environnement mixte ou exploitant pleinement la couche-pile Bluetooth avec le processeur principal qui peut engendrer, suivant la stratégie adoptée, des exploits dangereux de manière modérée ou critique) de différents constructeurs : outre Intel et Qualcomm, on retrouve des vendeurs intégrant ces SoCs tels que :

 

  • Microsoft : Surface laptop 3, Surface Go 2, Surface Pro 7, Surface Book 3 (Intel AX200) ;

  • Dell : (dont) Optiplex 5070, Alienware M17 R3 (Intel AX200) ;

  • Sony : Xperia XZ2 (WCN3990) ;

  • Oppo : Reno 5G CH1921 (WCN3998) ;

  • Ericsson : KDE20102 (CSR8510) ;

  • Volvo technology : (dont) Volvo FH (CSR8811-510) ;

  • Hella GmbH : PMP3 (CC2564C ;

  • Walmart : (dont) haut-parleur Disco Lamp (Jieli AC63XX), haut-parleur Small rugged (ATS281X) ;

  • Panasonic : barre de son SC-HTB100 (ATS281X) ;

  • Becker Avionics : (dont) AMU6500 5wt32i) ;

  • u-Box : module IoT NINA-W106 (ESP32) ;

  • Koyo Electronics : C2-02CPU (ESP32).

 

Du reste, voici un condensé synthétique des vulnérabilités :

 

  • CVE-2021-28139 : vulnérabilité depuis Espressif ESP-IDF (v4.4 et antérieures), d’un paquet – LMP – dédié (Feature Response Extented) permettant une exécution de code arbitraire sous ESP32 (appel LMP_feature_res_ext). En finalité, le Wi-fi peut être désactivé voire, entre-autres, un effacement de certaines données-firmware (NVRAM). Un reboot permet temporairement de restaurer les paramètres ou communications Bluetooth ;

 

  • CVE-2021-34144 : SoC Zhuhai Jieli AC6366C (SDK BT v0.9.1 et antérieures) incriminé au niveau de “la réception des paquets LMP” (SCO_Link_Request). Il est précisé que cette vulnérabilité est opérationnelle pour une unique connexion Bluetooth active. Une fois la faille exploitée, impossibilité de jointer le terminal à d’autres connexions Bluetooth. Un reboot permet temporairement de restaurer le protocole et ses paramètres ;

 

  • CVE-2021-28136 : vulnérabilité depuis Espressif ESP-IDF (v4.4 et antérieures), de plusieurs paquets LMP (IO_Capability_req) alors que le terminal finalise l’étape d’appareillage. Un crash-mémoire peut s’opérer au sein d’ESP32 en renvoyant un doublon d’un paquet LMP légitime ;

 

  • CVE-2021-28135, CVE-2021-28155 et CVE-2021-31717 : vulnérabilité depuis Espressif ESP-IDF (v4.4 et antérieures) au niveau de la gestion des récéption-réponses LMP “non sollicitées continues“. L’ensemble peut aboutir à une attaque DoS (via un crash) au sein de l’ESP32. Des fabricants tels que Xiaomi ou encore JBL voient certains de leurs terminaux impactés ;

 

  • CVE-2021-31609, CVE-2021-31612 : iWRAP (v6.3.0 et antérieures) de SiliconLabs défaillant lors de la réception d’un paquet LMP “sur-dimensionné” (supérieur à 17 octets) dans le canal DM1 (cf. illustration ci-dessus), ce qui implique un potentiel crash dans WT32i “via un LMP spécifiquement conçu“. Le plantage ou crash est effectif lors l’exploit est réitéré plusieurs fois (temps estimé : 3-5 minutes par une personne avertie). L’exploit fonctionne pour les SoCs Jieli cités un peu plus haut ;

 

  • CVE-? (en attente de divulgation) : SoC Laird CSR8811 A08 et CSR8510 A10 incriminés et permettant un dépassement mémoire type overflow depuis 2-DH1 avec, en finalité, une corruption des paquets ou du terminal. La connectivité Bluetooth LE (Low Energy) n’est pas impactée et un reboot-système permet de restaurer le protocole de manière fonctionnel mais temporaire, faute d’un patch correctif appliqué sur le terminal en question ;

 

  • CVE-2021-34150 : couplé avec BlueTooth classic (Bluetrum AB5301 A – SDK AB32VG1), certains versions de firmware “non spécifiées” provoque un dysfonctionnement lors de la réception de paquets LMP DM1 “sur-dimensionnés“. Ici également, toute nouvelle connexion autre que celle – Bluetooth – active par le cyber-attaquant s’avère impossible sur le terminal ainsi infecté. Contrairement à la vulnérabilité relative à iWRAP, il n’y a aucun besoin de concevoir un paquet LMP personnalisé ou spécifique : n’importe quel paquet LMP peut faire l’affaire ;

 

  • CVE-2021-31613 : SoC Jieli AC690X et AC692X (terminaux Zhuhai sous protocole BlueTooth classic) incriminés. La viralité prend son sein depuis un “firmware inconnu” alors la procédure auto-rate réceptionne un paquet LMP biaisé. Un crash ou plantage-système se produit avec un redémarrage-système “rapide“, ce qui conduit à un DoS. Une contre-mesure peut être appliquée en autorisant une unique connexion, ici, Bluetooth, pour réduire les connexions multiples (le cyber-attaquant devra cibler un SoC spécifique, alors). Faute de pouvoir accéder en source ouverte à l’implémentation BT, les chercheurs ont estimé que la vulnérabilité exploitent un ou plusieurs manquements au niveau des étapes de vérifications dans l’interrupt handler (gestionnaire d’interruption) ;

 

  • CVE-2021-31611 : SoC Jieli AC690X et AC692X (terminaux Zhuhai sous protocole BlueTooth classic) incriminés, depuis des paquets LMP mal (re)formés (procédure out-of-order – exécution dans le désordre + paquet “mal formé”). La viralité se fait sous la forme de “paquets LMP spécifiquement conçus“. Un reboot-système permet de rétablir le protocole Bluetooth de manière fonctionnelle mais temporaire, sans application d’un patch ;

 

  • CVE-2021-31785 : chipsets Actions ATS2815-ATS2819 sous BlueTooth classic sont impactés par une attaque DoS “si aucun autre appareil utilisateur n’est connecté au cible”, lors de la réception de paquets LMP (host_connection_req). Un reboot-système permet un retour à la normale, de manière temporaire, faute de patch ;

 

  • CVE-2021-31786 : chipsets Actions ATS2815-ATS2819 sous BlueTooth classic Audio. Dysfonctionnement d’une nouvelle connexion pointant sur “la même adresse BDAddress que l’hôte BT actuellement connectée”. Une erreur qui engendre des blocages. Un reboot-système restaure les paramètres fonctionnels mais de manière temporaire ;

 

  • CVE-2021-31610, CVE-2021-34149, CVE-2021-34146, CVE-2021-34143 : vulnérabilité de “plusieurs chipsets” (dont Texas Instruments CC2564C) sous BT classic au niveau de la gestion-réponses LMP “non-sollicitées continues”, ce qui provoque un dépassement mémoire type overflow et depuis le firmware. Une attaque par DoS s’opère, alors (via LMP_AU_rand). Un blocage unique est observé pour le SoC sous Texas Instruments ainsi que le MCU (hôte) MSP432 en dual-mode de la pile BT TI ;

 

  • CVE-2021-34145 : Cypress WICED BT v2.9.0 (et antérieures – terminaux CYW20735B1) sous BT classic incriminé. Erreur au niveau de la gestion des paquets LMP en réception (max_slot) via un adressage (lt_address) invalidé (lt_addr). Une fois la configuration opérée et combinée avec l’exploit présent, un DoS s’opère (via crash) par l’entremise d’un paquet LMP spécfique ;

 

  • CVE-2021-34148 : Cypress WICED BT v2.9.0 (et antérieures – terminaux CYW20735B1) sous BT classic incriminé. Erreur au niveau de la gestion des paquets LMP en réception (max_slot) via un outrepassement de la longueur ACL (où longueur égale 31). Une fois la configuration opérée et combinée avec l’exploit présent, un DoS s’opère (via crash) par l’entremise d’un paquet LMP spécfique ;

 

  • CVE-2021-34147, CVE-?, CVE-? : Cypress WICED BT v2.9.0 (et antérieures – terminaux CYW20735B1, chipsets Intel AX200 + Qualcomm WCN3990) sous BT classic incriminé. Erreur au niveau de la réception-réponse LMP “mal formée” (erreur-synchronisation), ce qui conduit à plusieurs tentatives de reconnexions. En finalité, de nombreuses tentatives sont effectuées (LMP_timing_acc-response) de manière spécifique avec une “reconnexion soudaine” via un BDAddress randomisé : une attaque par DoS s’opère pendant et après la cyber-attaque ce qui noie le terminal impacté sans que l’utilisateur puisse tenter de reprendre la main pendant l’incursion. Il est souligné qu’un reboot (daemon Bluetooth sous Android) permet de restaurer les micro-logiciels WCN3990 et CYW20735B1 (timer watchdog, actif par défaut). Nul besoin, est-il précisé par les chercheurs, d’avoir une authentification quelconque pour parfaire l’exploit ;

 

  • CVE-? : chipset Intel AX200 concerné par cette dernière vulnérabilité lors de la réception-réponse LMP invalidée (erreur-synchronisation), ce qui conduit à plusieurs tentatives “forcées” de reconnexion avec toujours la même BDAddress. De ce fait, toute autre connexion BT est exclue. Dans un schéma de cyber-attaque similaire originellement à la faille précédente ci-dessus, avec, ici, une variante consistant à déclencher l’offensive “avant la procédure de changement de rôle” (cf. illustration ci-dessus). En addition, un timing LMP est appliqué pour le paquet (réponse) LMP ainsi mal formé, via l’application d’un longueur “sur-dimensionnée” (supérieure à 17 octets, sous DM1), ce qui met en lumière le fait qu’Intel n’a tout simplement pas prévu, note les chercheurs, ce cas de figure ou de débordement. Une attaque par DoS peut alors s’opérer. Un reboot du protocole peut réinitialiser l’ensemble de la connectivité mais, faute d’un patch, de manière temporaire.

 

Plusieurs constats et recommandations ont été apposés, de manière globale :

 

  • L’exploit requiert une connaissance ou configuration exacte (en plus du kit ESP32) pour être effectif : y compris pour les constructeurs ou fabricants, les cyber-attaquants peuvent ne pas totalement maitriser l’ensemble des procédures sous LMP (un mode de test sous Bluetooth Core Specifications). Les chercheurs ont cependant souligné que le PoC présentement exposé (BrakTooth) permet d’obtenir “le contrôle sur LMP à l’hôte“, en universalisant la procédure, qu’elle soit sécuritaire côté vendeur ou malveillante côté cyber-attaquant potentiel ;

  • Cas malheureusement chronique, une dépendance s’opère entre les fabricants et les constructeurs, en terme de publication de contre-mesures ou correctifs. Le cas d’Android (patch), surtout lors de vulnérabilité critique illustre bien ce point ou encore l’inter-dépendance, concernant BrakTooth, entre un constructeur de SoC et un fabricant de smartphone intégrant ledit SoC qui serait colmaté sécuritairement mais qui resterait à déployer, au sein du smartphone donné. Un point qui s’avère redoutablement critique dans le domaine de l’IoT ou les acteurs, de part et d’autres, sont nombreux (pas seulement 1-à-1). Il est vivement recommandé à tout les acteurs concernés de considérer ces schémas en faisant une “évaluation approfondie des risques” ;

  • Un manque d’outils et de ressources-tests a été constaté par les chercheurs (ce que l’on nomme l’ingénierie inversée) lors des tests effectués depuis le Bluetooth Link Manager (BLM) ; plus précisément au niveau de la pile LMP qui n’a toujours pas de version “open-source et complète“, ce qui renforce les brèches sécuritaires, en terme d’exploitation potentielle. Des premiers pas ont été démontrés au sein du PoC, notamment au sein de la bibliothèque libbtdm_app (statique) sous la pile ESP32 BT (interface par fuzzing) : il s’agit d’un étape de validation pour légitimer un protocole sous BR / EDR, ce qui constitue, en l’état, une piste potentiellement applicable, côté vendeurs et fabricants, en terme d’ingénierie inversée et, donc, avancée.

Le PoC final (incluant le fameux code personnalisé évoqué en début d’actualité) ne sera publié qu’en fin d’Octobre 2021, pour des raisons sécuritaires, le temps que l’ensemble des acteurs technologiques puissent déployer sereinement leurs correctifs relatifs, en notant qu’un formulaire reste disponible, pour entrevoir ce fameux PoC… A veiller !

 

 

 

 

Sources :




  • 50% J'apprécieVS
    50% Je n'apprécie pas
    Pas de commentaire

    Laisser un commentaire

    ;) :zzz: :youpi: :yes: :xmas: :wink: :whistle: :warning: :twisted: :sw: :sleep: :sg1: :schwarzy: :sarko: :sante: :rollol: :roll: :rip: :pt1cable: :popcorn: :pff: :patapai: :paf: :p :ouch: :oops: :o :non: :na: :mrgreen: :mdr: :macron: :love: :lol: :kissou: :kaola: :jesuisdehors: :jap: :ilovesos: :idea: :houra: :hello: :heink: :grumpy: :fume: :frenchy: :fouet: :fouet2: :first: :fessee: :evil: :dispute: :demon: :cryy: :cry: :cpignon: :cool: :cassepc: :capello: :calin: :bug: :boxe: :bounce: :bluesbro: :bisou: :babyyoda: :assassin: :arrow: :annif: :ange: :amen: :D :??: :?: :/ :-| :-x :-o :-P :-D :-? :-1: :+1: :) :( 8-O 8)

    Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

    Copyright © Association SOSOrdi.net 1998-2021 - v1.11.4a