La sécurité de l’IoT est un enjeu clé pour les organisations. Dans tous les secteurs et domaines d’activité (santé, industrie, services, transport, énergie, etc.), l’IoT est synonyme de développement et de croissance.
Actuellement, on estime à plus de 15 milliards d’objets IoT en service à travers le monde. Ce nombre pourrait doubler d’ici 2030. Cependant, cette prolifération des objets connectés s’accompagne de nouveaux enjeux, notamment en termes de sécurité.
La sécurité de l’IoT : un enjeu clé pour les concepteurs d’objets connectés
Cependant, les opportunités offertes par l’IoT vont de pair avec une exposition accrue aux risques cybersécurité.
Au-delà des risques liés à la sécurité des serveurs, des interfaces web et des applications mobiles, la sécurité de l’IoT repose également sur les protocoles de communication utilisées, le logiciel embarqué – firmware – ainsi que l’architecture du hardware. Toutes ces composantes des systèmes IoT permettent de répondre à des besoins fonctionnels.
Cependant, la conception « appropriée » d’un système IoT ne doit pas reposer uniquement sur les besoins fonctionnels. Elle doit également tenir compte des considérations de sécurité pour se prémunir de vulnérabilités pouvant compromettre l’ensemble de l’écosystème IoT.
Pour garantir la sécurité des systèmes IoT contre les attaques, des mesures de sécurité spécifiques sont nécessaires : configurations et implémentations sécurisées, durcissement – hardening – des systèmes, chiffrement des communications, utilisation de protocoles sécurisés, gestion sécurisée des droits et des accès, etc.
Des tests d’intrusion IoT sont également un bon moyen de détecter les failles existantes sur les objets connectés.
Dans cet article, nous nous attarderons sur les principaux vecteurs d’attaques IoT qui pourraient mener à la compromission d’un objet connecté.
Quels sont les principaux vecteurs d’attaques IoT ?
Interfaces web
Les interfaces web sont des vecteurs privilégiés par des attaquants. En effet, les objets connectés disposent généralement d’un site web standard permettant d’interagir avec eux.
Cette interface web est soumise aux mêmes exigences de sécurité que n’importe quel autre site : protection par mot de passe, résistance aux attaques DoS, mises à jour régulières des composants, etc.
Même si elle peut sembler simpliste, une interface web reste un serveur à part entière et doit être traitée comme tel. En outre, de nombreux objets connectés communiquent par Internet avec des serveurs backend, souvent via HTTP ou via des websockets. Il est crucial de sécuriser ce trafic dans les deux sens afin de garantir un environnement sécurisé.
Réseaux WI-FI
Lorsqu’un objet est connecté à un réseau Wi-Fi, plusieurs aspects de sécurité doivent être scrupuleusement vérifiés :
- La connexion est-elle sécurisée avec un chiffrement WPA2 et un mot de passe fort ?
- En cas d’attaque Man in the Middle, l’attaquant peut-il se faire passer pour l’un des serveurs avec lesquels l’objet communique ? Utilise-t-on du certificate pinning pour vérifier l’authenticité des serveurs ?
- Si la mise à jour de l’objet se fait via internet, un attaquant peut-il se faire passer pour un serveur « officiel » et tenter de pousser une mise à jour malveillante sur l’objet connecté ?
Si l’objet lui-même sert de point d’accès Wi-Fi, les mêmes questions de sécurité se posent, mais il doit en plus être protégé des attaques IoT internes à son réseau.
Communications Bluetooth
Le Bluetooth est également très populaire dans l’IoT, et pour de bonnes raisons ! Il facilite la connectivité avec d’autres appareils et permet de mettre en place un protocole de communication et d’instruction efficace. Cependant, plusieurs critères doivent être remplis pour garantir sa sécurité.
L’appairage doit être unique et les communications doivent être chiffrées. Le GATT (Generic Attribute Profile, l’équivalent Bluetooth d’une API) doit être rigoureusement surveillé. Les arguments fournis par le client doivent être traités comme potentiellement malveillants, seules les informations nécessaires doivent être communiquées, et les fonctionnalités de debug doivent être désactivées.
Ports de debug
En ce qui concerne la désactivation des fonctionnalités de debug, les ports JTAG et UART en sont des exemples parfaits. Ces points d’entrée physiques, souvent sous forme de points de soudure, peuvent transmettre des informations cruciales et permettre la reconfiguration de l’objet, le dump de sa mémoire, la modification de données, etc.
Bien qu’ils soient extrêmement utiles durant la phase de développement, ces ports doivent impérativement être désactivés lors du passage en production. Cette désactivation est généralement spécifique au modèle de carte qui les héberge et relève souvent de la responsabilité du fabricant des composants.
Hardware
En plus des ports de debug, qui sont des cibles évidentes, le hardware peut être attaqué plus directement par divers vecteurs. Parmi ces méthodes, on peut citer :
- Se connecter directement sur les interfaces SPI pour intercepter ou modifier les données qui y transitent.
- Vérifier si les données sont correctement chiffrées et si la clé de déchiffrement est implémentée de manière sécurisée (par exemple, via TPM ou un système similaire).
- Examiner si la mémoire et le code peuvent être lus ou copiés.
- Vérifier si le code est signé et si les puces peuvent être flashées pour y installer un logiciel personnalisé.
- Tester la possibilité de se connecter en tant que périphérique (tel qu’un capteur) et d’injecter des données pour manipuler le code de l’objet.
Sécuriser complètement le hardware d’un objet est complexe, surtout face à un attaquant ayant un accès illimité, du temps et les ressources nécessaires pour mener une attaque de grande envergure. L’objectif est de rendre l’attaque suffisamment complexe et coûteuse pour dissuader l’attaquant de poursuivre.
Autres formes de communication
Dans cet article, nous n’avons abordé que les principaux moyens de communication, mais il en existe de nombreux autres. Qu’il s’agisse de la couche réseau (comme Bluetooth, Wi-Fi, Zigbee, LoRa, LoRaWAN, Z-Wave, Thread, ou même les réseaux cellulaires classiques) ou de la couche applicative (comme HTTP, websockets, MQTT, AMQP, XMPP, DDS), chaque protocole présente ses propres spécificités, faiblesses, forces et vecteurs possibles d’attaques IoT. Chacun de ces protocoles doit être analysé et sécurisé individuellement pour garantir une protection optimale.
Conclusion
Cet article n’est qu’une introduction très générale du sujet. D’autres suivront pour détailler chacun de ces vecteurs d’attaques.
En attendant, retenez ceci : comme mentionné précédemment, un objet connecté doit être considéré au même titre que tout autre ordinateur relié à votre réseau. C’est un ensemble de composants hardware et software, chacun étant une potentielle porte d’entrée pour un attaquant.
En apparence inoffensive, un objet connecté peut devenir une cible de choix, souvent négligée du point de vue de la sécurité, ce qui peut le rendre plus vulnérable.
Auteur : Renaud CAYOL – Pentester @Vaadata