Il y a eu plusieurs articles sur le Habré qui ont soulevé le sujet de l'American Fuzzy Lop (AFL) ( 1 , 2 ). Mais dans cet article, nous ne parlerons pas de l'AFL classique, mais des utilitaires auxiliaires pour lui et de ses modifications, qui, à notre avis, peuvent améliorer considérablement la qualité du fuzzing. Si vous souhaitez apprendre à mettre à niveau AFL et rechercher des vulnérabilités plus rapides et plus nombreuses, bienvenue dans la coupe!

Qu'est-ce que l'AFL et pourquoi est-ce si bon

AFL - Fuzzer guidé par la couverture ou fuzzer basé sur la rétroaction. Vous pouvez en savoir plus sur ces concepts à partir d'un article aussi cool que Fuzzing: Art, Science et Engineering . Si nous résumons les informations sur AFL, nous pouvons dire ce qui suit:

• Outillage d'un exécutable pour collecter des informations de couverture
• Mute l'entrée pour maximiser la couverture
• Répète l'étape précédente pour rechercher les plantages du programme.
  • En pratique, très efficace
    • Très simple d'utilisation

Graphiquement, cela peut être représenté comme suit:



Si vous ne savez pas ce qu'est l'AFL, alors pour commencer, nous vous recommandons:

1. Page officielle du projet
2. afl-training - une brève excursion en AFL
3. afl-demo - une démonstration simple de la façon de flou un programme C ++ en utilisant AFL
4. afl-cve - Collection de vulnérabilités découvertes à l'aide d'AFL (non mis à jour depuis 2017)
5. Le fait que l'AFL ajoute au programme lors de son assemblage peut être trouvé ici.
6. Quelques conseils utiles pour fuzzer les applications réseau ici

Au moment de la rédaction, la dernière version d'AFL était la version 2.52b . Fazzer se développe activement, et au fil du temps, certains développements tiers sont inclus dans la branche principale d'AFL et deviennent hors de propos par eux-mêmes. Il existe actuellement plusieurs outils auxiliaires utiles qui peuvent être identifiés - ils sont répertoriés dans la section suivante.


Cependant, certains utilisateurs de l'AFL notent que l'auteur du phaseur Michal Zalewski a marqué une campagne pour soutenir son idée, car les derniers changements sont datés du 5 novembre 2017. Cela serait lié à son départ de Google et à de nouveaux projets. À cet égard, les gens ont commencé à collecter et à créer indépendamment des correctifs pour la dernière version actuelle 2.52b.



Il existe également différentes options et dérivés d'AFL qui permettent de fuzzer Python, Go, Rust, OCaml, GCJ Java, les appels système du noyau ou même des machines virtuelles entières.

Outils auxiliaires

Dans cette section, nous avons sélectionné divers scripts et outils pour travailler avec AFL et les avons divisés en plusieurs catégories:

Traitement de kresh

• afl-utils - un ensemble d'utilitaires pour le traitement / l'analyse automatique des plantages et la minimisation des cas de test.
• afl-crash-analyzer - Un autre analyseur de crash AFL.
• fuzzer-utils - un ensemble de scripts pour analyser les résultats.
• atriage est un outil de triage simple.
• afl-kit - Réécrit en python afl-cmin.
• AFLize est un outil qui génère automatiquement des builds de paquets Debian adaptés aux afl.
• afl-fid - un ensemble d'outils pour travailler avec les données d'entrée.

Couverture du code

• afl-cov - Fournit des données de couverture lisibles par l'homme.
• count-afl-calls - Score de rapport. Le script compte le nombre de blocs instrumentés dans le binaire.
• afl-sancov - comme afl-cov, mais utilise un désinfectant Clang.
• covnavi est un script d'analyse et de couverture de code du groupe Cisco Talos.
• LAF LLVM Passes est un ensemble de correctifs pour afl qui modifient le code pour faciliter le passage des branches par les branches

Plusieurs scripts pour minimiser les cas de test

• afl-pytmin est un wrapper pour afl-tmin qui essaie d'accélérer le processus de réduction du scénario de test en utilisant plusieurs cœurs de processeur.
• afl-ddmin-mod - une variation de afl-tmin basée sur l'algorithme ddmin.
• halfempty est un utilitaire basé sur la parallélisation rapide pour minimiser les cas de test de Tavis Ormandy.

Pour un démarrage distribué

