Fuzzing dans l'Internet des objets

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

L'IoT est un secteur qui a émergé dans les années 2000, qui évolue vite, et dans lequel les technologies utilisées sont encore hétérogènes. Il n'y a pas encore de réel standard établit notamment en termes de test et de sécurité. Le but final étant de pouvoir garantir une interopérabilité des composants sur le marché pour envoyer et recevoir des paquets et messages de manière sûre et continuer à faire en sorte que cette industrie puisse rester compétitive et réactive sur le marché. Les standards et process de tests doivent donc innover par rapport aux process de standardisation classiques. Par exemple, le fait que le système d'un objet connecté puisse être patché plusieurs fois après sa mise sur le marché est une contrainte qui doit être prise en compte. En ce sens le fuzzing est une aide qui permet de les tester y compris les comportements inconnus et inattendus, et cette technique se fait de plus en plus une place dans les process de tests. Par exemple Microsoft intègre dans ses protocoles de tests une phase de fuzzing de ses logiciels avant leur mise sur le marché.

Des standards en construction

Consciente de la nécessité du besoin de standardiser l'IoT, notamment les standards de sécurité de l'IoT qui ont la particularité de grandir très vite, l'Europe a créé un programme de recherche nommé Horizon 2020 pour soutenir la recherche et l'innovation. Dans le cadre de ce programme, un projet de standardisation de l'IoT nommé ARMOUR a été lancé en Février 2016 entre cinq pays européens: la France, la Grèce, le Portugal, l'Espagne et l'Italie, avec un consortium de plusieurs laboratoires de recherche comme l'INRIA. Le but est de produire un cadre expérimental en apportant des solutions de tests et des standards destinés à l'industrie de l'IoT. Ce programme doit fournir une boite à outils de tests, des méthodes de travail, et des propositions pour la mise en place et l'obtention de certifications de sécurité.

Pour fournir cette boite à outils et ces frameworks, les chercheurs du programme ARMOUR s'appuient sur le fuzzing pour tester tous les comportements et plus précisément les plus incertains. Le fuzzing permet en effet de produire de nombreux tests à grande échelle. L'algorithme utilisé permet de tester de nombreux comportements tout en évitant les duplications, ce qui en fait un outil précieux dans les protocoles de tests.

Bibliographie

• (en) X. Han, Q. Wen et Z. Zhang, « A mutation-based fuzz testing approach for network protocol vulnerability detection », Proceedings of 2012 2nd International Conference on Computer Science and Network Technology,‎ décembre 2012, p. 1018–1022 (DOI 10.1109/iccsnt.2012.6526099, lire en ligne, consulté le 10 octobre 2017)
• (en) Qixu Liu et Yuqing Zhang, « TFTP vulnerability finding technique based on fuzzing », Computer Communications, vol. 31, n^o 14,‎ 5 septembre 2008, p. 3420–3426 (DOI 10.1016/j.comcom.2008.05.041, lire en ligne, consulté le 10 octobre 2017)
• (en) A. Lahmadi, C. Brandin et O. Festor, « A Testing Framework for Discovering Vulnerabilities in 6LoWPAN Networks », 2012 IEEE 8th International Conference on Distributed Computing in Sensor Systems,‎ mai 2012, p. 335–340 (DOI 10.1109/dcoss.2012.48, lire en ligne, consulté le 10 octobre 2017)
• (en) Paul Bakker, « PolarSSL is dead, long live mbed TLS », Arm Community,‎ 2015 (lire en ligne, consulté le 2 janvier 2018)
• (en) S. Kulkarni, S. Saha et R. Hockenbury, « Preserving privacy in sensor-fog networks », The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014),‎ décembre 2014, p. 96–99 (DOI 10.1109/ICITST.2014.7038785, lire en ligne, consulté le 1^er janvier 2018)
• (en) N. Tamani et Y. Ghamri-Doudane, « Towards a user privacy preservation system for IoT environments: a habit-based approach », 2016 IEEE International Conference on Fuzzy Systems (FUZZ-IEEE),‎ juillet 2016, p. 2425–2432 (DOI 10.1109/FUZZ-IEEE.2016.7737997, lire en ligne, consulté le 1^er janvier 2018)
• (en-US) Artemios G. Voyiatzis, Konstantinos Katsigiannis et Stavros Koubias, « A Modbus/TCP Fuzzer for testing internetworked industrial systems », 2015 IEEE 20th Conference on Emerging Technologies & Factory Automation (ETFA),‎ 2015 (DOI 10.1109/etfa.2015.7301400, lire en ligne, consulté le 6 janvier 2018)
• (en) Xiong Qi, Peng Yong, Zhonghua Dai et Shengwei Yi, « OPC-MFuzzer: A Novel Multi-Layers Vulnerability Detection Tool for OPC Protocol Based on Fuzzing Technology », International Journal of Computer and Communication Engineering, vol. 3, n^o 4,‎ 2014, p. 300–305 (DOI 10.7763/ijcce.2014.v3.339, lire en ligne, consulté le 6 janvier 2018)
• (en) Rebecca Shapiro, Sergey Bratus, Edmond Rogers et Sean Smith, « Identifying Vulnerabilities in SCADA Systems via Fuzz-Testing », Critical Infrastructure Protection V, Springer, Berlin, Heidelberg, iFIP Advances in Information and Communication Technology,‎ 23 mars 2011, p. 57–72 (ISBN 9783642248634, DOI 10.1007/978-3-642-24864-1_5, lire en ligne, consulté le 6 janvier 2018)
• (en) K. Koscher, A. Czeskis, F. Roesner et S. Patel, « Experimental Security Analysis of a Modern Automobile », 2010 IEEE Symposium on Security and Privacy,‎ mai 2010, p. 447–462 (DOI 10.1109/SP.2010.34, lire en ligne, consulté le 6 janvier 2018)
• (en) G. Baldini, A. Skarmeta, E. Fourneret et R. Neisse, « Security certification and labelling in Internet of Things », 2016 IEEE 3rd World Forum on Internet of Things (WF-IoT),‎ décembre 2016, p. 627–632 (DOI 10.1109/WF-IoT.2016.7845514, lire en ligne, consulté le 14 octobre 2017)
• M. Niedermaier, F. Fischer et A. von Bodisco, « PropFuzz #x2014; An IT-security fuzzing framework for proprietary ICS protocols », 2017 International Conference on Applied Electronics (AE),‎ septembre 2017, p. 1–4 (DOI 10.23919/AE.2017.8053600, lire en ligne, consulté le 11 février 2018)