Il est historiquement établi que la plupart des employés utilisent des claviers et des souris sans fil de la marque Logitech. Une fois de plus, en saisissant nos mots de passe, nous – les spécialistes de l'équipe Raccoon Security – nous sommes demandé : à quel point est-il difficile de contourner les mécanismes de protection des claviers sans fil ? L'étude que nous avons menée a révélé des défauts d'architecture et des erreurs logicielles qui permettent d'accéder aux données saisies. Découvrez ci-dessous ce que nous avons trouvé.
Pourquoi Logitech ?
À notre avis, les dispositifs d'entrée de la société Logitech sont parmi les plus qualitatifs et confortables. La plupart des appareils que nous avons reposent sur une solution Logitech. – c'est un récepteur dongle universel permettant de connecter jusqu'à 6 appareils. Tous les appareils compatibles avec la technologie Logitech Unifying sont marqués du logo correspondant. Facile à utiliser permet de gérer la connexion des claviers sans fil à l'ordinateur. Le processus de connexion d'un clavier à un dongle récepteur Logitech, ainsi que la technologie elle-même, sont abordés, par exemple, .
Dongle récepteur avec support Logitech Unifying
Un clavier peut devenir une source d'informations pour des attaquants. La société Logitech, prenant en compte la menace possible, a veillé à la sécurité – en appliquant un algorithme de chiffrement AES128 dans le canal radio du clavier sans fil. La première pensée qui peut traverser l'esprit d'un attaquant dans ce contexte est l'interception d'informations clés lors de leur transmission par le canal radio lors de la procédure d'appairage. En effet, en possédant la clé, il est possible d'intercepter les signaux radio du clavier et de les déchiffrer. Cependant, les utilisateurs ont très rarement (ou même jamais) besoin de lier un clavier via la procédure Unifying, et un hacker avec un récepteur radio scanner devra attendre longtemps. De plus, le processus d'interception lui-même n'est pas si simple. Lors de la dernière étude en juin 2019, l'expert en sécurité Markus Mengs a publié en ligne la découverte d'une vulnérabilité dans les anciennes versions des firmware des dongles USB Logitech. Cela permet aux attaquants ayant un accès physique aux appareils d'obtenir les clés de chiffrement du canal radio et d'injecter des frappes de touches (CVE-2019-13054).
Nous allons parler de notre étude de sécurité sur le dongle Logitech basé sur le SoC NRF24 de Nordic Semiconductor. Et commençons, peut-être, par le canal radio.
Comment les données « volent » dans le canal radio
Pour l'analyse temporelle et fréquentielle du signal radio, nous avons utilisé un récepteur SDR basé sur le dispositif Blade-RF en mode analyseur de spectre (vous pouvez également lire à ce sujet ).
Dispositif SDR Blade-RF
Nous avons également examiné la possibilité d'enregistrer les quadratures du signal radio à une fréquence intermédiaire, afin de les analyser ensuite à l'aide de méthodes de traitement numérique du signal.
La Commission État des Fréquences de la Fédération de Russie à être utilisée par des dispositifs à courte portée dans la plage de fréquences de 2400 à 2483,5 MHz. C'est une plage très « peuplée », dans laquelle on ne rencontre que toutes sortes de choses : Wi-Fi, Bluetooth, divers télécommandes, systèmes de sécurité, détecteurs sans fil, souris et claviers et autres dispositifs numériques sans fil.
Spectre de la bande de 2,4 GHz
La situation de brouillage dans la bande est assez complexe. Mais malgré cela, la société Logitech a réussi à assurer une réception fiable et stable en utilisant le protocole Enhanced ShockBurst dans le transceiver NRF24 combiné avec des algorithmes d'adaptation de fréquence.
Les canaux dans la bande sont disposés à des positions de valeurs entières en MHz, comme défini dans NRF24 Nordic Semiconductor – un total de 84 canaux dans la grille de fréquences. Le nombre de canaux de fréquence utilisés simultanément par Logitech est bien sûr moins élevé. Nous avons identifié l'utilisation d'au moins quatre. En raison de la bande passante limitée du spectre analysé, il n'a pas été possible de déterminer la liste exacte des positions de fréquence utilisées, mais cela n'était pas nécessaire. Les informations de la clavier au dongle-récepteur sont transmises en mode Burst (avec de courtes activations du transmetteur) en utilisant la modulation de fréquence à deux positions GFSK à une vitesse symbolique de 1 Mo/s :
Signal radio du clavier en représentation temporelle
Le récepteur utilise le principe de réception par corrélation, de sorte que le paquet transmis contient un préambule et une partie d'adresse. Le codage résistant au brouillage n'est pas utilisé, le corps des données étant chiffré selon l'algorithme AES128.
En général, l'interface radio du clavier sans fil Logitech peut être caractérisée comme complètement asynchrone avec compression statistique et adaptation de fréquence. Cela signifie que l'émetteur du clavier change de canal pour chaque nouveau paquet transmis. Le récepteur ne connaît à l'avance ni le temps de transmission, ni le canal de fréquence, mais seulement leur liste. Le récepteur et l'émetteur se rencontrent sur le canal grâce à des algorithmes de contournement et d'écoute de fréquence concordants, ainsi qu'à des mécanismes de confirmation Enhanced ShockBurst. Nous n'avons pas déterminé si la liste des canaux est statique. Il est probable que ses changements soient dus à l'algorithme d'adaptation de fréquence. Quelque chose de proche de la méthode PPRCH (reconfiguration pseudo-aléatoire de fréquence de travail) se devine dans l'utilisation des ressources de fréquence de la bande.
Ainsi, dans des conditions d'incertitude temps-fréquence, pour garantir la réception de tous les signaux du clavier, un attaquant devra contrôler en permanence l'ensemble de la grille de fréquence de la bande de 84 positions, ce qui nécessite des investissements temporels considérables. Ici, on comprend pourquoi la vulnérabilité d'extraction de clé via USB (CVE-2019-13054) est positionnée comme une possibilité d'injection des frappes de touches, et non comme un accès de l'attaquant aux données saisies au clavier. Il est évident que l'interface radio du clavier sans fil est conçue de manière suffisamment complexe et fournit une communication radio fiable entre les dispositifs Logitech dans des conditions d'interférences complexes dans la bande de 2,4 GHz.
Un regard sur le problème de l'intérieur
Pour l'étude, nous avons choisi l'un des claviers Logitech K330 que nous avons et le dongle Logitech Unifying.
Logitech K330
Jetons un œil à l'intérieur du clavier. Un élément intéressant à examiner sur le circuit imprimé est la puce SoC NRF24 de Nordic Semiconductor.
SoC NRF24 sur le circuit imprimé du clavier sans fil Logitech K330
Le firmware est stocké dans la mémoire interne, les mécanismes de lecture et de débogage sont désactivés. Malheureusement, le firmware n'a pas été publié dans les sources ouvertes. Par conséquent, nous avons décidé d'aborder le problème sous un autre angle : examiner le contenu interne du récepteur dongle Logitech.
L'intérieur du dongle est plutôt intéressant. Il se démonte facilement, embarque le NRF24 que nous connaissons avec un contrôleur USB intégré et peut être reprogrammé à la fois par USB et directement via un programmateur.
Dongle Logitech sans boîtier
Puisqu'il existe un mécanisme standard de mise à jour du firmware via (à partir de laquelle la version mise à jour du firmware peut être extraite), il n'est pas nécessaire de chercher le firmware à l'intérieur du dongle.
Ce qui a été fait : le firmware RQR_012_005_00028.bin a été extrait du corps de l'application Firmware Update Tool. Pour vérifier son intégrité, le contrôleur du dongle a été connecté via un câble :
Câble de connexion du dongle Logitech au programmateur ChipProg 48
Pour assurer l'intégrité du firmware, celui-ci a été placé avec succès dans la mémoire du contrôleur et a fonctionné correctement, le clavier et la souris étant connectés au dongle via Logitech Unifying. Il est possible de charger un firmware modifié en utilisant le mécanisme de mise à jour standard, car il n'y a pas de mécanismes de protection cryptographique prévues. Pour des raisons d'étude, nous avons utilisé une connexion physique au programmateur, car cela permet un débogage beaucoup plus rapide.
Analyse du firmware et attaque sur l'entrée utilisateur
Le chip NRF24 est conçu sur la base d'un cœur de calcul Intel 8051 dans une architecture Harvard traditionnelle. Pour le cœur, le transceiver agit comme un périphérique et est placé dans l'espace d'adresse comme un ensemble de registres. La documentation sur le chip et des exemples de code source peuvent être trouvés sur Internet, donc le désassemblage du firmware ne pose pas de difficultés. Lors du reverse engineering, nous avons localisé les fonctions pour obtenir des données sur les pressions de touches à partir du canal radio et les convertir en format HID pour les transmettre au host via l'interface USB. Le code d'injection a été placé dans les adresses mémoire libres, incluant des outils pour intercepter le contrôle, sauvegarder et restaurer le contexte d'exécution original, ainsi qu'un code fonctionnel.
Le paquet de pression ou de relâchement de la touche reçu par le dongle depuis le canal radio est déchiffré, converti en un rapport HID standard et envoyé à l'interface USB comme si c'était un clavier ordinaire. Dans le cadre de cette recherche, la partie du rapport HID contenant le byte des flags-modificateurs et un tableau de 6 bytes avec les codes des touches est celle qui nous intéresse le plus (pour référence, l'information sur le HID) ).
Structure du rapport HID :
// Keyboard HID report structure.
// See https://flylib.com/books/en/4.168.1.83/1/ (last access 2018 december)
// "Reports and Report Descriptors", "Programming the Microsoft Windows Driver Model"
typedef struct{
uint8_t Modifiers;
uint8_t Reserved;
uint8_t KeyCode[6];
}HidKbdReport_t;Juste avant la transmission de la structure HID à l'hôte, le code injecté prend le contrôle, copie en mémoire 8 bytes de données HID natives et les envoie sur le canal radio secondaire en clair. Dans le code, cela se présente comme suit :
//~~~~~~~~~ Send data via radio ~~~~~~~~~~~~~~~~~~~~~~~~~>
// Profiling have shown time execution ~1.88 mSec this block of code
SaveRfState(); // save transceiver state
RfInitForTransmition(TransmitRfAddress); // configure for special trnsmition
hal_nrf_write_tx_payload_noack(pDataToSend,sizeof(HidKbdReport_t)); // Write payload to radio TX FIFO
CE_PULSE(); // Toggle radio CE signal to start transmission
RestoreRfState(); // restore original transceiver state
//~~~~~~~~~ Send data via radio ~~~~~~~~~~~~~~~~~~~~~~~~~<Le canal secondaire est organisé à la fréquence que nous avons établie avec des caractéristiques particulières de vitesse de manipulation et de structure de paquet.
Fonctionnement du transcepteur dans la puce est basé sur un graphe d'états, dans lequel le protocole Enhanced ShockBurst est harmonieusement intégré. Nous avons découvert que juste avant la transmission des données HID à l'interface USB de l'hôte, le transcepteur se trouvait dans un état IDLE. Cela permet sa reconfiguration en toute sécurité pour travailler sur le canal secondaire. Le code injecté intercepte le contrôle, conserve la configuration originale du transcepteur dans son intégralité et le passe à un nouveau mode de transmission sur le canal secondaire. Le mécanisme de confirmations Enhanced ShockBurst est désactivé dans ce mode, les données HID sont transmises en clair dans l'air. La structure du paquet sur le canal secondaire est présentée sur l'image ci-dessous, les épures du signal ont été obtenues après démodulation et avant la restauration de la synchronisation des données. La valeur de l'adresse a été choisie pour faciliter l'identification visuelle du paquet.
Signal démodulé du paquet Burst sur le canal secondaire
Après la transmission du paquet sur le canal secondaire, le code injecté restaure l'état du transcepteur. Il est maintenant de nouveau prêt à fonctionner en mode normal dans le contexte du firmware original.
Dans les domaines de fréquence et de temps-fréquence, le canal secondaire apparaît comme illustré sur l'image :
Représentation spectrale et temporelle du canal secondaire
Pour tester le fonctionnement de la puce NRF24 avec un firmware modifié, nous avons assemblé un banc d'essai comprenant un dongle Logitech avec un firmware modifié, un clavier sans fil et un récepteur basé sur un module chinois avec une puce NRF24.
Schéma de capture du signal radio du clavier sans fil Logitech
Module basé sur le NRF24
Sur le banc d'essai, lors du fonctionnement normal du clavier après sa connexion au dongle Logitech, nous avons observé la transmission de données ouvertes concernant les frappes de touches sur un canal radio auxiliaire et une transmission normale de données chiffrées sur l'interface radio principale. Ainsi, nous avons réussi à intercepter directement les saisies au clavier de l'utilisateur :
Résultat de l'interception de la saisie au clavier
Le code injecté introduit de légers délais dans le fonctionnement du firmware du dongle. Cependant, ils sont trop insignifiants pour que l'utilisateur puisse les remarquer.
Comme vous pouvez le comprendre, pour un tel vecteur d'attaque, n'importe quel clavier Logitech compatible avec la technologie Unifying peut être utilisé. Étant donné que l'attaque cible le récepteur Unifying, qui est inclus avec la plupart des claviers Logitech, elle n'est pas dépendante d'un modèle spécifique de clavier.
Conclusion
Les résultats de l'étude poussent à réfléchir à une possible utilisation de ce scénario par des attaquants : si un hacker remplace le dongle récepteur du clavier sans fil Logitech de la victime, il pourra accéder aux mots de passe des comptes de la victime avec toutes les conséquences qui en découlent. Il ne faut pas oublier qu'il est également possible d'injecter des frappes au clavier, ce qui signifie qu'exécuter du code arbitraire sur l'ordinateur de la victime ne pose pas de difficulté.
Et si un attaquant pouvait modifier le firmware de n'importe quel dongle Logitech à distance via USB ? Alors, à partir de dongles situés à proximité, il serait possible de créer un réseau de relais et d'augmenter la distance de fuite. Bien qu'un attaquant 'financièrement équipé' disposerait de moyens modernes de réception radio avec des systèmes hautement sélectifs, des récepteurs radio sensibles ayant un temps de commutation de fréquence court et des antennes directionnelles étroites, pour 'écouter' les saisies au clavier et atteindre les touches même depuis le bâtiment voisin.
Équipement professionnel de réception radio
Étant donné que le canal de transmission sans fil du clavier Logitech est suffisamment sécurisé, le vecteur d'attaque trouvé nécessite un accès physique au récepteur, ce qui limite considérablement l'attaquant. La seule option de protection dans ce cas aurait pu être l'utilisation de mécanismes de protection cryptographique pour le firmware du récepteur, par exemple une vérification de la signature du firmware chargé du côté du récepteur. Malheureusement, le NRF24 ne le prend pas en charge et, dans le cadre de l'architecture actuelle de l'appareil, il est impossible de mettre en œuvre une protection. Alors, prenez soin de vos dongles, car le vecteur d'attaque décrit nécessite un accès physique à ceux-ci.
Raccoon Security est une équipe spécialisée d'experts du NTС «Vulkan» dans le domaine de la sécurité de l'information pratique, de la cryptographie, de l'électronique, de l'ingénierie inverse et de la création de logiciels bas niveau.
Source : habr.com