• disfuzz-afl - fuzzing distribué pour afl.
• AFLDFF est un cadre pour le fuzzing distribué avec AFL.
• afl-launch est un outil pour lancer de nombreuses instances afl.
• afl-mèreship - Gérez et lancez plusieurs fuzzers AFL synchronisés sur le cloud AWS.
• afl-in-the-cloud est un autre script pour exécuter afl dans AWS.
• VU_BSc_project - Test Fuzz des bibliothèques open source avec libFuzzer et AFL.

En outre, un très bon article «Mise à l'échelle d'AFL sur une machine à 256 threads» a récemment été publié sur ce sujet, qui décrit le lancement d'AFL sur 256 threads.

Déploiement, gestion, suivi, reporting

• afl-other-arch - un ensemble de correctifs et de scripts pour ajouter facilement la prise en charge de diverses architectures (non x86) dans AFL.
• afl-trivia - quelques petits scripts pour simplifier la gestion de l'AFL.
• afl-monitor - un script pour surveiller le fonctionnement de l'AFL.
• afl-manager - un serveur web python pour gérer multi-afl.
• afl-tools - image docker avec afl-latest, afl-dyninst et Triforce-afl.
• afl-remote - un serveur Web pour la gestion à distance des instances afl.

Modifications AFL

AFL a grandement influencé la communauté de recherche de vulnérabilités et l'industrie du fuzzing elle-même. Et il n'est pas surprenant qu'au fil du temps, diverses modifications inspirées de l'AFL d'origine aient commencé à apparaître sur la base de son idée. Dans cette section, nous les examinerons. Chacune de ces modifications a ses avantages ainsi que ses inconvénients par rapport à la version AFL d'origine dans différentes situations.

Dites simplement que s'il y a des problèmes avec l'installation ou si vous ne voulez pas passer de temps - presque toute modification peut être trouvée sur hub.docker.com

Pourquoi?

• Augmentez la vitesse et / ou la couverture du code
  
  • Des algorithmes
  • L'environnement
    
    • OS
    • Le fer
    
    
  
  
• Travailler dans des conditions sans code source
  
  • Émulation de code
  • Instrumentation de code
    
    • Statique
    • Dynamique
    
    
  
  

Modes AFL intégrés

Avant de passer à la discussion des différentes modifications et fourches AFL, il est nécessaire de parler de deux modes importants qui étaient autrefois également des modifications, et qui sont finalement devenus des modes intégrés. Il s'agit du mode Syzygy et du mode Qemu.

Mode Syzygy - est le mode de fonctionnement dans instrument instrument.exe

instrument.exe --mode=afl --input-image=test.exe --output-image=test.instr.exe 

Pour ce mode, il est nécessaire: Réécrire statiquement les binaires PE32 avec AFL, des symboles sont requis, Nécessite un dev supplémentaire pour rendre le noyau WinAFL conscient.

Mode Qemu - Comment cela fonctionne sous QEMU peut être trouvé ici "Internals of AFL fuzzer - QEMU Instrumentation" . La prise en charge de l'utilisation des binaires à l'aide de QEMU est apparue dans l'AFL en amont à partir de la version 1.31b. Le mode afl qemu fonctionne avec la fonctionnalité supplémentaire d'instrumentation de code binaire dans le moteur de traduction binaire qemu tcg (petit générateur de code). Pour ce faire, afl dispose d'un script de construction qemu qui télécharge le code source d'une version spécifique (2.10.0) de qemu, leur impose plusieurs petits correctifs et les compile pour une architecture donnée. Après cela, le fichier afl-qemu-trace est renvoyé, qui est en fait une émulation en mode utilisateur (émulation de fichiers exécutables ELF uniquement). Grâce à cela, vous pouvez utiliser le fuzzing avec des commentaires sur les binaires elf, et pour un tas d'architectures différentes prises en charge par qemu. De plus, vous obtenez tous les outils cool d'Afl, en commençant par un écran pratique avec des informations sur la session en cours et en terminant par des choses avancées comme afl-analyse. Mais gardez à l'esprit que vous bénéficiez également de restrictions qemu. De plus, par exemple, si le fichier est compilé par une chaîne d'outils qui utilise les fonctionnalités matérielles SoC, sur lesquelles le binaire est lancé et qui n'est pas pris en charge par qemu, le fuzzing s'arrête dès qu'une instruction spécifique est rencontrée, ou, par exemple, un MMIO spécifique est utilisé.

Il existe également une fourchette intéressante du mode qemu, où la vitesse a été augmentée 3x-4x fois en raison de l'instrumentation du code TCG et de la mise en cache.

Fourches

L'apparition des fourches AFL est principalement associée à des changements, à des améliorations des algorithmes de fonctionnement des AFL classiques eux-mêmes.

