Cybersécurité et internet des objets

Panorama des objets communicants

Les protocoles

Le célébrissime Wifi, utilisé pour les réseaux locaux (WLAN). Il permet de communiquer avec un débit de plusieurs centaines de Mb/s jusqu'à plusieurs centaines de mètres. Son principal inconvénient est sa forte consommation électrique. Quasiment n'importe quel ordinateur équipé d'une carte WiFi permet d'en analyser les couches basses (des utilitaires opensource comme la suite airodump-ng permettant de tirer le meilleur des équipements à votre disposition). Des équipements plus spécialisés existent aussi, comme les PineApple de chez Hack5.

Le Bluetooth, utilisé pour des réseaux personnels sans fil (WPAN). Il permet de communiquer jusqu’à quelques centaines de mètres avec un débit maximum de 100Mb/s (même si, en pratique, il se retrouve principalement utilisé à moins de 10m de distance). Comme le Wifi, son principal inconvénient est sa consommation électrique importante. Pour pallier ce problème, une variante appelée Bluetooth Low Energy a été créée. Son implémentation nécessite beaucoup moins d'énergie mais offre un débit bien plus faible. Là aussi, un ordinateur équipé d'un adaptateur bluetooth permet de réaliser des investigations basiques sur cette technologie, et des outils dédiés comme les adaptateurs bluesnarf permettent d'aller plus en profondeur.

Le ZigBee, très utilisé pour la domotique. Il s'agit d'un protocole développé par la ZigBee Alliance qui permet de communiquer à une distance de quelques mètres avec un débit maximum de quelques centaines de kb/s. Son avantage principal est son faible coût de production et sa très faible consommation énergétique (un nœud ZigBee sur batterie peut avoir une autonomie de plusieurs années). De part son orientation très domotique, les adaptateurs standards pour PC sont quasiment inexistants et il faudra donc se rabattre sur des kits de développements comme celui du CC2531 de chez TI (dont le coût d'acquisition reste néanmoins très raisonnable).

Le RFID (Radio Frequency Identification), ces petits dispositifs passifs qui utilisent l'énergie électromagnétique transmise par l'émetteur pour recevoir et traiter des informations. La portée de ce type d'appareil s'étend de quelques centimètres, à quelques dizaines de mètres. Parmi les différents types de RFID, le plus utilisée est le NFC (Near Field Contact) qui a une portée limitée à quelques centimètres et permet un débit de quelques centaines de kb/s. Ce type de communication, déjà très communs dans les badges de transports ou d'accès, s'invitent depuis peu dans nos cartes de crédit et nos passeports. Certains ordinateurs portables sont équipés de modules permettant de communiquer avec certaines de ces cartes, mais un équipement dédié comme les Proxmark restent essentiels pour toute analyse poussée de sécurité.

De nombreux autres protocoles existent, mais sont moins utilisés: ZWave, 6LoWPAN, HbbTV, Wimax et d'autres encore. Les protocoles sont donc, nous l'avons vu, légion ; mais les objets également. Nous pouvons distinguer plusieurs grands secteurs d'application.

Les secteurs d'application

La domotique : de la sonnette aux caméras de surveillance en passant par le réfrigérateur ou la station météo, de plus en plus d'objets sont reliés à internet, le plus souvent via un réseau WiFi. On retrouve également chez nous de plus en plus de compteurs d'eau, d'électricité ou encore de gaz fonctionnant grâce aux technologies sans fil, mais aussi des volets commandés à distance, portes de garage, thermostats, ou diffuseurs de contenu (ChromeCast par exemple).

Les équipements sportifs et médicaux : les objets connectés sont également de plus en plus utilisés afin de surveiller les activités du corps humain ou pour traiter certaines maladies. On retrouve par exemple des pompes à insuline ou encore des pacemakers contrôlés à distance. Parmi les équipements sportifs sans fil on peut citer les cardio-fréquencemètres, montres GPS ou encore les bracelets connectés.

Les fameuses « villes intelligentes » : les feux de signalisation, caméras de vidéoprotection, l’éclairage publique, ou encore les capteurs mesurant la qualité de l'air sont autant d’équipements contrôlés à distance qui transforment nos villes en « Smart Cities ».

Les transports : Certaines voitures sont aujourd’hui équipées du WiFi ou de Bluetooth pour le confort des usagers. Des clés de voitures permettent également de déverrouiller le véhicule à distance. Plus généralement, les drones, avions ou encore les bateaux sont très dépendants des technologies sans fil pour partager leur position ou être contrôlés à distance.

De nombreux autres équipements modernes : dans l'informatique aussi les technologies sans fil sont très présentes. On trouve de plus en plus de claviers, de souris, imprimantes ou encore de webcams sans fil. Tout ce qui était autrefois relié avec un câble possède aujourd'hui un équivalent sans fil.

Dans cet article, nous séparons tous ces objets en deux grandes familles : les objets qui sont directement connectés à Internet, et ceux qui ne le sont pas (ou indirectement).

Systèmes connectés à Internet

Qu'un objet caché derrière une adresse IP soit un réfrigérateur dans la cuisine de monsieur Michu ou un serveur dans le plus gros datacenter de Google n'a finalement que peu d'importance. Vu d'Internet, ce ne sont que des interlocuteurs parlant IP. Ils sont tous les deux également exposés à des risques de piratage. Ils sont "voisins". Ce qui change, c'est le niveau de prise de conscience de la sécurité chez ceux qui les conçoivent et les administrent. En 2015, Charlie MILLER et Chris VALASEK ont démontré que des voitures (dont les Jeep Cherokee modèle 2014 vendues aux USA) étaient connectés à Internet (via le réseau GSM de l'opérateur "Sprint") et présentaient des vulnérabilités permettant d'en prendre le contrôle à distance. Le plus choquant, à mes yeux, ce n'est pas qu'une telle vulnérabilité existe, c'est sa trivialité d'exploitation. La "vulnérabilité" en mérite à peine le nom tant elle résulte de choix volontaire des concepteurs. On pourrait plus facilement appeler cela une « fonctionnalité » pensée en dépit des bases de sécurisation les plus élémentaires. Exactement le genre de « fonctionnalité » qu'il est aujourd'hui impensable de croiser sur un serveur.

