Le fuzzing dans l'Internet des objets consiste à tester une grande variété de protocoles réseaux, de systèmes et d'appareils impliqués dans l'Internet des objets, dans des secteurs aussi divers que les secteurs industriel, automobile et bancaire. Le fuzzing est une technique pour tester des logiciels en injectant des entrées aléatoires dans un programme, et l'Internet des objets - Internet of Things (IoT) en anglais - est l'extension d'Internet à des objets du monde physique. Connaissant les faiblesses et les pratiques de programmation dans l'IoT, il est intéressant d'utiliser le fuzzing pour détecter les vulnérabilités et renforcer la sécurité.

Le fuzzing a déjà été utilisé dans de nombreux cas, mais le manque de standards et les contraintes, protocoles et systèmes spécifiques à l'IoT nécessitent des techniques particulières, par exemple pour la détection des erreurs ou l'instrumentation du code source.

Fuzzing réseau de l'IoT Un programme de fuzzing, appelé plus communément un fuzzer permet de découvrir des failles de sécurité. La plupart de ces programmes sont utilisés notamment pour tester les protocoles réseaux.

Les protocoles réseaux de l'IoT n'ont pas été spécialement conçus pour les objets connectés mais par exemple pour les communications en temps réel ou asynchrone et ont émergé dans les années 2000 et sont encore peu testés, mais ils ont cependant été adoptés par l'industrie de l'IoT. Pour tester ces protocoles il existe des techniques telles que le fuzzing, en utilisant un fuzzer dédié à un protocole spécifique, ou un framework plus générique. Les tests peuvent se faire selon différentes approches: entièrement automatisée ou en partie manuelle. Fuzzer les protocoles réseaux de l'IoT consiste à envoyer des séquences de paquets réseaux et à analyser la façon dont l'objet connecté y répond: en renvoyant une exception, par un crash, par un comportement inhabituel ou par un comportement normal. L'envoi de ces paquets se fera en suivant des scénarios élaborés en amont, ou de façon plus globale et aléatoire afin de recueillir une première base de données statistiques.

Les protocoles de l'IoT ont émergé dans les années 2000 et dans l'industrie de l'IoT on peut voir des implémentations de protocoles qui ne respectent pas totalement les RFC ou qui sont peu testés. Pourtant la modification des systèmes IoT une fois sur le marché étant difficile, il est nécessaire de mettre en place des tests adaptés pour éviter les vulnérabilités.

Fuzzing des protocoles réseaux de l'IoT

6LoWPAN

Le protocole 6LoWPAN (Low-power Wireless Personal Area Networks) est conçu pour consommer peu d'énergie. Les paquets sont encodés, compressés, et les longs messages sont fragmentés en plusieurs messages plus courts. Fuzzer ce protocole nécessite donc un mécanisme de décompression et compression des paquets pour les analyser. Il est également nécessaire d'identifier les différents fragments d'un même message. Cela peut se faire grâce à des outils tels que Scapy et des frameworks dédiés qui permettent d'accéder au message en représentation hexadécimale pour analyser les différents champs qui le composent tels que la taille globale du message. La construction des paquets à injecter à l'objet connecté peut se faire grâce à des systèmes d'exploitation dédiés tels que Contiki qui permettent d'envoyer nativement des messages 6LoWPAN. Ces messages sont altérés pour suivre les scénarios de test, par exemple en changeant certains bits aux hasard, certains champs au hasard ou selon une fonction personnalisée.

CoAP

Le protocole CoAP (Constrained Application Protocol) est conçu au dessus d'UDP. Il est utilisé comme une sorte d'HTTP léger pour l'IoT. Pour fuzzer ce protocole on envoie plusieurs requêtes construites pour analyser des comportements anormaux, comme par exemple une requête GET ou POST avec des options adaptées aux scénarios de tests.

Mbed TLS

Mbed TLS est une librairie de cryptographie pour l'IoT. Le code source est disponible en open source et est téléchargeable. Il est donc possible d'utiliser un fuzzer pour le tester et détecter des failles. Par exemple, grâce au fuzzer American fuzzy lop développé par Michal Zalewski, le groupe Gotham Digital Science a trouvé une faille sur le déréférencement d'un pointeur nul côté client, corrigée par ARM.

Fuzzing dans le fog computing

Confidentialité des données Le fog computing est la nouvelle génération de cloud computing. Il est composé d'objets connectés intelligents comme des capteurs reliés sans fil. Pour assurer la sécurité des données de ce type de réseau, on peut utiliser le fuzzing. Dans le fog computing chaque objet connecté a la capacité d'opérer des traitements, et chaque objet peut communiquer avec un autre et transmettre des données. Afin d'éviter que les données soient interceptées, chaque objet peut envoyer des données fuzzées selon une fréquence déterminée afin de générer du bruit. Un utilisateur malveillant ne pourra donc pas récupérer les données, alors que le récepteur légitime sera lui capable de les interpréter.

Détection des comportements malveillants Le fuzzing est également utilisé afin de construire des outils pour repérer les comportements anormaux lors de l'échange de données entre les objets connectés. En identifiant plusieurs paramètres comme le nombre de connexions reçues, les auteurs des connexions et le caractère sensible d'une donnée, il est possible d'établir un schéma de confiance et ainsi d'alerter en cas de comportements potentiellement malveillant.