• afl-cygwin est une tentative de portage d'AFL classique vers Windows à l'aide de Cygwin. Malheureusement, cette tentative est assez floue, lente et le développement peut être considéré comme abandonné.
• AFLFast (étend AFL avec Power Schedules) - l'une des premières fourches d'AFL, toutes sortes d'heuristiques ont été ajoutées, grâce auxquelles elle pourrait aller plus loin dans un court laps de temps.
• FairFuzz est une extension AFL dont le but est d'essayer de passer plus de temps sur des branches plus rares.
• AFLGo est une extension pour AFL, qui est principalement destinée à la réalisation ciblée de certaines sections de code, plutôt qu'à la couverture générale du code de programme. Cela peut être utilisé pour tester des correctifs ou des sections de code nouvellement ajoutées.
• PerfFuzz est une extension AFL qui recherche des cas de test qui pourraient ralentir le programme autant que possible.
• Pythia est une extension pour AFL qui vise à ajouter des éléments de prédiction au processus de phasage en ce qui concerne la difficulté de découvrir de nouveaux chemins.
• Angora est l'un des flous les plus récents, écrits en rouille. Utilise ses nouvelles stratégies de mutation et pour augmenter la couverture.
• Neuzz - une tentative de fuzz en utilisant des réseaux de neurones.
• UnTracer-AFL - intégration afl avec UnTracer, pour un traçage efficace.
• Qsym - Moteur d'exécution concolique pratique conçu pour le fuzzing hybride. En fait, c'est un moteur d'exécution de symboles (les principaux composants sont implémentés comme un plug-in intel pin), qui, en combinaison avec afl, implémente le fuzzing hybride. Il s'agit d'une nouvelle évolution du sujet de fuzzing basé sur les commentaires et mérite une discussion séparée. Son principal mérite est qu'il peut très rapidement (par rapport au reste) effectuer une exécution concolique. Cela se produit en raison de l'exécution native des commandes sans présentation intermédiaire du code, en se débarrassant du mécanisme d'instantané et d'un certain nombre d'heuristiques. Il utilise l'ancienne broche Intel (en raison d'un certain nombre de problèmes de support entre libz3 et d'autres DBT) et peut actuellement fonctionner avec les architectures elf x86 et x86_64.

Il convient de noter qu'il existe un grand nombre de travaux universitaires liés à la mise en œuvre de nouvelles approches, techniques de fuzzing, où l'AFL est utilisé et modifié. En plus du livre blanc, rien d'autre n'est disponible, nous n'avons donc même pas mentionné de telles implémentations. Si vous êtes intéressé, alors ils sont faciles à google. Par exemple, ce dernier est CollAFL: Path Sensitive Fuzzing , EnFuzz , Smart Greybox Fuzzing , ML for afl.

Modifications basées sur Qemu

• TriforceAFL - Fuzzing AFL / QEMU avec émulation système complète. Fourche de nccgroup. Permet de flouiller l'ensemble du système d'exploitation en mode qemu. Implémenté via une instruction spéciale (aflCall (0f 24)), qui a été ajoutée au processeur QEMU x64. Malheureusement, il n'est plus pris en charge, la dernière version d'AFL en elle est 2.06b.
• TriforceLinuxSyscallFuzzer - Fuzzing des appels système Linux.
• afl-qai est un petit projet de démonstration avec QEMU Augmented Instrumentation (qai).

Modification basée sur KLEE

kleefl - pour générer des cas de test au moyen d'une exécution symbolique (très lent sur les grands programmes).

Modifications basées sur Unicorn

