otsmr/blackbox-fuzzingFuzzing des appareils IoT avec le routeur TL-WR902AC comme exemple
Ceci est la version HTML de mon mémoire qui peut être téléchargé en PDF ici.
Le fuzzing est devenu « l'un des moyens les plus efficaces » de trouver des bugs dans les logiciels. C'est par cette affirmation ou des affirmations similaires que commencent de nombreux articles récents liés au fuzzing [google-scholar]. L'objectif principal de notre précédent mémoire sur le thème « Internet of Vulnerable Things » était de trouver un bug lié à la mémoire, puis d'écrire un exploit pour cette vulnérabilité. Nous avons réussi à trouver une vulnérabilité en rétro-ingéniant le firmware, mais aucun bug lié à la mémoire n'a été trouvé. Trouver un débordement de tampon en rétro-ingéniant un binaire à la main est non seulement chronophage, mais nécessite également beaucoup d'expérience. Le fuzzing vise quant à lui à être le « moyen le plus efficace » de trouver ce type de vulnérabilités liées à la mémoire. Google, par exemple, a introduit OSS-Fuzz, qui fuzze en continu des logiciels open source et a déjà trouvé plus de 10 000 vulnérabilités dans 1 000 projets [oss-fuzz].
L'objectif de ce mémoire est à nouveau de trouver une vulnérabilité liée à la mémoire, mais cette fois en utilisant le fuzzing. La vulnérabilité visée doit être exploitable sur le réseau sans connaître les identifiants administrateur. Ce mémoire décrit la manière d'atteindre cet objectif. Pour cela, le mémoire est divisé en deux parties. La première partie se concentre sur la façon de trouver une cible pertinente, quels outils peuvent être utilisés et ce que doit comprendre une bonne cible de fuzzing. La seconde partie décrit ensuite comment développer et déboguer un harness capable de fuzzer une fonction spécifique d'un binaire. Ensuite, le harness développé est utilisé par AFL++ pour fuzzer la fonction cible. Dans ce qui suit, un bref contexte est présenté ainsi que l'état de l'art actuel en matière de fuzzing d'appareils IoT.
Tous les fichiers créés dans le cadre de ce mémoire sont également publiés intégralement sur GitHub et peuvent être consultés via l'URL suivante : otsmr/blackbox-fuzzing.
Fuzzer des appareils IoT n'est pas aussi simple que fuzzer un projet open source. Souvent, le code source est propriétaire, ce qui rend impossible le fuzzing en boîte grise, qui instrumente le code source pour obtenir les meilleures performances de fuzzing [afl-persistent]. De plus, l'architecture du processeur n'est souvent pas prise en charge nativement par les fuzzers, ce qui nécessite un émulateur comme QEMU [qemu], ce qui ralentit également la vitesse de fuzzing [afl-persistent]. Un autre problème concerne les périphériques matériels, ce qui complique le développement d'une approche générale. L'article « Embedded Fuzzing: A Review of Challenges, Tools, and Solutions » [embedded-fuzzing] donne un aperçu des différentes stratégies de fuzzing, comme le fuzzing embarqué basé sur le matériel. La plupart de ces stratégies nécessitent le code source du programme cible, par exemple lors du portage du code source du fuzzer, comme AFL, vers des appareils IoT basés sur ARM afin d'exécuter le fuzzer sur le matériel IoT. L'exécution du fuzzer sur le matériel de l'appareil pose également des problèmes de performances, car ces appareils ont souvent des processeurs bas de gamme, plus lents que les processeurs de bureau classiques. Une autre approche présentée dans cet article est le fuzzing embarqué basé sur l'émulation, où soit un seul programme ciblé est exécuté dans un émulateur pour effectuer un fuzzing guidé par la couverture, soit le système complet.
Les approches mentionnées ci-dessus ciblent toutes un binaire directement en utilisant un émulateur ou en instrumentant le code source. Ces approches nécessitent une configuration de fuzzing qui doit souvent être spécialement conçue pour un seul appareil IoT et sont difficiles à généraliser. Pour cela, les chercheurs ont créé un programme IoTFuzzer qui vise à être un cadre de fuzzing automatisé ayant pour objectif de « trouver des vulnérabilités de corruption mémoire sans accès à leurs images de firmware
[iotfuzzer]. » IoTFuzzer repose sur l'observation que la plupart des appareils IoT disposent d'une application mobile pour les contrôler, et que ces applications contiennent des informations sur le protocole utilisé pour communiquer avec l'appareil. Le programme identifie et réutilise ensuite la logique spécifique au programme pour muter les cas de test afin de tester efficacement les cibles IoT [iotfuzzer].
Un harness décrit une séquence d'appels API traitant les entrées fournies par le fuzzer. Contrairement à une application normale, qui ne nécessite souvent pas de harness, une bibliothèque qui implémente des fonctions réutilisables doit être appelée avec les bons paramètres et dans le bon ordre, afin que l'état entre plusieurs appels de fonctions partagées puisse être appelé. Fuzzer aléatoirement la bibliothèque sans construire la machine à états a peu de chances de réussir et, au contraire, créera beaucoup de faux positifs (crashes) lorsque les dépendances de la bibliothèque ne sont pas respectées. Cela peut se produire lorsque, par exemple, une vérification de taille de tampon est ignorée par le fuzzer, ce qui entraîne un débordement de tampon non pertinent.
Dans ce mémoire, des applications normales seront fuzzées, mais en raison des dépendances matérielles liées à l'utilisation des sockets et du multi-threading, nous devons également créer un harness pour elles. Le harness est chargé dans le contexte du binaire et peut appeler des fonctions internes du programme ciblé, comme le montre le Code 10.
Le terme « corpus » désigne des échantillons d'entrée valides ou des cas de test et sert de référence fondamentale pour générer de nouvelles données d'entrée au cours du processus de fuzzing. Dans le Code 10, il s'agirait par exemple d'une requête HTTP. Les fuzzers utilisent ensuite ce corpus pour créer des cas de test mutés ou diversifiés, facilitant ainsi la détection de vulnérabilités logicielles grâce à l'exploration de différents scénarios d'entrée.