En effet, le système multimédia embarqué dans ces véhicules expose, sans aucune protection de quelque nature que ce soit, une interface permettant d’interagir avec de nombreux services (c'est une interface DBUS sur TCP exposée à l'adresse 0.0.0.0:6667). L'un de ces services propose, tout naturellement, la commande "execute" qui permet, comme son nom le laisse deviner, d'exécuter n'importe quelle commande sur le système d'exploitation (un QNX) avec les droits les plus élevés (root), sans aucune authentification. À ce point, on a donc la possibilité d'exécuter, depuis n'importe quelle adresse IP de l'opérateur Sprint, des commandes arbitraires sur le système multimédia de toute une famille de véhicules sortis depuis 2014. Ce type de vulnérabilité n'existe plus sur les serveurs depuis la fin des années 80 (du siècle dernier). La défense en profondeur a, évidemment, elle aussi été "oubliée" et, du système multimédia, il est possible d'agir sur les commandes de conduite du véhicule (en profitant de la porosité dans les bus CAN).

Cet exemple montre à quel point c'est la prise de conscience des concepteurs et des administrateurs des objets connectés qui est en cause la plupart du temps, et pas le talent d'un hypothétique hacker « petit génie de l'informatique ». Le botnet MIRAI est, lui aussi, une illustration de ce principe. Ce logiciel permet de créer des réseaux Zombies composés principalement d'IOT qu'il pirate généralement de la plus simple des façons : en devinant le login et le mot de passe par défaut de l'interface d'administration. Là encore, ce sont deux vulnérabilités évidentes et triviales qui sont la cause du problème : l'exposition d'interface d'administration sur Internet sans filtrage, et l'utilisation de login et mot de passe triviaux (généralement en telnet). L'affaire est loin d'être anecdotique puisque les botnets MIRAI auraient, entre autre, été utilisés pour mener de nombreuses attaques d'envergure, dont une visant le Libéria et affectant sensiblement l'ensemble des accès Internet du pays pendant toute une semaine.

Systèmes non-connectés à Internet

