Fuzzing dans l'Internet des objets

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[4].

Le protocole CoAP (Constrained Application Protocol) est conçu au dessus d'UDP[2]. Il est utilisé comme une sorte d'HTTP léger pour l'IoT[5]. 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[2].

Mbed TLS est une librairie de cryptographie pour l'IoT[6]. Le code source est disponible en open source[7] et est téléchargeable[8]. 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[9], 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[10].

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[11].

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[12].

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[14], aux spécifications OPC[15] ou encore aux systèmes de télégestion SCADA[16] - [17].

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)[18]. 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[18].

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[19].

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[13].

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[13].

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[13].

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[13].

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[20]. 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é[21].

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[22]. 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é[23].

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[20].