afl-unicorn - vous permet de fuzz des morceaux de code, en les émulant sur le moteur Unicorn . Nous avons également utilisé avec succès cette variation AFL dans notre pratique, à savoir dans les sections de code d'un RTOS, qui a été exécuté sur SOC, et il était impossible d'utiliser le mode QEMU. Il est conseillé d'utiliser cette modification lorsqu'il n'y a pas de sources (vous ne pouvez pas assembler de binaires autonomes pour l'analyse de l'analyseur) et que le programme n'accepte pas directement les données d'entrée (par exemple, elles sont cryptées ou représentent des échantillons de signaux comme dans un binaire CGC), vous pouvez alors les utiliser inverser et trouver les lieux-fonctions proposés où ces données sont traitées dans un format convenable pour le fuzzer et qui peuvent être fuzzées. Il s'agit de la modification AFL la plus courante. En ce sens que cela vous permet de tout flou. Autrement dit, cela ne dépend pas de l'architecture, de la disponibilité des codes source, du format des données d'entrée et du format du binaire lui-même (l'exemple le plus frappant est juste du métal nu - juste des morceaux de code de la mémoire du contrôleur). Le chercheur examine au préalable ce binar même et écrit un fuzzer qui émule l'état à l'entrée de la procédure de l'analyseur, par exemple. On peut voir que, contrairement à l'AFL, vous devez faire une sorte de recherche sur le binaire. Pour le micrologiciel nu, comme le Wi-Fi ou la bande de base, il y a simplement un certain nombre d'inconvénients que vous devez garder à l'esprit:

1. Il est nécessaire de localiser en quelque sorte les contrôles de somme de contrôle.
2. Il faut garder à l'esprit que l'état du fuzzer est l'état de la mémoire qui a été stockée dans le vidage de la mémoire, cela peut empêcher la réalisation de certains chemins pour le fuzzer.
3. Il n'y a pas d'assainissement des accès à la mémoire dynamique, mais elle peut être implémentée manuellement (également après avoir déployé des efforts), et cela dépendra de RTOS (elle doit également être étudiée au préalable).
4. L'interaction entre les tâches RTOS n'est pas émulée - vous pouvez également empêcher Fuzzer de trouver certains chemins.

Un exemple de travail avec cette modification est «afl-unicorn: Fuzzing Arbitrary Binary Code» et
«Afl-unicorn: Part 2 - Fuzzing the 'Unfuzzable'» .

Avant de passer aux modifications basées sur les frameworks d'instrumentation binaire dynamique (DBI), nous rappelons immédiatement que DynamoRIO affiche la vitesse la plus élevée de ces frameworks, puis DynInst, et enfin PIN.

Modifications du code PIN

• aflpin - AFL avec Intel PIN Instrumentation.
• afl_pin_mode - Une autre instrumentation AFL implémentée via Intel PIN.
• afl-pin - AFL avec PINtool.
• NaFl - Un clone (du noyau de base) de fuzzer AFL.
• PinAFL - l'auteur de l'outil a essayé de transférer AFL vers Windows pour fuzzing des binaires déjà compilés. Apparemment, on a fait plus sur le ventilateur en une soirée, puis le projet ne se développe pas. Le référentiel ne contient pas de sources, uniquement des binaires collectés et des instructions de démarrage. La version AFL sur laquelle cet outil est basé n'est pas spécifiée et ne prend en charge que les applications 32 bits.

Comme vous pouvez le voir, il existe de nombreuses modifications différentes, mais dans la pratique, elles ne sont pas très utiles dans la vie réelle.

Modifications basées sur Dyninst

afl-dyninst - American Fuzzy Lop + Dyninst == AFL blackbox fuzzing. La caractéristique de cette version est que le programme initialement étudié (sans code source) est instrumenté statiquement (instrumentation binaire statique, réécriture binaire statique) en utilisant DynInst, puis flou par l'AFL classique, qui pense que le programme a été construit en utilisant afl-gcc / afl -g ++ / afl-as;) Au final, cela nous donne l'opportunité de travailler sans code source et avec de très bonnes performances - Il était à une vitesse de 0,25x par rapport à une compilation native. Il y a un avantage significatif par rapport à QEMU, qui est la capacité d'instrumenter des bibliothèques liées dynamiquement. Alors que QEMU ne peut instrumenter que le fichier exécutable principal lié statiquement aux bibliothèques. Malheureusement, cela ne concerne désormais que le système d'exploitation Linux. Pour prendre en charge Windows, des modifications sont nécessaires dans DynInst lui-même et le travail y est en cours .

Vous pouvez également faire attention à une telle fourche où elle a été bien pompée sur diverses capacités (prise en charge des architectures AARCH64 et PPC) et la vitesse;)

Modifications basées sur DynamoRIO