Les objets connectés non reliés à Internet ne sont pas pour autant protégés d'attaques extérieures. Bien que ces réseaux ne soient pas connectés directement à Internet, il est cependant souvent possible d'y accéder par le jeu d'interconnexion avec des réseaux qui, eux, sont connectés au monde extérieur. Par ailleurs ces systèmes utilisent le plus souvent les télécommunications sans fil pour être contrôlés à distance. Cela les expose à de nouveaux vecteurs d'attaques, jusqu'ici peu pris en compte par les constructeurs. Ces attaques sont à première vue plus compliquées à mettre en œuvre que les attaques classiques sur Internet. Elles nécessitent en effet de se déplacer près du système à étudier pour capter les signaux émis et demandent en général un long travail de préparation pour étudier et comprendre le protocole de communication, le plus souvent propriétaire. Cependant, un individu motivé et correctement préparé n'aura pas de difficulté à attaquer ce type de système. En guise d'exemple, nous allons nous intéresser à deux produits très différents, à cela près qu'ils sont tous deux communs et reposent sur les communications sans fil : les automates industriels dans un premier temps et les claviers et souris sans fil dans un second temps.

Automates industriels

Bien qu'invisibles du grand public, les automates industriels sont très répandus dans notre quotidien. On les retrouve par exemple dans les transports ferroviaires (pilotage d'aiguilleur), le traitement de l'eau (ouverture d'une vanne ou mise en service d'une pompe) ou, plus généralement, dans des usines de tout type (par exemple, nous avons récemment été amené à auditer un incinérateur dans lequel la chaîne de combustion était contrôlée à l'aide d'automates industriels).

Dans le cadre de travaux de recherche sur la sécurité de ces systèmes nous avons étudié spécifiquement un type d'automates très répandu en France. Utilisés pour la télégestion, ils permettent de centraliser et de remonter des alertes provenant de différents capteurs et de programmer des actions à déclencher en réponse à ces alertes (par exemple : ouverture d'une vanne de régulation lorsqu'un capteur mesure un trop plein d'eau dans un réservoir). Plusieurs cartes de communication sont disponibles pour ces automates : Wifi, Ethernet, GPRS, radio, RTC, etc. Dans cet article, nous n'allons aborder que les communications radio entre deux automates, étudiées à l'aide d'une carte HackRF combinée à GNU Radio (ce qui permet de faire de la radio logicielle à moindre coût).

Un travail préalable d'identification est nécessaire pour déterminer les caractéristiques techniques du système de communication visé. Grâce aux documentations fournies par le constructeur, aux données récoltées sur Internet et à un travail de rétro-ingénierie il est possible de déterminer les caractéristiques suivantes permettant de démoduler les signaux radios de notre automate cible :

• Type de modulation utilisée : FSK (modulation de fréquence)
• Canaux de communication : 869,425 / 869,475 / 869,525 / 869, 575 / 869,625 MHz
• Bande passante du signal : 10 kHz
• Débit des données : 10 kHz

Ces caractéristiques permettent d'implémenter dans GNU Radio un démodulateur afin de visualiser les signaux échangés.

Une fois le démodulateur construit, une seconde étape débute afin de décoder le protocole de communication. Il s'est avéré que les automates auxquels je me suis intéressé communiquaient avec le protocole Modbus, extrêmement fréquent dans ce domaine d'application. Modbus est architecturé autour d'un fonctionnement maître/esclave : le maître initie la connexion et demande à l'esclave d'exécuter des fonctions prédéterminées. Ces fonctions, identifiées par un code entier, permettent d'effectuer des opérations de lecture et d'écriture dans la mémoire de l'automate. Une opération de lecture permet de récupérer la valeur d'un registre (correspondant à la hauteur d'eau d'un réservoir par exemple) alors qu'une opération d'écriture permet de déclencher certaines actions prédéfinies (mise en route d'un moteur par exemple).

En termes de sécurité le bilan de nos études est plutôt inquiétant. De nombreuses propriétés importantes de sécurité ne sont pas respectées. La confidentialité des échanges n'est pas assurée : les messages n'étant pas chiffrés, leur contenu est donc accessible à quiconque parvient à démoduler les signaux. L'authenticité des messages n'est pas non plus vérifiée : le destinataire du message est identifié grâce à un code en début de paquet, mais aucun mécanisme n'est prévu pour authentifier l'émetteur. Enfin, la disponibilité des automates n'est pas non plus garantie puisque, à l'aide d'une antenne plus puissante que celle des automates, il est très facile de brouiller les communications. Plusieurs scénarios d'attaques découlent de ces observations. Selon la nature de l'infrastructure étudiée et du niveau de connaissance de l'attaquant, ils seront plus ou moins faciles à mettre en œuvre :