Fuzzing des systèmes embarqués Les systèmes embarqués sont de plus en plus présent dans notre vie quotidienne. Leurs interconnexions avec d’autres appareils proposant différents services en ligne en font des acteurs essentiels de l’Internet des Objets. Cependant, l’augmentation rapide du nombre d’appareils connectés s’accompagne d’un accroissement de la surface d’attaque, et les systèmes fortement contraints sont considérés comme particulièrement vulnérables. Le fuzzing est une technique très populaire pour découvrir des failles de sécurité, il peut être automatisé à grande échelle même avec une connaissance limité du système à tester, mais un traitement particulier est parfois requis lorsqu'il s'agit de l'appliquer aux systèmes embarqués.

Dans le secteur industriel Les systèmes embarqués sont couramment utilisés dans les dispositifs de supervision industriels, mais la compatibilité des réseaux industriels avec Internet est une tendance récente qui les rend vulnérables aux cyber-attaques. Cette tendance entraîne donc un besoin croissant de tests de sécurité de ces réseaux. Grâce au fuzzing des implémentations de protocoles réseaux industriels, il est possible d’obtenir des informations sur la résilience des systèmes face aux nouvelles menaces en provenance d’Internet. Cependant, les outils de fuzzing traditionnels ne conviennent pas à ces systèmes complexes conçus pour fonctionner en vase clos, on voit donc apparaître de nouveaux outils de fuzzing spécialisés, dédiés par exemple au protocole Modbus/TCP, aux spécifications OPC ou encore aux systèmes de télégestion SCADA.

Dans le secteur automobile Les automobiles modernes sont contrôlées par des dizaines d’ordinateurs coordonnés par un ou plusieurs bus de communication interne, et sont de plus en plus connectées avec l'extérieur. Ces évolutions ont introduit de nouveaux risques potentiels. Par ailleurs la fragilité de ces systèmes est démontrée, on sait maintenant qu’il est possible de prendre le contrôle de certaines fonctions critiques d’un véhicule en infiltrant les unités de commandes électroniques (ECU). Il n’est pas nécessaire de connaître finement les composants du véhicule, l’éventail de paquets CAN valides étant assez mince, un simple fuzzing de paquets générés aléatoirement puis envoyés sur un bus CAN peut entraîner des dégâts significatifs. Le fuzzing permet également de découvrir les fonctions de contrôle des ECU afin de contrôler par exemple le moteur ou les freins.

Dans le secteur bancaire Le fuzzing est également utilisé pour tester les cartes à puce. Certaines cartes, telles que les cartes de paiement, contiennent des informations sensibles ou confidentielles, or, une découverte notable concernant la technologie Java Card a permis d'accéder à ces données. La technologie Java Card permet d'enregistrer des applications sur une carte à puce, même après sa fabrication. Pour prévenir l'installation d'applications malveillantes, le code Java est préalablement vérifié par un élément de sécurité appelé Byte Code Verifier (BCV). En 2015, une technique de fuzzing inspirée d'algorithmes génétiques a révélé une faille permettant d'injecter du code à travers le BCV, puis de prendre le contrôle de la totalité de la mémoire de la carte.

Défis spécifiques La théorie et les outils du fuzzing développés dans les années 90 ont été conçus pour tester des programmes exécutés sur des systèmes généralistes sophistiqués. Ils sont généralement inadaptés aux systèmes embarqués destinés à fonctionner dans des environnements fortement contraints. En outre, les systèmes embarqués sont des dispositifs souvent très spécialisés, hétérogènes et opaques, qui utilisent de nombreux protocoles propriétaires. Le fuzzing de tels systèmes est donc un exercice particulièrement délicat qui nécessite un travail de préparation au cas par cas. Parmi les défis majeurs, on peut mentionner la détection des erreurs, la performance et la scalabilité des tests, mais aussi l'instrumentation des tests.

La détection d’erreurs La grande majorité des techniques de fuzzing s’appuie sur des erreurs observables, or la plupart des systèmes embarqués ne dispose pas de mécanismes de détection des erreurs, et même lorsque ces mécanismes existent, ils sont souvent incomplets ou ne produisent pas de messages d’erreurs. Une des techniques permettant de compenser ces lacunes consiste à vérifier continuellement l’activité du système afin de connaître les effets des tests de fuzzing sur le dispositif.

La performance et la scalabilité Il est rarement possible de virtualiser entièrement un système embarqué, et se procurer un grand nombre d’appareils n’est souvent pas envisageable par manque de moyens, il est donc difficile de démarrer plusieurs instances du même logiciel pour paralléliser les tests. De plus, il est nécessaire de restaurer fréquemment l’état initial du dispositif pour préparer le test suivant, ce qui implique généralement un redémarrage complet de l’appareil et ralenti considérablement l’exécution des tests.

L’instrumentation Le manque de visibilité sur le fonctionnement du système limite l’accès à des techniques de fuzzing sophistiquées. En effet, le plus souvent le code source des firmwares n’est pas disponible, et la diversité des cibles à tester complique grandement la recompilation. Une solution courante consiste à instrumenter le programme compilé, mais elle est rarement applicable pour cette catégorie de dispositifs. Ainsi, l’instrumentation statique ou dynamique des firmwares est souvent complexe, voire impossible.

Le fuzzing outil dans la standardisation de l'IoT

Des process de standardisation à adapter