• drAFL - AFL + DynamoRIO = fuzzing sans source sous Linux.
• afl-dr - une autre mise en œuvre sur la base de DynamoRIO qui est déjà peint en détail dans les espaces ouverts de Habr.
• afl-dynamorio - modification de vanhauser-thc (un ventilateur pour pomper et stabiliser AFL). il dit à propos de cette version: "exécutez AFL avec DynamoRIO lorsque afl-dyninst normal plante le mode binaire et qemu -Q n'est pas une option." D'agréable, le support pour ARM et AARCH64 est ajouté ici. Concernant les performances: DynamoRIO est environ ~ 10 plus lent que Qemu, ~ 25 plus lent que dyninst - cependant, ~ 10 plus rapide que Pintool.
• WinAFL est le fork le plus célèbre d'af pour Windows. (DynamoRIO, ont également le mode syzygy). L'apparition de cette modification n'était qu'une question de temps, car le désir d'essayer AFL sous Windows sur des applications pour lesquelles il n'y a pas de code source est apparu pour beaucoup. Pour le moment, l'outil est activement développé, et malgré l'utilisation de la base de code AFL légèrement en retard (2.43b au moment de la rédaction), plusieurs vulnérabilités ont déjà été trouvées avec celui-ci (CVE-2016-7212, CVE-2017-0073, CVE-2017- 0190, CVE-2017-11816). Il convient de noter que les principaux développeurs sont des spécialistes de l'équipe Google Zero Project et de l'équipe MSRC Vulnerabilities and Mitigations, ce qui donne des raisons d'espérer un développement actif du projet. Pour implémenter le flou, les développeurs sont passés de la compilation de l'instrumentation temporelle à l'utilisation de l'instrumentation dynamique (basée sur DynamoRIO), ce qui devrait ralentir l'exécution du logiciel à l'étude, mais la surcharge résultante (deux fois) est comparable à l'AFL classique en mode binaire. Les développeurs ont également résolu le problème d'un long démarrage du processus, le qualifiant de mode de fuzzing persistant, ils sélectionnent la fonction qui doit être fuzzée (par décalage dans le fichier ou par nom si la fonction est présentée dans la table d'exportation) et l'instrumentation de telle manière qu'elle puisse être appelée dans une boucle, lançant ainsi plusieurs échantillons de données d'entrée sans redémarrer le processus. Un article intéressant est récemment paru dans lequel les chercheurs ont montré comment ils avaient trouvé ~ 50 vulnérabilités avec ~ 50 jours d'utilisation de winafl. De plus, presque avant la publication de l'article dans WinAFL, le mode Intel PT a également été ajouté (plus d'informations à ce sujet plus tard) - les détails sont ici .

Un lecteur avancé / sophistiqué peut noter qu'il y a des modifications avec tous les cadres d'instrumentation populaires, à l'exception de Frida - c'est le cas. La seule mention de l'utilisation de Frida avec AFL n'a été trouvée que dans Chizpurfle: Un Fuzzer Android Gray-Box pour les personnalisations des services des fournisseurs . La version d'AFL avec Frida était vraiment utile car Frida supporte bien un certain nombre d'architectures RISC.

De nombreux chercheurs attendent également avec impatience la sortie du cadre Scorpio DBI du créateur de Capstone, Unicorne, Keystone. Sur la base de ce cadre, les auteurs eux-mêmes ont déjà réalisé un fuzzer (Darko) et, selon eux, l'ont utilisé avec succès pour fuzzer des appareils embarqués. Pour plus d'informations, consultez Digging Deep: Find 0days in Embedded Systems with Code Coverage Guided Fuzzing .

Modifications basées sur les capacités matérielles du processeur

En ce qui concerne les modifications AFL avec prise en charge des capacités matérielles du processeur, cela indique principalement la possibilité de fuzzing le code du noyau, et deuxièmement, une vitesse de fuzzing plus élevée pour les applications sans code source.

Et, bien sûr, nous parlons tout d'abord de capacités matérielles du processeur comme Intel PT (Processor Tracing). Qui est disponible à partir de la 6ème génération de processeurs (c'est-à-dire vers 2015). Naturellement, pour utiliser les fuzzers suivants, vous aurez besoin d'un matériel avec le support Intel PT approprié.

• WinAFL-IntelPT est une modification WinAFL tierce dans laquelle la technologie Intel PT est déjà utilisée à la place de DynamoRIO.
• kAFL est un développement académique visant à résoudre le problème guidé par la couverture pour le phasing du noyau d'une manière indépendante du système d'exploitation. Ce qui est résolu en utilisant l'hyperviseur et la technologie Intel PT. Vous pouvez en savoir plus sur leur livre blanc «kAFL: Fuzzing de rétroaction assistée par matériel pour les noyaux OS» .

Conclusion

Comme vous l'avez peut-être remarqué, ce sujet se développe activement. En même temps, il y a beaucoup d'espace pour la créativité pour créer une nouvelle modification intéressante et utile d'AFL.

Merci pour votre attention et votre fuzzing réussi!

Co-auteur: Nikita Knizhov

PS Merci à toute l'équipe du centre de recherche pour leur aide dans la préparation de ce matériel, sans leur expérience et leur aide, il serait impossible de préparer une telle chose.