• Brouillage des signaux échangés pour empêcher un automate de remonter une alarme, ou pour paralyser l'ensemble du réseau.
• Interception des messages pour en étudier le contenu et, ainsi, obtenir des informations sur le fonctionnement interne d'un système industriel.
• Rejeu de messages interceptés. Même sans comprendre le contenu d'un message, et dans certains cas même sans parvenir à démoduler le signal, il est possible de l'enregistrer et le rejouer par la suite. Ce type d'attaque permettrait, par exemple, de très simplement faire basculer un aiguillage.
• Pour un attaquant ayant une grande compréhension du système il est également possible de forger ses propres messages et de se faire passer pour un autre automate afin d'interagir finement avec le réseau.
• Scan du réseau. Les automates sont identifiés par un code en début de message pour déterminer à qui est destiné le message. En incrémentant ce code et en observant les réponses pour chacun d'entre eux, il est possible de déterminer quels sont les automates présents dans le réseau.

Clavier/Souris sans fil

À l'opposé des automates industriels, en termes de visibilité, nous avons les souris et claviers sans fils. Ces interfaces homme-machine se retrouvent quasiment partout et nous en avons tous eu un entre les mains à un moment ou un autre. Historiquement, ces périphériques communiquaient principalement en infra-rouge, puis le bluetooth a rapidement relégué cette technologie au rang d'antiquité, avant de céder à son tour la part du lion à des protocoles propriétaires sur chipset NRF24. La très faible consommation de cette puce radio explique probablement son hégémonie au sein des constructeurs de clavier et de souris sans fil. En 2014, nous nous sommes penchés sur la sécurité de ces équipements dans le cadre d'un audit.

Les puces NRF24L01+ que nous avons identifiées dans plusieurs claviers à notre disposition (simplement en les démontant et en lisant les références des puces radios), modulent en GFSK sur des canaux démarrant à 2.4GHz et s’étalant sur 1MHz ou 2MHz. Ce sont d'ailleurs ces même puces que nous retrouvons abondamment pour assurer la communication de drônes quadricoptères low-cost.

En lui-même, le protocole de communication de ces puces souffre des même faiblesses que celles identifiées sur les automates industriels : il n'offre pas de chiffrement, pas d'authentification de l'émetteur, et pas de résistance aux dénis de service. L'implémentation de ces fonctionnalités de sécurité est reléguée aux protocoles de plus haut niveau. Ce choix de la part du constructeur des puces est totalement compréhensible puisque sa tâche consiste à fournir des puces de communication radio fonctionnant avec une très faible consommation. Il ne peut présumer du niveau de sensibilité des applications dans lesquelles seront intégrées ces puces, et laisse à chaque constructeur intégrant ce composant le soin d'implémenter les fonctions de sécurité dont il a besoin dans les protocoles de plus haut niveau. La puce en elle-même ne propose que deux protocoles, le plus simple « ShockBurst » dont les paquets sont constitués comme suit :

Préambule d'un octet | Adresse de destination sur 3 à 5 octets | charge utile sur 0 à 32 octets | CRC facultatif sur 0, 1, ou 2 octets

Et le protocole le plus avancé « Enhanced Shockburst » qui n'ajoute qu'un en-tête de 9bits au protocole « ShockBurst ». Cet en-tête contenant, dans l'odre, la taille de la payload (sur 6 bits), un compteur de paquet (sur 2 bits), et un bit d'acknowledgement. Les paquets Enhanced Shockburst ressemblent donc à ceci :

Préambule d'un octet | Adresse sur 3 à 5 octets | en-tête sur 9 bits | charge utile sur 0 à 32 octets | CRC facultatif sur 0, 1, ou 2 octets

