Depuis quelques temps, les chercheurs publient presque chaque semaine de nouvelles failles de sécurité liées à des lacunes de conception ou de configuration dans l'Internet des Objets: caméras de sécurité non protégées, objets connectés servant de cheval de Troie, etc. Comme nous fabriquons des modules réseau permettant de fabriquer des systèmes connectés, nous nous devons de faire le point de la situation, afin que vous sachiez à quoi vous en tenir.
Pour commencer, rappelons que la sécurité des systèmes informatiques doit être analysée dans son contexte: on ne protège pas de la même manière un serveur Web exposé au public qu'une machine de développement protégée par un firewall. On sait désormais que la sécurité absolue n'existe pas, et que les failles de sécurité se monnaient sur le Dark net. Le tout est d'adapter le niveau de protection, et donc l'effort qui devra être fourni pour contourner la protection, à l'enjeu de la sécurité. On distinguera trois environnements réseau:
- Le réseau public Internet, où les machines sont directement atteignables et donc les plus vulnérables
- Les réseaux semi-privés, comme les réseaux Wi-Fi, pour lesquels des protocoles de sécurité comme WPA2 sont censés éviter les accès non-autorisés, mais pour lesquels on sait que des vulnérabilités existent et que la sécurité est donc très relative.
- Les réseaux protégés par un firewall, où tous les accès physiques sont contrôlés, et dont le niveau de sécurité global dépend donc du maillon connecté le plus faible.
L'effort consacré à la protection dépend naturellement aussi de l'objet à protéger: on ne protège pas une salle de contrôle machine de la même manière qu'un système d'arrosage. Néanmoins, le danger de cet argument est d'oublier les effets collatéraux que la violation d'un système mineur peut avoir sur des systèmes critiques, en particulier comme relais pour abaisser le niveau de protection d'un réseau protégé.
Nous allons donc passer en revue les différents types de défauts de sécurité auxquels on peut être confronté via l'Internet des Objets, par ordre de gravité croissante, pour en analyser le risque vis-à-vis des modules Yoctopuce:
- perte de confidentialité: une personne étrangère accède à des informations qui ne lui sont pas destinées;
- déni de service: une personne bloque l'accès au système;
- violation de l'intégrité du système: une personne étrangère modifie des données ou altère le fonctionnement d'un système;
- utilisation à des fins malveillantes: une personne étrangère détourne le fonctionnement d'un objet connecté pour qu'il participe à une action malveillante, par exemple une attaque par déni de service distribuée (DDOS);
- utilisation comme cheval de Troie: une personne étrangère détourne l'objet connecté comme passerelle pour attaquer d'autres machines sur le réseau local.
Confidentialité
La méthode de base pour la protection de la confidentialité est le cryptage. Pour qu'elle soit efficace, elle doit être basée sur des méthodes récentes, comme TLS: en effet, SSL n'est plus considéré comme sûr. Malheureusement, en raison de la taille du processeur utilisé dans nos modules, nous n'avons pas pu y inclure TLS directement. Les communications ne sont donc pas cryptées. Si nos modules étaient utilisés pour des transférer des données sensibles, cela serait un problème. Mais les données transmises par nos modules ne sont a priori pas critiques, puisqu'il ne s'agit que de mesures ou d'état de modules de commande. Par ailleurs, sur un réseau protégé moderne (sans Wi-Fi), un utilisateur ne peut pas accéder aux communications des autres utilisateurs à moins d'avoir précédemment compromis l'infrastructure réseau, ce qui représenterait dans tous les cas un défaut bien plus grave. Donc cette limitation n'est en générale pas critique.
Par les cas exceptionnels où un cryptage de la communication avec nos modules serait indispensable, la solution est de mettre nos modules derrière un pare-feu doté d'une fonction VPN (réseau privé virtuel), comme les appareils ZyWALL par exemple. Un VPN offre un cryptage bien plus sérieuse qu'une simple connexion https, de même qu'une protection accrue contre tous les autres risques de sécurité.
Pour les cas sensibles, l'utilisation d'un pare-feu avec fonction VPN offre une bien meilleure sécurité qu'une connexion HTTPS, et protège également contre les autres risques de sécurité
Déni de service
Les attaques par déni de services consistent empêcher un système de fonctionner normalement. Cela peut être soit en le faisant planter via un bug connu, soit en le surchargeant par des communications inutiles, de sorte à ce qu'il ne soit plus en mesure de répondre aux requêtes légitimes.
Il est quasiment impossible de protéger un système contre une attaque active par des communications inutiles: en y mettant les moyens, un attaquant doté de suffisamment de ressources pourra toujours d'une manière ou d'une autre surcharger un système connecté au réseau.
Par contre, la protection contre les bugs causant des dénis de services est possible, et les modules Yoctopuce sont bien placés de ce côté-là. Il faut savoir que contrairement à la plupart des objets connectés, les modules Yoctopuce ne sont pas basés sur un système d'exploitation Linux ou un autre noyau de ce type. Par conséquent, la plupart des bugs répertoriés dans les recoins obscurs d'Internet ne s'appliquent pas aux modules Yoctopuce. D'autre part, les modules Yoctopuce sont dotés d'un watchdog: en cas de perte de connexion du module pendant une durée déterminée, le module va automatiquement effectuer un redémarrage pour se retrouver dans son état normal.
Intégrité
Pour protéger l'intégrité d'un système basé sur des objets connectés, il faut mettre en place un contrôle d'accès sur les connexions entrantes. Sur tous nos modules, il est possible de configurer des mots de passe pour sécuriser l'accès direct par le réseau. Lors d'un accès par HTTP, l'identification se fait par la méthode HTTP Digest. Lors d'un accès par WebSocket, c'est un échange similaire basé sur un challenge SHA qui est utilisé. Dans les deux cas, le secret est vérifié sans devoir transiter par le réseau. L'absence de cryptage ne représente donc pas de risque pour l'intégrité.
Si nécessaire, une protection accrue de l'intégrité peut être obtenue en masquant le système derrière un pare-feu NAT: dans cette configuration, il est impossible à quiconque de contacter directement le module Yoctopuce. Par contre, grâce au mécanisme de callback HTTP ou callback WebSocket, les modules Yoctopuce sont toujours en mesure de transmettre leurs données et de recevoir des commandes, mais seulement depuis l'hôte désigné dans la configuration du module. Cela réduit grandement les risques d'atteinte à l'intégrité, puisqu'il faut alors compromettre le serveur de contrôle pour pouvoir affecter le comportement du système. Dans le cas où une connexion directe serait néanmoins occasionnellement nécessaire, l'utilisation d'un pare-feu doté d'un VPN peut offrir un accès direct sécurisé le cas échéant.
Utilisation malveillante
On arrive là au centre des préoccupations actuelles relayées par la presse. En automne 2016, l'hébergeur français OVH et quelques autres cibles se sont retrouvées victime de la plus grosse attaque par déni de service jusqu'à ce jour, du fait d'une utilisation malveillante de 145'000 caméras connectées et autres objets de ce type. Ces appareils ont été détournés pour se mettre au service d'un serveur de commande malveillant. Comment cela a-t-il été possible?
La première faute pour les détenteurs de ces caméras a été de ne pas changer le mot de passe d'usine, permettant ainsi à n'importe qui de s'y connecter. Ensuite, ces caméras utilisaient un système Linux embarqué qui n'était naturellement pas mis à jour avec les derniers correctifs de sécurité. Les failles de sécurité connues ont donc permis d'injecter du code malveillant dans ces caméras, et ainsi de les détourner de leur comportement prévu.
Est-ce que ce problème aurait pu se produire avec des modules Yoctopuce ? C'est très improbable. En effet, contrairement aux petits systèmes Intel ou ARM utilisés par les machines Linux, le programme exécuté par les modules Yoctopuce ne se trouve pas en mémoire vive ou dans un système de fichiers: il est s'exécute directement depuis la mémoire non-volatile du processeur. Il n'y a pas de système d'exploitation dans un module Yoctopuce: le code ne transite pas par la mémoire vive utilisée pour le traitement des données. Par conséquent, il n'est pas possible d'exploiter un buffer overflow pour faire exécuter du code arbitraire à un module Yoctopuce: le seul code qui peut être exécuté est celui qui a été défini dans la mémoire non-volatile. Et la mémoire non-volatile ne peut pas être écrite par de simples d'instructions d'écriture en mémoire vive. Donc l'injection de code dans un module Yoctopuce n'est possible que par la réécriture d'un nouveau firmware, et la mise à jour du module par la procédure officielle, ce qui demande un bien plus gros investissement de temps pour l'attaquant.
Un objet connecté basé sur un système d'exploitation standard est plus vulnérable au buffer overflow qu'un YoctoHub, qui est basé sur une architecture Harvard où le code est séparé des données
Utilisation comme cheval de Troie
Le même principe d'injection de code dans un objet connecté peut causer un dommage direct au propriétaire de l'objet. En effet, si l'objet connecté se trouve dans un réseau sécurisé, il devient une passerelle d'entrée non-autorisée dans ce réseau, abaissant ainsi globalement son niveau de sécurité et permettant le lancement d'attaques sur toutes les machines. C'est donc un risque très important qui est évité grâce au fait que les modules Yoctopuce ne sont pas basés sur un noyau de système d'exploitation.
Les objets connectés qui dépendent d'un service de Cloud fourni par le fabricant de l'objet représentent un deuxième facteur de risque. En effet, si un attaquant parvient à prendre le contrôle du serveur de Cloud, il peut -selon la conception du système- prendre indirectement le contrôle de tous les objets connectés au service. Il y a donc un fort enjeu, qui peut justifier la mise en place de moyens importants pour y parvenir.
Les modules Yoctopuce, eux, sont intentionnellement libres de tout système de Cloud propriétaire. Chaque entreprise peut les connecter à ses propres serveurs Web, sous le contrôle de sa propre équipe de sécurité. Au final, l'effort nécessaire pour attaquer un serveur pilotant des objets Yoctopuce est à multiplier pour chaque entreprise à attaquer, puisque toutes les configurations seront différentes. L'investissement est donc beaucoup moins rentable pour l'attaquant.
Conclusion
Comme beaucoup de petits objets connectés, les modules Yoctopuce ont des limites quand à leur capacité de se protéger par les méthodes cryptographiques traditionnelles. Par contre, leur architecture originale permet de réduire très efficacement les risques de déni de service et d'utilisation malveillante, les rendant particulièrement inintéressants comme point d'attaque pour pénétrer dans un réseau sécurisé.