Nous voyons bien que rien dans ces paquets n'offre les fonctions de sécurité dont nous avons discuté préalablement. En effet, il n'y a aucune authentification de l’émetteur (pour être précis, il n'y a même pas d'identification de l'émetteur), et aucune protection contre le rejeu dans la version originale du protocole (contre une très faible protection dans la version améliorée puisqu'il y a bien un compteur de paquet mais que celui-ci n'occupe que 2 bits). La puce n'offre aucune fonctions native de chiffrement des payloads.

Nous avons donc analysé les protocoles propriétaires qui avaient été implémentés sur cette couche de communication radio afin de déterminer si des propriétés de sécurité avaient été ajoutées. Force est de constater qu'il existe une grande diversité dans les fonctions de sécurité implémentées en fonction des marques et des modèles. En 2014, nous avons pu vérifier que les périphériques de la marque Logitech utilisaient un chiffrement AES afin de protéger leurs communication de haut niveau ; les périphériques de la marque Microsoft utilisaient une obfuscation à base de XOR (dont la clef n'était autre que l'adresse du périphérique de destination, qui circule en clair au tout début des paquets ShockBurst et Enhanced Shockburt comme vous avez pu le voir…) ; et plusieurs marques bas de gamme expédiaient directement les paquets USB-HID brut dans le canal radio sans les protéger d'aucune façon.

L'absence de fonctions de sécurité sur un grand nombre de périphériques ouvre donc la voie à des attaques, potentiellement triviales (écoute des mots de passe tapés au clavier, injection de frappes pour coder un virus « en place », etc.). De nos jours, il est facile d'acquérir un matériel de radio-logicielle et d'écouter ou d'injecter des données arbitraires dans la bande libre des 2.4GHz. Nous aurions donc pu en rester là, mais nous avons jugé que, dans un effort de sensibilisation, il était intéressant de simplifier au maximum les pré-requis pour mener ce type d'attaque. En exploitant une fonctionnalité non-documentée de la puce NRF24 elle-même, et des astuces statistiques sur les bruits radio ambiants, il a été possible de ré-implémenter une attaque imaginée par Travis Goodspeed et qui permet d'utiliser une simple puce NRF24 afin d’interagir avec les communications d'autres puces NRF24 à portée. Nous pouvons donc nous affranchir de la couche de radio-logicielle. En l'espèce, il est possible de détecter les communications d'autres puces NRF24, de les écouter, et d'y injecter des paquets arbitraires simplement avec notre propre puce NRF24 (qui, par conception, coûte extrêmement peu cher). Nous avons fait la démonstration d'un matériel complet permettant de réaliser cette attaque pour moins d'une dizaine d'euros et dont les seuls pré-requis logiciels sont un interpréteur python et un module de communication série. Nous invitons le lecteur curieux à consulter la présentation « La radio qui venait du froid », présentée au SSTIC 2014, pour plus de détails sur cet équipement.

Depuis, nous avons identifié cette technologie sur plusieurs modèles de drones bas de gamme ; ce qui confirme encore l'intérêt de regarder les protocoles propriétaires que les constructeurs implémentent sur la couche radio fournit par la puce NRF24. Bien souvent, les constructeur de ces IOT n'ont aucune notion de sécurité et, lorsqu'ils en ont, ils s'imaginent que la communication radio est de toute façon sécurisée car sans fil. En regardant ces protocoles, on peut donc encore aujourd'hui trouver des vieilleries du même acabit que la « fonctionnalité » permettant d'exécuter des commandes systèmes à distance sans aucune authentification sur votre véhicule : l'utilisation d'un XOR en lieu et place d'un mécanisme de chiffrement digne de ce nom par exemple.

Conclusion

Les « IOT » recouvrent une large variété de technologies et d'objets. Ils ont en commun de ne pas correspondre à l'image populaire de ce qu'est un ordinateur (bien qu'ils soient, pour la plupart de façon évidente, des Systèmes de traitement automatisés de données), d'être communicants, et de partager un gros risque de failles de sécurité triviales. En fonction de la nature de l'objet, sa surface d'exposition peut être colossale (si votre voiture est connectée directement à Internet) ou plus réduite (si votre brosse à dent est joignable en bluetooth). De même, les conséquences peuvent être dramatiques (s'il s'agit d'un système de contrôle industriel d'usine chimique) ou plus bénignes (s'il s'agit d'un podomètre). Les compétences requises pour concevoir ces systèmes de façon sécurisée ne sont pas si différentes des compétences de ceux qui sécurisent des systèmes informatiques plus conventionnels. En revanche, les techniques d'audit, elles, peuvent demander une adaptation lorsque ce sont les vecteurs de communications alternatifs qui sont ciblés (bluetooth, zigbee, radio propriétaire, …). Comme souvent donc, plus la sécurité est prise en compte tôt dans un projet, moins elle coûte cher.